Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#38389 - [mkinitcpio] - keyboard is unresponsive in initramfs in certain configurations

Attached to Project: Arch Linux
Opened by me (skuphundaku) - Sunday, 05 January 2014, 18:54 GMT
Last edited by freswa (frederik) - Sunday, 13 September 2020, 13:36 GMT
Task Type Bug Report
Category Arch Projects
Status Assigned
Assigned To Giancarlo Razzolini (grazzolini)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No

Details

Description:
I installed Arch on an USB drive using an encrypted root partition and after everything was done I tested it on other machines to see if everything works correctly. Unfortunately, I found a problem with the keyboard in initramfs. When requested to enter the password to decrypt my root partion at boot time, on some configurations the keyboard was unresponsive. I did have the necessary hooks configured in mkinitcpio.conf (I used the "keyboard" hook), and it should have worked without a hitch. This isn't the first time I install Arch on an USB drive with full disk encription, this seems to be a recent problem.

Here are the configurations I tested:

1. Laptop #1, Intel-based (MSI GX660), with USB 3.0
a) integrated keyboard - works
b) external USB keyboard using USB 3.0 port - works
b) external USB keyboard using USB 2.0 port - doesn't work
2. Laptop #2, Intel-based (Gateway P-6860FX), no USB 3.0
a) integrated keyboard - works
b) external USB keyboard using USB 2.0 port - doesn't work
3. Laptop #3, AMD-based (ASUS U38N), with USB 3.0
a) integrated keyboard - doesn't work
b) external USB keyboard using USB 3.0 port - works
4. Desktop #1, AMD-based, with USB 3.0
a) external PS/2 keyboard - works
b) external USB keyboard using USB 3.0 port - works
b) external USB keyboard using USB 2.0 port - doesn't work
5. Desktop #2, AMD-based, no USB 3.0
a) external PS/2 keyboard - works
b) external USB keyboard using USB 2.0 port - doesn't work

Out of all of this, I can surmise that using an USB keyboard with USB 3.0 ports always works and while using one with USB 2.0 ports never works. Using a PS/2 keyboard is just a workaround that may not be available for everybody. As for the integrated laptop keyboards, the fact that some work and some don't is even more troubling.

Additional info:
mkinitcpio 16-2 - latest version, given that I installed everything from scratch yesterday

Steps to reproduce:
Install Arch on an USB drive using dm-crypt/LUKS to do full disk encryption for the root partition. Configure mkinitcpio.conf with the necessary hooks. I used:
HOOKS="base udev autodetect modconf block keyboard encrypt filesystems fsck"
Boot from the USB drive using setups similar to the one in the description above and notice how the keyboard is unresponsive.
This task depends upon

Comment by Dave Reisner (falconindy) - Sunday, 05 January 2014, 19:16 GMT
The presence of the autodetect hook means that support for your USB keyboard will only be included if it's plugged in at the time of image creation. That's not a bug, it's just how autodetect works.

If that isn't the case, then there's little to fault mkinitcpio on here. I guess we need to pare down the problem to figure out what the failure point is:

When the keyboard doesn't work, is the module included in the initramfs? Is it loaded in early userspace at all? Does forcibly loading it (earlymodules=$modname) make the keyboard work?
Comment by me (skuphundaku) - Monday, 06 January 2014, 17:39 GMT
I removed the autodetect hook and tried again and everything seems to be working. I am still slightly confused because I have Arch installed on another USB drive since something like 1.5 years ago and that I was keeping up to date until the USB drive failed a little while ago, with the same hooks I used this time (well... with usbinput instead of keyboard) but I never had this problem before.

Also, if I were to have to check if the module is included in initramfs and/or if it's loaded in early userspace, how would I go about doing that?
Comment by Dave Reisner (falconindy) - Monday, 06 January 2014, 18:15 GMT
> how would I go about doing that?
One solution would be to call lsmod from a cleanup hook and write to /run.
Comment by Thomas Bächler (brain0) - Sunday, 12 January 2014, 11:14 GMT
The fact that the integrated keyboard on one laptop doesn't work, and that the same keyboard works on USB3 but not USB2 ports indicates some problem with autodetection (not caused by the device not being plugged in on image genration).

We really need to compare lsmod (after initramfs) to mkinitcpio -M on those machines. I'd like to see file lists of the mkinitcpio images (with autodetect enabled, look at lsinitcpio for generating them) and the output of lsmod from a cleanup hook for each of those machines.
Comment by me (skuphundaku) - Sunday, 09 February 2014, 13:49 GMT
1. Laptop #1, Intel-based (MSI GX660), with USB 3.0
a) integrated keyboard - works >> same as before
b) external USB keyboard using USB 3.0 port - works >> same as before
b) external USB keyboard using USB 2.0 port - doesn't work >> now it works
2. Laptop #2, Intel-based (Gateway P-6860FX), no USB 3.0
a) integrated keyboard - works >> same as before
b) external USB keyboard using USB 2.0 port - doesn't work >> same as before
3. Laptop #3, AMD-based (ASUS U38N), with USB 3.0
a) integrated keyboard - doesn't work >> now it works
b) external USB keyboard using USB 3.0 port - works >> same as before
4. Desktop #1, AMD-based, with USB 3.0
a) external PS/2 keyboard - works >> same as before
b) external USB keyboard using USB 3.0 port - works >> same as before
b) external USB keyboard using USB 2.0 port - doesn't work >> same as before
5. Desktop #2, AMD-based, no USB 3.0 >> the motherboard of this PC failed a couple of weeks ago, so it's out of the picture

I also noticed another thing: when autodetect is enabled, the display of laptop #3 doesn't work in graphical mode (I have all xorg drivers installed, XFCE4 and LXDM). If I connect an external display to its HDMI port, the graphical mode works on the external display. If I disable autodetect, the laptop's display works fine.

I added to this message files containing the output from lsmod after initramfs, mkinitcpio -M and lsinitcpio -a from all 4 working machines. I didn't manage to get a cleanup hook to execute in order to run lsmod from a cleanup hook though.
Comment by Dave Reisner (falconindy) - Saturday, 21 June 2014, 16:40 GMT
Is this still a problem with kernel 3.15?
Comment by me (skuphundaku) - Saturday, 21 June 2014, 16:44 GMT
I haven't looked into it yet. I will make some time, try it out again and let you know.
Comment by ixeft (ixeft) - Thursday, 24 July 2014, 21:06 GMT
Same problem here with a fresh install, with an asus laptop UX303LN and an integrated keyboard.
Comment by ixeft (ixeft) - Friday, 25 July 2014, 09:11 GMT
with an asus laptop UX303LN and an integrated keyboard :

I tried to put the keyboard hook just after base in the HOOKS (mkinitcpio.conf) :

HOOKS="base udev keyboard autodetect modconf block keymap encrypt lvm2 filesystems fsck"

But, at boot time, I can't see the hook been executed, but I see the keymap hook line, before the encrypt hook.
It is just like the hook order wasn't respected.

I also tried using fallback (without autodetect), same effect...

I think I didn't find yet the right module for my keyboard because loading keyboards modules in the MODULES part of mkinitcpio.conf has no effect either.
Comment by Dave Reisner (falconindy) - Friday, 25 July 2014, 12:37 GMT
> But, at boot time, I can't see the hook been executed
The hook has no runtime component. Notice that you don't see other hooks running during early boot, e.g. "filesystems" or "modconf". This is working as expected.

> loading keyboards modules in the MODULES part of mkinitcpio.conf has no effect either.
Because "keyboards" isn't the name of any kernel module.
Comment by ixeft (ixeft) - Friday, 25 July 2014, 15:28 GMT
Hello,

>> But, at boot time, I can't see the hook been executed
> The hook has no runtime component. Notice that you don't see other hooks running during early boot, e.g. "filesystems" or "modconf".
> This is working as expected.

Yes, I realized that looking at the mkinitcpio package...


>> loading keyboards modules in the MODULES part of mkinitcpio.conf has no effect either.
> Because "keyboards" isn't the name of any kernel module.

Yes, I know that, I'm just saying that I tried to load every keyboard related modules I found using lsmod (in a netinstall) on this laptop, and still, my keystrokes are not taken in account when I try to type my keyphrase when the hook « encrypt » is executed.

Comment by ixeft (ixeft) - Sunday, 27 July 2014, 10:08 GMT
Hello,

Booting the kernel with debug argument let me know that the keyboard is detected correctly by the serio module before encrypt hook get executed without probing any supplementary modules.

so the problem is not with keyboard detection...
Comment by ixeft (ixeft) - Sunday, 27 July 2014, 15:45 GMT
OK

my problem is not directly related to this one : when I use the keymap hook to load my keyboard layout (fr-bepo) at boot tize the «enter» and «backspace» strokes does not works anymore ...
Comment by Florian Klink (flokli) - Sunday, 07 December 2014, 23:29 GMT
As a workaround, try to add "ohci_pci" to your MODULES= line and rebuild the initramfs.

This worked at least for my laptop keyboard (Fujitsu T904).

See also: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1241505
Comment by Cornelius (dude42) - Wednesday, 01 April 2015, 14:41 GMT
I performed a clean install of Arch using the 201503 live iso. During installation my Logitech mx800 wireless keyboard worked fine. However, after installation was complete and I rebooted my keyboard was also unresponsive at the prompt for the password by the encrypt hook.

I also solved the problem by removing the autodetect hook and generating a new initcpio image. I have attached the output of lsinitcpio and lsinitcpio -a for both the working and nonworking images.
Comment by Ceriel Jacobs (cj1) - Tuesday, 14 March 2017, 23:40 GMT
mkinitcpio autodetect only adding xhci (USB 3.0) and not ehci (USB 2.0) on hosts with both USB2.0 and USB3.0 interface, is still an issue in 2017 with kernel 4.9.11-1-ARCH and mkinitcpio 22.

This is especially an issue on USB stick Arch Linux installations where you never know in whether ahci, ehci, xhci or ohci drivers will be necessary for the computer where the USB flash drive will be plugged in to.
Comment by Dave Reisner (falconindy) - Wednesday, 15 March 2017, 12:15 GMT
> This is especially an issue on USB stick Arch Linux installations where you never know in whether ahci, ehci, xhci or ohci drivers will be necessary for the computer where the USB flash drive will be plugged in to.
Then the autodetect hook is not for you.
Comment by Florian Klink (flokli) - Wednesday, 15 March 2017, 13:04 GMT
Thinkpad T460P user here.

Unlocking the drive via a keyboard connected via a docking station is really flaky.

I'm not sure whether it is related to having the initcpio built when being docked vs. being undocked,
but IMHO the hook should simply include all *hci modules in case the computer has USB support.

Some keyboard variation should still be supported with the autodetect hook in place.
Comment by Dave Reisner (falconindy) - Wednesday, 15 March 2017, 13:16 GMT
> but IMHO the hook should simply include all *hci modules in case the computer has USB support.
Which "the hook" are you referring to? If it's the keyboard hook, then it already does include all *hci modules via the inclusion of the usb/host module subdirectory.

Again, if your hardware requirements can vary, then the autodetect hook is not for you (and/or you need to manually specify your required MODULES).
Comment by Florian Klink (flokli) - Wednesday, 15 March 2017, 22:14 GMT
@falconindy: I had 'autodetect' before 'keyboard' in my 'HOOKS', so probably the relevant modules got kicked out by autodetect.

I moved 'keyboard' before 'autodetect'. I will see whether this helps :-)
Comment by Xander (wxwilcke) - Saturday, 15 July 2017, 17:39 GMT
I too, appear to experience the same issue. Not on a laptop however, but on a regular desktop PC after changing my Logitech UltraX keyboard (USB) for a Cherry Stream 3.0 (also USB).
Specifically, the Cherry kb _stops_ working during initramfs (when asking for a dm_crypt password), but works fine before and during Grub, and once the root filesystem has been accessed (ie, after entering the correct password).
The same issue does seem to pop up on the forum now and then (eg [1]), so this appears to affect more users.

Similar to the users here, I have moved and removed the 'autodetect' hook, but this didn't help. I have also tried adding the 'hid_cherry' and 'ohci_pci' module, but this too, had no effect.
Some additional info:

> uname -h
> Linux prometheus 4.9.36-1-lts #1 SMP Wed Jul 5 17:34:52 CEST 2017 x86_64 GNU/Linux

The cherry module is added in the initramfs, although I'm not even sure whether I need it in the first place. [1] mentions the 'pinctrl_cherryview' module though, but my system doesn't have that one.
> # mkinitcpio -v | grep -i cherry
> adding module: hid-cherry

All seems well during boot (after unlocking):
> Jul 15 16:37:41 prometheus kernel: usb 5-3: new low-speed USB device number 2 using xhci_hcd # the Cherry
> Jul 15 16:37:41 prometheus kernel: usb 3-2: new low-speed USB device number 2 using xhci_hcd # the UltraX
> Jul 15 16:37:41 prometheus kernel: usbcore: registered new interface driver usbhid
> Jul 15 16:37:41 prometheus kernel: usbhid: USB HID core driver
> Jul 15 16:37:41 prometheus kernel: input: Logitech HID compliant keyboard as /devices/pci0.../input3 # the UltraX
> Jul 15 16:37:41 prometheus kernel: hid-generic 0003:046D:C30E.0004: input,hidraw1: USB HID v1.10 Keyboard [Logitech HID compliant keyboard] on usb-... # the UltraX
> Jul 15 16:37:41 prometheus kernel: input: HID 046a:0023 as /devices/pci0.../input7 # the Cherry
> Jul 15 16:37:41 prometheus kernel: cherry 0003:046A:0023.0001: input,hidraw3: USB HID v1.11 Keyboard [HID 046a:0023] on usb-... # the Cherry

hwinfo gives the following output, which only differs from my UltraX on model and vendor name. As the UltraX works, it doesn't appear to have to do with the 'usbhid' driver.
> 12: USB 00.0: 10800 Keyboard
> Hardware Class: keyboard
> Model: "Cherry CyMotion Master Linux Keyboard G230"
> Hotplug: USB
> Vendor: usb 0x046a "Cherry GmbH"
> Device: usb 0x0023 "CyMotion Master Linux Keyboard G230"
> Driver: "usbhid"
> Driver Modules: "usbhid"
> ...

udevadm list the following drivers (via grep), again no different than the UltraX:
> DRIVERS=="usb"
> DRIVERS=="usb"
> DRIVERS=="xhci_hcd"
> DRIVERS=="pcieport"

TL;DR: This issue appears to go beyond laptop installs, and seems to be caused by the failing to load vendor/chipset-specific modules during initramfs.

Anyone can think of something else I try?

[1] https://bbs.archlinux.org/viewtopic.php?id=212515
Comment by Xander (wxwilcke) - Saturday, 15 July 2017, 19:00 GMT
Of course, _after_ I submit the above post (and after a week of trying stuff), I find the cause AND the fix... I'm unsure whether it applies to the all issues here though.

So, it was indeed the 'hid_cherry' module which failed to load. Adding it to the MODULES list in mkinitcpio.conf did the trick. But, as I explained above, I had already tried this without any effect. So, why didn't it work?
Well, apparently the default mkinitcpio preset (ie, '-p linux') only generates the kernel-4.xxx.img (and its fallback), whereas Grub by default boot the kernel-4.xxx-lts.img. Note the difference: the non-lts is generated, but the lts is booted. So while the 'hid_cherry' module was added to the non-lts img, I kept booting the lts img.

Strangely enough, the pacman kernel upgrade hook DOES generate the lts img, and ignores the non-lts one.
I never noticed this difference before, and the wiki fails to mention it. I think I'll add a note to the initramfs page when I have the time.
Comment by Eli Schwartz (eschwartz) - Sunday, 16 July 2017, 03:37 GMT
The default mkinitcpio preset (`mkinitcpio -p linux`) is for the linux 4.11.9-1 package, you should have used the linux-lts preset for the linux-lts kernel.

Actually, you should use `mkinitcpio --allpresets` when you change your mkinitcpio.conf, to ensure that any kernel packages that you have installed will notice the changes you make.

...

Also note that there are no "kernel-4.xxx.img"s at all, lts or otherwise, since Arch does not include the version in the filenames and also doesn't use the word "kernel".
Comment by Xander (wxwilcke) - Sunday, 16 July 2017, 17:10 GMT
> Also note that there are no "kernel-4.xxx.img"s at all, lts or otherwise, since Arch does not include the version in the filenames and also doesn't use the word "kernel".
True, I didn't have time to check when I wrote my post.

> The default mkinitcpio preset (`mkinitcpio -p linux`) is for the linux 4.11.9-1 package, you should have used the linux-lts preset for the linux-lts kernel.
> Actually, you should use `mkinitcpio --allpresets` when you change your mkinitcpio.conf, to ensure that any kernel packages that you have installed will notice the changes you make.
Might be, but the 'mkinitcpio' wiki fails to mention anything other than the 'linux' preset (and custom presets). As the 'linux' preset is also used in the install guide, it makes it appear as if that preset is all you will ever need. At least, after 5+ years of using Arch, and after regenerating the initramfs frequently enough, I never knew that I was just creation an image that I was never going to use. I guess weekly system updates (ie kernel updates) prevented me from finding out.
Comment by Eli Schwartz (eschwartz) - Sunday, 16 July 2017, 17:30 GMT
"For the stock Arch Linux kernel [...] `mkinitcpio -p linux`" and "The -p switch specifies a preset to utilize; most kernel packages provide a related mkinitcpio preset file" wasn't clear enough? Okay, it's a wiki -- what would you suggest instead?

None of that involves intimidating warnings about linux-lts which is not installed by default and therefore cannot be booted into by default.

EDIT: I reverted your edit and added some clarification as to how presets work, hopefully this helps.
Comment by Xander (wxwilcke) - Sunday, 16 July 2017, 17:50 GMT
> None of that involves intimidating warnings about linux-lts which is not installed by default and therefore cannot be booted into by default.

Are you sure about that? I did a fresh install two weeks ago and ended up with the lts installed and set as default. Save from the use of dm-crypt and lvm, I never deviated from the guide nor did I alter Grub's configuration.

Anyway, this discussion doesn't fit in this thread so I'll leave this be then and just assume that I somehow made an error during install. As the 'linux' preset is the default one apparently, nothing should be changed in the wiki.
Comment by Eli Schwartz (eschwartz) - Sunday, 16 July 2017, 18:16 GMT
FS#28081 but linux-lts still isn't *installed* by default (the Installation guide references the installation of the base group, which contains linux but not linux-lts).

Loading...