Bug 1043533

Summary: No usb functionality at the LUKS password input screen when using a notebook with external usb keyboard and mouse
Product: [openSUSE] openSUSE Distribution Reporter: Stakanov Schufter <stakanov>
Component: BasesystemAssignee: Daniel Molkentin <daniel>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: crrodriguez, daniel, forgotten_ngNQ5IyoFI, hare, pwieczorkiewicz, trenn, tsuroerusu
Version: Leap 42.2   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 42.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Stakanov Schufter 2017-06-09 06:39:14 UTC
When starting up 42.2 with a grub bios password, a password protected grub and a LUKS LVM you can observe the following behavior (appeared after the last update tho kernel 4.4.70-18.9-default #1 SMP Wed May 31 09:09:25 UTC 2017 (c1231a7) x86_64 x86_64 x86_64 GNU/Linux): 

You put in the bios password, no problem, USB keyboard input works O.K. 
You put in the grub user name and password: no problem, as above.
You come to the LUKS screen. Now, unlike after a fresh install, all USB devices are unresponsive, you need to use the keyboard to input the LUKS password. USB keyboard is not even powered any more (no numlock or capslock response any more). 
Once this is done, the system will start up and USB power and functionality will return.

This was not present at install time, not even with an updated system. 

Observed behavior:
no external usb functionality when the LUKS password screen comes up. 

Normal behavior: external usb appliances should be recognized to input the LUKS password. 

This bug is IMO important and annoying, because it makes the use of docking stations impossible, if you have to open the lid. It is normally possible to use a docking station with external usb appliances and an external monitor to work as with a fix PC. With the lid closed and the laptop placed on the docking station. Such a behavior makes this useless because you will have to open the lid to input the password (thus triggering when you close it the suspend to disk or to ram feature). Or you have to work with the lid open (undesirable as you have your monitor running, this is the whole point of the docking station. 
Or you would have to set every time a different profile for the behavior of the lid.
Comment 1 Andreas Stieger 2017-06-09 07:14:25 UTC
By LUKS screen you mean the passphrase prompt in dracut.
I think this is only working in BIOS and grub due to legacy emulation, and in the initial ramdisk there is no USB support (yet).
Assigning to dracut maintainers.
Comment 2 Daniel Molkentin 2017-06-19 12:24:13 UTC
Can you check if you received any dracut updates recently as well? We need to isolate the package first. Does using an older kernel fix the issue?
Comment 3 Stakanov Schufter 2017-06-19 13:05:33 UTC
I can confirm the issue is solved by the dracut update. 
However...
First you had the VGA screen and the notebook screen showing activity when booting up. 
Now only the notebook screen shows activity. Thus somebody working on a machine attached to a ultrabase with external monitor will have to open the lid when starting the machine, no matter what. If not he will see either a black screen or not reaction on the LUKS input (reaction "dots" you see them only on the notebook screen). 
I do not deem this important, but somebody else may. You will have to judge. 

This bug is somehow connected with two other things (also the behavior before and after the fix). 
Before the fix, once the system started, when you did plug in after system start the usb keybord all open plasma-desktops came down immediately and you dropped out to sddm. 
After the patch, it is now possible to attach the keyboard without having immediate crash of all desktops (thought it might interest you). 

Also: in the one user that was hit by the most anomalies (the post one, with pam password and wallet troubles) it now (after the fix) as follows:
it is only after 8 to 10 times possible to input the password of the wallet with opening it, while the other times it is false.
- it is possible to get immediate opening when opening from the notebook keyboard directly. 
Thus the patch had effect (for whatever reason) also on this problem. 

After the patch however the machine now often tends to overheat and to shutdown in emergency (this appears to be in a random number of sessions, not always). 
Yesterday for example it boiled as soon as seccheck cronjob ran. 
I mention this because this behavior appeared after the dracut patch as well. 
So, limited to this bug, it should be considered fixed if you can live with the above.
Comment 4 Stakanov Schufter 2017-08-13 14:52:41 UTC
afaik works for me in 42.3. Will reopen if I find it to appear again.
Comment 5 Troels Just 2017-12-13 12:43:48 UTC
I have just experienced this problem of no USB input at the LUKS password prompt on Leap 42.3. My hardware is a ThinkPad W530, so at least I had the laptop's keyboard to input the passphrase, however if I only had USB I would have been out of luck. This is despite all updates having been applied.

The problem is that the "usbhid" kernel module was not included in my initrd by default, thus it might have USB bus support, but not for input devices.

I solved the problem by adding a file to /etc/dracut.conf.d/ with the following:
add_drivers+="usbhid"

I think this really ought to be a default inclusion, or at least applied when configuring full disk encryption via YaST during the installation.
Comment 6 Daniel Molkentin 2017-12-13 12:54:13 UTC
Hmmm, usbhid is included in Leap 42.2 and 42.3, see /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh. From reading the code, the only chance is that one of the files in /etc/dracut.conf.d/ sets "$drivers" (most certainly incorrect, as probably what's needed is add_drivers). thus the check at the beginning of the file fails, and so usbhid and other important drivers do not get included.
Comment 7 Troels Just 2017-12-13 13:55:56 UTC
(In reply to Daniel Molkentin from comment #6)
> Hmmm, usbhid is included in Leap 42.2 and 42.3, see
> /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh. From reading the
> code, the only chance is that one of the files in /etc/dracut.conf.d/ sets
> "$drivers" (most certainly incorrect, as probably what's needed is
> add_drivers). thus the check at the beginning of the file fails, and so
> usbhid and other important drivers do not get included.

I do see usbhid mentioned in that file, however when I did lsinitrd it was not listed along with the ehci and xhci modules.

I have not added any additional files to /etc/dracut.conf.d/ aside from the one I mentioned. The only other files in there are the two default ones for microcode and debug (02-early-microcode.conf, 99-debug.conf), the latter of which only has commented lines and thus does nothing.

I plan on installing 42.3 (Also with full disk encryption) on another one of my ThinkPads in the coming days, I will report what result I get by default on there, however my hunch is that the result will likely be the same, ie. no usbhid loaded by default.
Comment 8 Daniel Molkentin 2017-12-13 15:00:19 UTC
Sending the output of dracut -f --debug 2>&1|gzip > dracut.log.gz will help. 

While I am sceptical about an update improving this particular issue, it's still a good idea :)
Comment 9 Tomáš Chvátal 2018-04-17 14:11:41 UTC
This is automated batch bugzilla cleanup.

The openSUSE 42.2 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug against that version (see the "Version"
component in the bug fields), or alternatively open
a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime