After an install, with /boot on a regular partition, and / on and encrypted lvm logical volume, using the i586 dvd, when dracut prompts for the passphrase, the keyboard does not respond. My guess is that the usbhid module has not yet been loaded. It is in the initrd file. Reproducible: Steps to Reproduce:
CC: (none) => ennael1Whiteboard: (none) => 4beta1
At 13MB, too large for an attachment here. initrd uploaded to http://www.ody.ca/~dwhodgins/initrd-3.12.0-server-2.mga4.img
Hmm, as udev should be loading the modules, it should quite happily install this module for you. I suspect perhaps that the specific usb host driver is not installed. Can you play with the various rd.break= options to double check you can use your keyboard OK prior to mounting? e.g. rd.break=pre-mount If you cannot use your keyboard at this point, then can you check via some other kind of keyboard if this helps and perhaps try and pin down which driver is missing from the initrd to make things work. Also, is plymouth working here? It's got a mode to ask for the passphrase, so perhaps the problem is that there is no plymouth module and and there is no text based password mechanism working? Perhaps we need the tty-password agent stuff? I've not looked at this for a couple releases myself so am a bit out of touch with how things *should* be working!
None of the rd.break options provide a working keyboard (usb wireless), but using a ps/2 keyboard does work. According to harddrake2, the keyboard is handled by usbhid, which is in the initrd. # lsinitrd initrd-3.12.0-server-2.mga4.img |grep hid drwxr-xr-x 3 root root 0 Nov 11 11:17 usr/lib/modules/3.12.0-server-2.mga4/kernel/drivers/hid -rw-r--r-- 1 root root 1012 Nov 8 17:46 usr/lib/modules/3.12.0-server-2.mga4/kernel/drivers/hid/hid-generic.ko.xz -rw-r--r-- 1 root root 32676 Nov 8 17:46 usr/lib/modules/3.12.0-server-2.mga4/kernel/drivers/hid/hid.ko.xz -rw-r--r-- 1 root root 6516 Nov 8 17:46 usr/lib/modules/3.12.0-server-2.mga4/kernel/drivers/hid/hid-logitech-dj.ko.xz drwxr-xr-x 2 root root 0 Nov 11 11:17 usr/lib/modules/3.12.0-server-2.mga4/kernel/drivers/hid/usbhid -rw-r--r-- 1 root root 22356 Nov 8 17:46 usr/lib/modules/3.12.0-server-2.mga4/kernel/drivers/hid/usbhid/usbhid.ko.xz In Mageia 3, usbhid gets loaded by /lib/udev/rules.d/42-usb-hid-pm.rules, which is not in the initrd lsinitrd ./initrd-3.12.0-server-2.mga4.img |grep rules drwxr-xr-x 2 root root 0 Nov 11 11:17 etc/udev/rules.d -rw-r--r-- 1 root root 168 Oct 8 03:55 etc/udev/rules.d/10-console.rules -rw-r--r-- 1 root root 142 Oct 8 03:55 etc/udev/rules.d/11-dm.rules -rw-r--r-- 1 root root 681 Nov 11 11:17 etc/udev/rules.d/59-persistent-storage-dm.rules -rw-r--r-- 1 root root 298 Nov 11 11:17 etc/udev/rules.d/59-persistent-storage.rules -rw-r--r-- 1 root root 1031 Nov 11 11:17 etc/udev/rules.d/61-persistent-storage.rules -rw-r--r-- 1 root root 776 Oct 8 03:55 etc/udev/rules.d/64-lvm.rules -rwxr-xr-x 1 root root 894 Nov 9 11:45 usr/lib/dracut/hooks/pre-udev/30-block-genrules.sh drwxr-xr-x 2 root root 0 Nov 11 11:17 usr/lib/udev/rules.d -rw-r--r-- 1 root root 6960 Oct 21 19:27 usr/lib/udev/rules.d/10-dm.rules -rw-r--r-- 1 root root 1303 Oct 21 19:27 usr/lib/udev/rules.d/11-dm-lvm.rules -rw-r--r-- 1 root root 1446 Oct 21 19:27 usr/lib/udev/rules.d/13-dm-disk.rules -rw-r--r-- 1 root root 121 Oct 31 06:38 usr/lib/udev/rules.d/50-firmware.rules -rw-r--r-- 1 root root 3074 Oct 31 06:38 usr/lib/udev/rules.d/50-udev-default.rules -rw-r--r-- 1 root root 5465 Oct 31 06:38 usr/lib/udev/rules.d/60-persistent-storage.rules -rw-r--r-- 1 root root 452 Oct 31 06:38 usr/lib/udev/rules.d/75-net-description.rules -rw-r--r-- 1 root root 1245 Oct 31 06:38 usr/lib/udev/rules.d/80-drivers.rules -rw-r--r-- 1 root root 491 Oct 31 06:38 usr/lib/udev/rules.d/80-net-name-slot.rules -rw-r--r-- 1 root root 479 Oct 21 19:27 usr/lib/udev/rules.d/95-dm-notify.rules -rw-r--r-- 1 root root 155 Oct 31 06:38 usr/lib/udev/rules.d/95-udev-late.rules So it looks like it's a missing udev rule, rather then a missing module.
May also be 95-keymap.rules, which appears to handle the Logitech USB Receiver.
The PM rules don't look important, but I suspect your 95-keymap.rules are... That said, this stuff has likely all been converted to hwdb now.. it's maybe some problem with that conversion. I guess the initrd does contain the hwdb stuff? Probably worth checking this model was converted properly upstream (I don't see it being grepped properly but as I'm guessing it works OK on your regular cauldron system then perhaps we do need to look at hwdb info getting into the initrd properly.
It works fine, if the root filesystem is not encrypted. lsusb shows ID 046d:c52b Logitech, Inc. Unifying Receiver In Mageia 4, usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb has usb:v046DpC52B* ID_MODEL_FROM_DATABASE=Unifying Receiver but there are no hwdb files in the initrd.
(In reply to Dave Hodgins from comment #6) > It works fine, if the root filesystem is not encrypted. lsusb shows > ID 046d:c52b Logitech, Inc. Unifying Receiver I suspect you mean it works fine once the system has booted properly - I'd guess any rd.break= passed would still give a shell that is just as broken? > In Mageia 4, usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb has > usb:v046DpC52B* > ID_MODEL_FROM_DATABASE=Unifying Receiver > but there are no hwdb files in the initrd. Ahh, therein lies the problem :( Will speak to upstream about how to handle this as I don't like the idea of passing in the full 5.6MB /etc/udev/hwdb.bin file I have on my machine to the initrd. As a test, can you build an initrd with this file included? (just pass "-I /etc/udev/hwdb.bin" when calling dracut and see if it helps? You can do it on the unencrypted one if it's easier and test via an appropriate rd.break to make sure the keyboard is working? I'm guessing we'll just need to patch dracut to whitelist a few hwdb.d/ files and then run the script to generate the hwdb.bin for the initrd. Hopefully it'll be a lot smaller than 5.6MB once we only include the things we really need.
I've added support to dracut to do this, but even just including the 20-usb-vender-model.hwdb creates a hwdb.bin file of 1.5Mb which is IMO still too large. This is likely due to the file containing a lot of stuff unrelated to keyboards. I've asked upstream if we can split this file out into keyboard+other for this use case.
OK, so upstream reckon it shouldn't be needed, so including the hwdb.bin shouldn't actually be needed. Can you double check again that the correct USB host drivers are included (e.g. uhci ohci stuff etc.) and also check if just modprobing the usbhid module in the initrd from your ps/2 keyboard makes the usb one work OK? If it does, can you experiment if running any particular udevadm trigger commands makes this happen without manual modprobing?
I tried modprobing all of the hid modules, hid_logitech_dj, usbhid, hid, and hid-generic, but the wireless keyboard is still not working.
What about the host drivers tho'? xhci ehci etc. Are they properly included in the initrd? Try and find out the modules loaded after booting and then add them to the initrd with the --add-driver option to see if it makes a difference. Ultimately one of the modules from the system is the one that's making the difference! (unless something strange is going on)
I think I may have found the problem. Using rd.break=initqueue, and using the ps/2 keyboard to modprobe all hcd, hci, and usb modules used in Mageia 3, the usb keyboard is still not working. After using the ps/2 keyboard to enter the passphrase, and get into a working Mageia 4 system, where the keyboard is working, there is an additional hci module, ohci_pci, which is not present in the initrd. I'll try running dracut --add-driver with that module, to see if that fixes the problem.
Confirmed. Running "dracut -f --add-drivers ohci_pci" fixes the problem.
(In reply to Dave Hodgins from comment #13) > Confirmed. Running "dracut -f --add-drivers ohci_pci" fixes the problem. Cool, so my guess in comment 2 was correct afterall when I said: "I suspect perhaps that the specific usb host driver is not installed." :) I'll add the appropriate fix to dracut.
OK, should be fixed in latest dracut. (-10)
Status: NEW => RESOLVEDResolution: (none) => FIXED