How to enable USB keyboard support when booting from an encrypted disk


When I boot my laptop system and have to type my encryption password, the external wireless keyboard does not work, and I have to use the laptop’s keyboard instead. This is rather inconvenient given that I use the laptop almost exclusively with the lid closed, connected to an external display, and external keyboard & mouse (same usb dongle). In addition, the external monitor does not receive the HDMI video input at that stage, but only when the display server starts, so I don’t have any feedback regarding the password prompt or the GRUB menu.

This is in contrast with a Windows 10 laptop in the same setup, which allows me to type the BitLocker password on the wireless keyboard, and see that blue screen directly on the external monitor.

Would it be possible to have the same functionality on the Manjaro laptop?

Thank you

You probably need change mkinitcpio hooks order. Show what you have in /etc/mkinitcpio.conf.

My HOOKS line in mkinitcpio.conf looks like this:
HOOKS=(base udev keyboard autodetect modconf block keymap encrypt filesystems fsck)

Since dmcrypt is part of the initramfs, i would rather say that you need to add the corresponding modules to load them as early as possible.

That can be accomplished at /etc/mkinitcpio.conf on the line MODULES=(). I can’t say which modules you need to load explicitly. lsmod will show you which modules has been loaded. At least the the correct gpu module and the keyboard modules needs to be loaded.

I guess the password input of dmcrypt works by default with the framebuffer without any specific driver.

Thanks for the advice

There are some related discussions here:

Could you please help me identify the correct modules for keyboard and video output support? I can see xhci_pci and usbhid in the output of lsmod.

@bluewhale99 If I had to guess, then I would say:

MODULES=(ohci-pci ehci-pci xhci_pci ohci_hcd ehci_hcd xhci_hcd hid_generic hid usbhid evdev)

The driver for the gpu driver should be added there also.

But well, i am not 100% sure, since i never had this problem.

Thanks @megavolt, I have a few questions here

  1. Is this an issue for every hardware, or is it specific to my laptop? I’ve just noticed the following note on the arch wiki page: If using a keyboard through a USB 3 hub and wish to use it to unlock a LUKS device, add usbhid xhci_hcd
  2. Are there any security downsides when loading these modules during the boot process?
  3. Is there a way to know for sure which modules are required to enable usb keyboard and video support when unlocking a LUKS boot partition?
  1. I guess it is a general problem of laptops which have keyboards integrated (what is commonly for a laptop), thus the driver prefer to use the integrated one and rejects other devices when the modules are not forced to load the driver.

  2. Yes. You could imagine, that if the usb hub is fully activated at the password prompt of dmcrypt, then, if you are smart enough, it could be possible to exploit this connection. Imagine a usb device which aims to be a keyboard can be used to do a brute-force attack, but that is only one possibility. Well, not everyone is so paranoid.

  3. I think the driver for the usb hub and the driver for usb input devices should be enough.

let me explain:

  • ohci → USB1
  • ehci → USB2
  • xhci → USB3
  • usbhid → Core driver for usb input devices
  • hid → generic driver for input devices

To identify which driver needs to be loaded, run this:

lsusb -vt

There should be listed the driver for the hub, for the keyboard and sort of.

Thanks for the explanations @megavolt

Interestingly, lsusb -vt displays one Linux Foundation 3.0 root hub and one Linux Foundation 2.0 root hub, where the USB receiver is connected to the latter, driver=usbhid, whereas the root hubs use the xhci_hcd/6p or /12p driver. (Also, unrelated, the USB3 port has stopped working in Manjaro at least one year ago, only acts as power out). So xhci is compatible with all usb1,2, and 3, not only 3, right?

Is it possible that the fast boot option in BIOS causes the system to skip loading the right usb driver?

Normally USB3 HUBs should support USB3 devices and all below that standard, but the xhci_hcd driver can not be used for a USB1/2 hub, there you must load the correct driver.

I would say no, but possible. “Fast boot” is just a method for partial initialization. It cache init steps, skip them at boot time and read the cached one.

Hmm, the keyboard issue was indeed from the Fast Boot option in BIOS. It now works well with an empty MODULES line in mkinitcpio.conf. I had previously tried to load ehci or usbid as you suggested, but with no success. According to this support page:

Fast Boot is a feature in BIOS that reduces your computer boot time. If Fast Boot is enabled:

    Boot from Network, Optical, and Removable Devices are disabled.
    Video and USB devices (keyboard, mouse, drives) wont be available until the operating system loads.

Although I don’t own a NUC or a Intel Visual Bios device, I thought the same principles may apply.

Now the only issue is that the external monitor only receives the HDMI signal after logging in. Even the Lightdm greeter is still displayed on the laptop monitor alone.

Nice :+1:

Since it is running in basic-video-mode you will need to force the second monitor to use it at the kernel parameter: