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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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 -  FS#34431  - which was closed a couple years ago.

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.
Comment by Doug Newgard (Scimmia) - Monday, 06 July 2015, 15:57 GMT
Does this still happen with systemd-boot? I'm guessing it does, but it's good to check.
Comment by Dave Reisner (falconindy) - Monday, 07 January 2019, 11:40 GMT
If this is still happpening, please open a bug upstream: https://github.com/systemd/systemd/issues