+++ This bug was initially created as a clone of Bug #1204392 +++ Description of problem: I use a wireless keyboard K330 from Logitech. Also I use dm-crypt. When I start my PC the keyboard does not work for entering the dm-crpyt passwphrase.This happend to me today after updating to kernel 3.19. Version-Release number of selected component (if applicable): 3.19.1-201.fc21.x86_64 How reproducible: Use kernel 3.19.1-201.fc21.x86_64. It still works correctly with 3.18.9-200.fc21.x86_64. Steps to Reproduce: 1. Use a Linux system which asks for a dm-crypt (luks) passphrase while booting. 2. Use a K300 Logitech wireless keyboard. 3. Boot the PC and try to enter the passphrase. Actual results: No characters (dots) appear. You cannot enter the passphrase. Expected results: It should be possible to enter the passphrase. Additional info: This is the second time there was a bad surprise for dm-crypt after a kernel update this year (first surprise was that the keyboard layout was suddenly German instead of English). --- Additional comment from Frank Ansari on 2015-03-21 11:40:34 EDT --- I also tried to rebuild the initramfs (using kernel-install). But the result is the same. --- Additional comment from Frank Ansari on 2015-03-21 12:32:09 EDT --- Sorry, typo in the description. It is K330 (not K300). Maybe all wireless keyboards will fail - but I just have this one for testing. --- Additional comment from Thomas Howard on 2015-03-23 01:40:00 EDT --- This is affecting me since the update to kernel 3.19.1-201, also. Though I am using a Logitech MK700 Keyboard and a Logitech M705 connected to the same receiver. --- Additional comment from Thomas Howard on 2015-03-23 02:17:20 EDT --- Adding "hid-logitech-hidpp" to my additional drivers in /etc/dracut.conf and rebuilding my initramfs seems to have fixed this for me. --- Additional comment from Frank Ansari on 2015-03-23 16:02:25 EDT --- Yes, I can confirm this. With this configuration it is working on my system too. Remains the question: why was this removed? Is this a bug or a feature? --- Additional comment from wintonian on 2015-03-24 11:11:08 EDT --- Also broken in 3.19.2-201 for me and another user (as reported on Fedoraforum I won't link as nothing useful is said the the thread) --- Additional comment from wintonian on 2015-03-24 11:14:13 EDT --- Apologies forgot to mention I'm using a K750 --- Additional comment from Boricua on 2015-03-26 08:50:55 EDT --- I am the other FedoraForum user mentioned by wintonian. Mine is a Logitech K350. It does not work at cryptsetup with current kernel 3.19.1-201.fc21.x86_64. I also tried kernel 3.19.2-200.fc21.x86_64 from the testing repo, with the same negative result. --- Additional comment from Eric Smith on 2015-03-30 06:06:21 EDT --- This happens whenever the kernel modules needed for the Logitech receivers change. It happened with kernel 3.2 (bug #786303), and now it's happened again with 3.19, which now requires the hid-logitech-hidpp module. Thomas provided the workaround in comment 4 above, but the fix requires a patch to the dracut package to /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh to add hid-logitech-hidpp after hid-logitech-dj. --- Additional comment from wintonian on 2015-03-30 14:37:16 EDT --- That worked for 3.19.2-201 (and beyond I will assume), thank you. I still hope someone will find time to issue an update or at least have it fixed for F22 release? As there is quite enough tinkering to do on a clean install to get basic functionality (mainly thinking about propitiatory graphic drivers), as it is. --- Additional comment from Carrot Cruncher on 2015-03-30 16:22:21 EDT --- I'm having problems with a Logitech K520 keyboard. I've tried both the "amending the /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh script" option and the "adding the driver to /etc/dracut.conf" option but, while I see the driver listed in the new initramfs: lsinitrd /boot/initramfs-3.19.2-201.fc21.x86_64.img | grep logitech -rw-r--r-- 1 root root 6996 Mar 24 03:48 usr/lib/modules/3.19.2-201.fc21.x86_64/kernel/drivers/hid/hid-logitech-dj.ko.xz -rw-r--r-- 1 root root 7060 Mar 24 03:49 usr/lib/modules/3.19.2-201.fc21.x86_64/kernel/drivers/hid/hid-logitech-hidpp.ko.xz I still get no response from the keyboard during boot. --- Additional comment from Carrot Cruncher on 2015-04-01 05:07:27 EDT --- (In reply to Carrot Cruncher from comment #11) > I'm having problems with a Logitech K520 keyboard. I've tried both the > "amending the /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh > script" option and the "adding the driver to /etc/dracut.conf" option but, > while I see the driver listed in the new initramfs: > > lsinitrd /boot/initramfs-3.19.2-201.fc21.x86_64.img | grep logitech > -rw-r--r-- 1 root root 6996 Mar 24 03:48 > usr/lib/modules/3.19.2-201.fc21.x86_64/kernel/drivers/hid/hid-logitech-dj.ko. > xz > -rw-r--r-- 1 root root 7060 Mar 24 03:49 > usr/lib/modules/3.19.2-201.fc21.x86_64/kernel/drivers/hid/hid-logitech-hidpp. > ko.xz > > I still get no response from the keyboard during boot. Not sure what has changed but I've just tried it again and it is working now. Apologies for the confusion. --- Additional comment from Steven Pehrson on 2015-04-01 12:08:12 EDT --- (In reply to Thomas Howard from comment #4) > Adding "hid-logitech-hidpp" to my additional drivers in /etc/dracut.conf and > rebuilding my initramfs seems to have fixed this for me. This workaround worked for me too, thanks! Steps: 1) sudo vi /etc/dracut.conf modification: add_drivers+="hid-logitech-hidpp" 2) cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak 3) dracut -f 4) reboot --- Additional comment from Frank Ansari on 2015-04-01 15:11:07 EDT --- (In reply to Eric Smith from comment #9) > This happens whenever the kernel modules needed for the Logitech receivers > change. It happened with kernel 3.2 (bug #786303), and now it's happened > again with 3.19, which now requires the hid-logitech-hidpp module. > > Thomas provided the workaround in comment 4 above, but the fix requires a > patch to the dracut package to > /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh to add > hid-logitech-hidpp after hid-logitech-dj. For me both solutions work indepedently. When I add the driver to module-setup.sh and remove it from dracut.conf it works and vice versa. --- Additional comment from Illya on 2015-04-02 04:23:14 EDT --- Same problem with K710 keyboard and 3.19.3-200.fc21.x86_64 kernel. Workaround from comment 13 solves this. Thanks! --- Additional comment from Boricua on 2015-04-20 18:00:49 EDT --- Just to report that I upgraded to Fedora 22 Beta RC3, updated to kernel 4.0.0-1 and found the same issue. --- Additional comment from Harald Hoyer on 2015-04-23 07:49:05 EDT --- http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=180e9d78516fb4b2ee5baef44521007a860d4dd2 --- Additional comment from Steeve McCauley on 2015-05-05 12:29:44 EDT --- (In reply to Steven Pehrson from comment #13) > (In reply to Thomas Howard from comment #4) > > Adding "hid-logitech-hidpp" to my additional drivers in /etc/dracut.conf and > > rebuilding my initramfs seems to have fixed this for me. > > This workaround worked for me too, thanks! > > Steps: > 1) sudo vi /etc/dracut.conf > modification: add_drivers+="hid-logitech-hidpp" > 2) cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak > 3) dracut -f > 4) reboot This also worked for me, although I had to rebuild a different kernel I was running an older kernel that wasn't affected by the issue. To rebuild for a newer kernel version, $ sudo dracut -f /boot/initramfs-3.19.5-200.fc21.x86_64.img 3.19.5-200.fc21.x86_64 After reboot I was able to enter the Luks password and boot without problems, and the HID++ multi-touch features of the new driver seem to be working well. --- Additional comment from Chris Bredesen on 2015-05-16 12:45:33 EDT --- The workaround in comment 13 also worked for me but it's not clear in which version this will be fixed. Does the dracut fix persist across newer kernels? Thanks for the help folks. --- Additional comment from Fedora Update System on 2015-05-18 08:17:59 EDT --- dracut-038-39.git20150518.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dracut-038-39.git20150518.fc21 --- Additional comment from Fedora Update System on 2015-05-19 12:21:05 EDT --- Package dracut-038-39.git20150518.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-038-39.git20150518.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8504/dracut-038-39.git20150518.fc21 then log in and leave karma (feedback). --- Additional comment from Fedora Update System on 2015-05-21 13:36:40 EDT --- dracut-038-39.git20150518.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from Aniruddha on 2015-05-27 12:39:40 EDT --- I have the same problem with a Logitech K800 on Fedora 22 with dracut 041, release 10.fc22.1, kernel 4.0.4-301.fc22.x86_64. --- Additional comment from Frank Ansari on 2015-05-28 06:02:08 EDT --- Please let me add that I had the same issue while using fedup to update to 22. Only option was to use my USB keyboard to open the HDD. --- Additional comment from Joe Spencer on 2015-05-30 09:49:12 EDT --- This is why I love open source. Had the same issue with my K520, did some googling, arrived here, tried the solution posted in comment #4 and voila! For those arriving here needing more guidance, this worked for me (fedora 20): 1. vim /etc/dracut.conf 2. uncomment add_drivers and add hid-logitech-hidpp 3. save the file 4. sudo dracut -f 5. reboot --- Additional comment from Chris Bredesen on 2015-05-31 13:50:47 EDT --- This was definitely fixed for me in F-21. Did the patch not go into rawhide/22? --- Additional comment from Steeve McCauley on 2015-05-31 15:54:03 EDT --- I think I got bit by this using fedup to upgrade f21 to f22. $ lsinitrd initramfs-fedup.img | grep logitech -rw-r--r-- 1 root root 6956 May 21 09:57 usr/lib/modules/4.0.4-301.fc22.x86_64/kernel/drivers/hid/hid-logitech-dj.ko.xz Got to the LUKs prompt and keyboard didn't work on my logitech K520 keyboard, which fortunately had never been prone to this particular issue in any of the F21 kernels. I don't have a USB keyboard so I had to bail from the upgrade so cannot tell if it's just the initramfs-fedup image or whether it's a more general problem with f22. Regardless it looks like the hid-logitech-hidpp module is missing in this image.
Hi. I also have this problem, & looks like it's an easy fix that's already been done for Fedora 21. I'm running Fedora 22 KDE stable. Is there any way we can get this fix updated for Fedora 22 as well??? It would be very greatly appreciated. This problem seems to affect all current Fedora versions, so it would be best if this fix could somehow be pushed to all current & future versions of Fedora, including beta versions & whatever else. Thanks in advance. : )
I can verify that the initramfs-fedup image does not contain the hid-logitech-hidpp kernel module, and so the luks prompt doesn't work with a wireless logitech keyboard (had to plug in a usb keyboard to continue). But the Fedora 22 kernels installed by the update do work as expected (for me) with the wireless keyboard. This happened on both of my systems with logitech wireless keyboards. This is a fedup issue, should I file another bug?
(In reply to Steeve McCauley from comment #2) > I can verify that the initramfs-fedup image does not contain the > hid-logitech-hidpp kernel module, and so the luks prompt doesn't work with a > wireless logitech keyboard (had to plug in a usb keyboard to continue). But > the Fedora 22 kernels installed by the update do work as expected (for me) > with the wireless keyboard. > > This happened on both of my systems with logitech wireless keyboards. > > This is a fedup issue, should I file another bug? That's good information. To add to that, I have only done clean, brand new installs of F22 KDE, & the Logitech wireless keyboard doesn't work. I don't think it is limited to that fedup upgrade thing. I don't know if anyone else noticed, but also part of this same problem, is that in the running OS, the battery widget is unable to display the battery levels for the Logitech wireless keyboard & mouse. They function like normal, but the OS doesn't seem to be able to see their power levels.
(In reply to 3ndymion from comment #3) > (In reply to Steeve McCauley from comment #2) > > I can verify that the initramfs-fedup image does not contain the > > hid-logitech-hidpp kernel module, and so the luks prompt doesn't work with a > > wireless logitech keyboard (had to plug in a usb keyboard to continue). But > > the Fedora 22 kernels installed by the update do work as expected (for me) > > with the wireless keyboard. > > > > This happened on both of my systems with logitech wireless keyboards. > > > > This is a fedup issue, should I file another bug? > > That's good information. To add to that, I have only done clean, brand new > installs of F22 KDE, & the Logitech wireless keyboard doesn't work. I don't > think it is limited to that fedup upgrade thing. > > I don't know if anyone else noticed, but also part of this same problem, is > that in the running OS, the battery widget is unable to display the battery > levels for the Logitech wireless keyboard & mouse. They function like > normal, but the OS doesn't seem to be able to see their power levels. Do you see the hid-logitech-hidpp kernel module installed? I see the following on all of my F22 systems wtihout any hacking of dracut.conf $ lsmod | grep logitech hid_logitech_hidpp 20480 0 hid_logitech_dj 20480 0 Maybe your issue is related to KDE, I'm running gnome-shell so I can't say.
(In reply to Steeve McCauley from comment #4) > Do you see the hid-logitech-hidpp kernel module installed? I see the > following on all of my F22 systems wtihout any hacking of dracut.conf > > $ lsmod | grep logitech > hid_logitech_hidpp 20480 0 > hid_logitech_dj 20480 0 > > Maybe your issue is related to KDE, I'm running gnome-shell so I can't say. Here is mine: $ lsmod | grep logitech hid_logitech_hidpp 20480 0 hid_logitech_dj 20480 0 Looks like both kernel modules are indeed there. This is from a new, clean install of F22 KDE stable. I did not add them in myself.
dracut-041-14.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dracut-041-14.fc22
Has anybody tested this yet??? Will it get pushed through only after people have tested & leave feedback??? It's a bit confusing to me. Not only that, but the links showing how to test it refer to Fedora 11.
Package dracut-041-14.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-041-14.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10407/dracut-041-14.fc22 then log in and leave karma (feedback).
(In reply to Fedora Update System from comment #8) > Package dracut-041-14.fc22: ... > Update it with: > # su -c 'yum update --enablerepo=updates-testing dracut-041-14.fc22' ... OK, so I did this, & it didn't work. HOWEVER, the next day, I got a bunch of new updates, including kernel upgrade to 4.0.5-300.fc22.x86_64 from 4.0.4-303.fc22.x86_64, & with the new kernel, it works!!! It does NOT work on the old kernel, but since kernels are usually updated, perhaps this won't be an issue to most??? I thought the fix would work by itself, but I don't really know anything about this dracut. With the new kernel, the keyboard works for the LUKS password screen, & the keyboard & mouse power levels are shown in the running OS. All is well. Thank you to whoever did this, & to all for reporting. : )
Created attachment 1041856 [details] Picture of desktop showing that the wireless keyboard & mouse power levels are shown now.
Mine also works as described in comment 9. I do not have the neat GNOME shell integration like described in comment 10 but that's another discussion. Thanks all!
(In reply to 3ndymion from comment #9) > (In reply to Fedora Update System from comment #8) > > Package dracut-041-14.fc22: > ... > > Update it with: > > # su -c 'yum update --enablerepo=updates-testing dracut-041-14.fc22' > ... > > OK, so I did this, & it didn't work. HOWEVER, the next day, I got a bunch > of new updates, including kernel upgrade to 4.0.5-300.fc22.x86_64 from > 4.0.4-303.fc22.x86_64, & with the new kernel, it works!!! It does NOT work > on the old kernel, but since kernels are usually updated, perhaps this won't > be an issue to most??? I thought the fix would work by itself, but I don't > really know anything about this dracut. With the new kernel, the keyboard > works for the LUKS password screen, & the keyboard & mouse power levels are > shown in the running OS. All is well. Thank you to whoever did this, & to > all for reporting. : ) You do need to run "# dracut -f /boot/initramfs-4.0.5-300.fc22.x86_64.img 4.0.5-300.fc22.x86_64" (replace '4.0.5-300.fc22.x86_64' with the relevant kernel version, or just use "# dracut -f" for the currently running one) to build it in to the initramfs. The reason it works for the newer kernel is that the system has to build one for the newer kernel anyway as the initramfs doesn't exist for it. At least that is my rudimentary understanding. Or just patch the script by hand (and then rebuild the initramfs) I can attest to this working in F22. As @Eric Smith above states: "Thomas provided the workaround in comment 4 above, but the fix requires a patch to the dracut package to /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh to add hid-logitech-hidpp after hid-logitech-dj."
(In reply to wintonian from comment #12) > You do need to run "# dracut -f /boot/initramfs-4.0.5-300.fc22.x86_64.img > 4.0.5-300.fc22.x86_64" (replace '4.0.5-300.fc22.x86_64' with the relevant > kernel version, or just use "# dracut -f" for the currently running one) to > build it in to the initramfs. The reason it works for the newer kernel is > that the system has to build one for the newer kernel anyway as the > initramfs doesn't exist for it. > Another shortcut: # dracut --regenerate-all --force
(In reply to wintonian from comment #12) > You do need to run "# dracut -f /boot/initramfs-4.0.5-300.fc22.x86_64.img > 4.0.5-300.fc22.x86_64" (replace '4.0.5-300.fc22.x86_64' with the relevant > kernel version, or just use "# dracut -f" for the currently running one) to > build it in to the initramfs. The reason it works for the newer kernel is > that the system has to build one for the newer kernel anyway as the > initramfs doesn't exist for it. > > At least that is my rudimentary understanding. > > > Or just patch the script by hand (and then rebuild the initramfs) I can > attest to this working in F22. > > As @Eric Smith above states: > "Thomas provided the workaround in comment 4 above, but the fix requires a > patch to the dracut package to > /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh to add > hid-logitech-hidpp after hid-logitech-dj." (In reply to Harald Hoyer from comment #13) > Another shortcut: > > # dracut --regenerate-all --force Much thanks for that guys. I didn't know how to go about rebuilding the initramfs, but now I do. There's much I need to learn. I did this for the old kernel, & it works on the 1st try. So I was quite wrong about it not working before. It all works perfectly fine on the old kernel once the rebuild is done. Thanks again!!! : ) (In reply to Chris Bredesen from comment #11) > Mine also works as described in comment 9. I do not have the neat GNOME > shell integration like described in comment 10 but that's another > discussion. Thanks all! Actually, I'm using the KDE desktop, & not Gnome. KDE5 is still full of bugs & problems right now, but it's slowly shaping up & getting better. Despite it still being in its infancy, it sure is looking really nice.
dracut-041-14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.