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?
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.
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
Are there any security downsides when loading these modules during the boot process?
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?
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.
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.
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:
There should be listed the driver for the hub, for the keyboard and sort of.
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?
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.