Red Hat Bugzilla – Bug 1204392
Wireless keybord K330 Logitech not working for dm-crypt passphrase
Last modified: 2015-06-09 06:45:34 EDT
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):
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.
No characters (dots) appear. You cannot enter the passphrase.
It should be possible to enter the passphrase.
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).
I also tried to rebuild the initramfs (using kernel-install).
But the result is the same.
Sorry, typo in the description. It is K330 (not K300). Maybe all wireless keyboards will fail - but I just have this one for testing.
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.
Adding "hid-logitech-hidpp" to my additional drivers in /etc/dracut.conf and rebuilding my initramfs seems to have fixed this for me.
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?
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)
Apologies forgot to mention I'm using a K750
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.
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.
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.
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.
(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
> -rw-r--r-- 1 root root 7060 Mar 24 03:49
> 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.
(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!
1) sudo vi /etc/dracut.conf
2) cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
3) dracut -f
(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.
Same problem with K710 keyboard and 3.19.3-200.fc21.x86_64 kernel.
Workaround from comment 13 solves this. Thanks!
Just to report that I upgraded to Fedora 22 Beta RC3, updated to kernel 4.0.0-1 and found the same issue.
(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!
> 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.
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.
dracut-038-39.git20150518.fc21 has been submitted as an update for Fedora 21.
* 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:
then log in and leave karma (feedback).
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.
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.
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.
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
This was definitely fixed for me in F-21. Did the patch not go into rawhide/22?
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.