FS#44923 - [systemd] hangs during boot when no keyboard connected
Attached to Project:
Arch Linux
Opened by Matt H (limaxray) - Sunday, 10 May 2015, 02:02 GMT
Last edited by Toolybird (Toolybird) - Saturday, 03 June 2023, 01:56 GMT
Opened by Matt H (limaxray) - Sunday, 10 May 2015, 02:02 GMT
Last edited by Toolybird (Toolybird) - Saturday, 03 June 2023, 01:56 GMT
|
Details
Description:
Gummiboot loads default kernel correctly as long as keyboard is attached, but hangs indefinitely at boot select menu when booting without a keyboard connected. Additional info: Package version: 48-1 Configuration attached. Steps to reproduce: 1) Install gummiboot using default method and attached loader.conf and entry file (direct boot to default with no timeout) 2) Reboot system with USB keyboard connected - observe system boots successfully to login prompt without displaying gummiboot boot menu. 3) Disconnect keyboard and reboot system, system hangs at gummiboot menu. Reconnecting keyboard has no effect, system must be rebooted to correct. I don't know if this is a motherboard firmware issue, using a Biostar A68I-350 DELUXE R2.0 motherboard with latest firmware. Note, this appears to be a return of an older bug - Further attempts to debug issue: Looking at the gummiboot source, specifically console.c, I believe the issue is in console_key_read. It seems multiple attempts to read a key press are made, first using TextInputEx->ReadKeyStrokeEx, then on failure using ST->ConIn->ReadKeyStroke. In my case, when no keyboard is connected, the first call returns an error while the second returns success with a scan code of 0. The console_key_read function then returns with success and this scan code. Since scan codes 0 and 0xff indicate a keyboard error, I don't think this is correct behavior. I have attached a patch (against the head revision) to check for these scan codes and return the error from the first failed EFI call. I don't claim to know enough about UEFI to know if this is a reasonable approach or not, but it at least allows my system to boot. I apologize can't seem to find where to report this issue upstream which is why I'm reporting here - if there is a better upstream maintainer to report to I will do so. And while I see old - supposedly closed - bug reports for this issue, I haven't seen anything current, so I apologize if this is a duplicate to a more recent report. |
This task depends upon
Closed by Toolybird (Toolybird)
Saturday, 03 June 2023, 01:56 GMT
Reason for closing: Upstream
Additional comments about closing: Old and stale. If still an issue, please report upstream as mentioned in the comments.
Saturday, 03 June 2023, 01:56 GMT
Reason for closing: Upstream
Additional comments about closing: Old and stale. If still an issue, please report upstream as mentioned in the comments.

Does this still happen with systemd-boot? I'm guessing it does,
but it's good to check.

If this is still happpening, please open a bug upstream:
https://github.com/systemd/systemd/issues