Arch Linux

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?

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?

> how would I go about doing that?
One solution would be to call lsmod from a cleanup hook and write to /run.

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.

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.

Is this still a problem with kernel 3.15?

I haven't looked into it yet. I will make some time, try it out again and let you know.

Same problem here with a fresh install, with an asus laptop UX303LN and an integrated keyboard.

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.

> 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.

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.

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...

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 ...

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

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.

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.

> 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.

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.

> 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).

@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 :-)

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

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.

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".

> 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.

"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.

> 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.

 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).