+++ This bug was initially created as a clone of Bug #1229650 +++ +++ 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. --- Additional comment from 3ndymion on 2015-06-12 10:16:27 EDT --- 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. : ) --- Additional comment from Steeve McCauley on 2015-06-12 10:56:49 EDT --- 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? --- Additional comment from 3ndymion on 2015-06-12 11:57:49 EDT --- (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. --- Additional comment from Steeve McCauley on 2015-06-12 12:11:46 EDT --- (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. --- Additional comment from 3ndymion on 2015-06-13 08:15:50 EDT --- (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. --- Additional comment from Fedora Update System on 2015-06-16 09:05:48 EDT --- dracut-041-14.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dracut-041-14.fc22
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.