Description of problem: After installing 3.19 kernel update, the keyboard (Logitech k400 wireless) doesn't work at boot time. It is usable in grub menu, but cannot introduce LUKS password. No response at all. Version-Release number of selected component (if applicable): 3.19.0-0.rc7.2.mga5 How reproducible: Not sure if it's keyboard model specific or something in dracut, with 3.18.3 kernel it worked without problem. Steps to Reproduce: 1. Update kernel to 3.19 2. Reboot to new kernel 3. Try to use keyboard after grub menu. Reproducible: Steps to Reproduce:
Similar problem in Kali Linux and kernel 3.18, related to initramfs-tools: https://bugs.kali.org/view.php?id=2043
Still valid with kernel-3.19.0-0.rc7.3
Severity: normal => major
Keywords: (none) => TriagedAssignee: bugsquad => tmb
Maybe dracut doesn't include a HID module that is new in 3.19? Though udev should have loaded it later Can you attach (not paste) the output of the "lspcidrake -v" command (from another kernel obviously). Actually, if you can ssh to your machine when it boots the 3.19 kernel, if you could attach "lspcidrake -v" output for 3.19 too that would help. We could then compare lspcidrake output for 3.18 & 3.19
Keywords: (none) => NEEDINFOCC: (none) => mageia, thierry.vignaudSource RPM: kernel-3.19.0-0.rc7.2.mga5.src.rpm => kernel-3.19.0-0.rc7.2.mga5.src.rpm, dracut
Created attachment 5864 [details] 'lspcidrake -v' from a running kernel-3.17.2-desktop-3 Cannot currently boot with 3.19 kernel due to the impossibility to introduce LUKS password at boot, will try to create an USB contained key to boot.
Can you attach output of lsinitrd /boot/initrd-3.19.0-desktop-0.rc7.3.mga5.img and lsinitrd /boot/initrd-3.17.2-desktop-3.mga5.img
Created attachment 5865 [details] lsinitrd from /boot/initrd-3.17.2-desktop-3.mga5.img
Created attachment 5866 [details] lsinitrd from /boot/initrd-3.19.0-desktop-0.rc7.3
Can you add an lsinitrd for the working 3.18.3 too ? the 3.17 one looks like a --hostonly=no initrd with a lot of extra... the same hid drivers are in both... One thing, can you try to add the hid-logitech-hidpp to the 3.19 initrd move old initrd to safety: mv /boot/initrd-3.19.0-desktop-0.rc7.3.mga5.img /boot/initrd-3.19.0-desktop-0.rc7.3.mga5.img.old # create new one: dracut -f --add-drivers hid-logitech-hidpp /boot/initrd-3.19.0-desktop-0.rc7.3.mga5.img 3.19.0-desktop-0.rc7.3.mga5 and try to reboot into the 3.19 kernel
Created attachment 5869 [details] lsinitrd from 3.18.3-desktop-2 New initrd created with dracut and added hid-logitech-hidpp doesn't solve the problem (also, boot resolution has changed with it).
Created attachment 5972 [details] lsinitrd from running 3.19.0-4 kernel With 3.19.0-4 kernel and latest dracut the issue seems to have gone, but only after running "dracut --hostonly --force" (I've bought a wired keyboard to do this XD ) The attachment is the lsinitrd for the resulting image.
Can you confirm that when kernel-3.19.0-5.mga5 (currently building) gets installed it works without you having to do any manual initrd creation If so, close this bug as fixed
Nope, this problem persists.
Ok, can you attach lsinitrd from the non-working initrd for 3.19.0-5 and then regenerate the initrd with the above "dracut --hostonly --force", and if that initrd works, attach the lsinitrd from that one so we can compare what gets missed
Created attachment 5986 [details] lsinitrd from 3.19.0-desktop-5 before rebuilding
Created attachment 5987 [details] lsinitrd from 3.19.0-desktop-5 after rebuilding, with working keyboard
Ok, so now I'm confused... the specific difference between comment 14 and comment 15 is exactly that missing hid-logitech-hidpp module. And that one I added in the dracut-038-12.mga5 package: http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0521-kernel-modules-hid-logitech-hidpp.patch?revision=817174&view=markup wich kernel 3.19.0-5 has a requires(pre) on. @colin: any thoughts on why it does not get added on kernel install time, but gets added on manual install ? dracut.conf states hostonly="yes" and that is the same as the above --hostonly
With kernel 3.19.0-6 the issue is not present and the keyboard works without further intervention. Can this be closed?
Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED