No wireless keyboard during boot, after update to kernel 3.11

I updated to kernel-default-3.11 today. After the update, I am unable to use my Logitech wireless keyboard, but only when prompted for my pass-code to unlock my encrypted system volume.

The keyboard works during POST, and works at the grub menu (I use legacy grub if it makes a difference). When prompted for my crypt-setup pass-code, the wireless keyboard does not work and I am forced to plug in an old PS2 keyboard, just for the pass-code. Once the drive is unlocked, the keyboard remains dead until later in the boot process. When KDM starts, the keyboard works as it should.

I am not sure if this is a problem with the new kernel, a problem with mkinitrd, or maybe a problem with cryptsetup-mkinitrd.

I’ll post the outputs of the commands I have run so far:

   ronnie@Opto:~> lsusb
 Bus 001 Device 003: ID 050d:0237 Belkin Components F5U237 USB 2.0 7-Port Hub
 Bus 002 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 004: ID 050d:0237 Belkin Components F5U237 USB 2.0 7-Port Hub
 Bus 001 Device 005: ID 06a3:0460 Saitek PLC ST290 Pro Flight Stick
 Bus 001 Device 006: ID 054c:002c Sony Corp. USB Floppy Disk Drive
 Bus 001 Device 007: ID 046d:c242 Logitech, Inc.  

 ronnie@Opto:~> lsmod | grep usb
 usb_storage            62063  0  
 usbhid                     53007  0  
 usbcore                 241252  7 xpad,usb_storage,ohci_pci,ohci_hcd,ehci_pci,ehci_hcd,usbhid
 usb_common          13057  1 usbcore


 ronnie@Opto:~> lsmod | grep logitech
 hid_logitech_dj        18604  0  

In the output of lsmod, it apperas that usbhid and hid_logitech_dj are loaded, but not being used, even though the wireless keyboard works correctly.
I use an older motherboard that is not USB 3 capable. It has worked perfectly until the kernel upgrade today, along with re-installing the ATI proprietary driver after the kernel upgrade.

Since I am still able to get into my system, I’ll keep this kernel rather than downgrading. If anyone has any troubleshooting suggestions, I’ll be able to comply.

There’s probably a module that you need to force into the “initrd”.

solution on this pc was to deselect legacy usb support in bios


I had already tried forcing modules into the initrd. I also unplugged and re-plugged the keyboard while the system was up, followed by mkinitrd; hoping that would cause all currently loaded modules into the initrd. Since I only lose the keyboard after I choose an item from the grub menu, and since I have been using this computer without problems before the kernel upgrade, I can only assume that BIOS is not the problem.

yes, that was what my logical conclusion too

with every earlier kernel, usb legacy has been enabled in this pc’s bios without any problem,
also no hardware changes since purchase


original info came from nrickert see

Here’s the difference.

For your problem, you indicated no keyboard with grub.

But purevw is saying that grub is okay, and it is after the kernel has loaded that the keyboard doesn’t work.

Grub is accessing the keyboard with BIOS calls, which seem to be working.

The loaded kernel does it directly. It eventually works, but not at first.

The sequence is (as far as I know)

grub accesses keyboard with BIOS calls – this works.

kernel accesses keyboard directly – this does not work.

after the crypto setup, kernel can load additional modules. And then keyboard works.

That’s why it looks to me as if something more is needed in the “initrd” so that the kernel has earlier use of whatever is needed.

I may have a clue. Is it possible that the newest mkinitrd is not fully compatible with kernel-default-3.11? Here is a short clip of the output of mkinitrd -v:

[MODULES] thermal processor fan
[MODULES] sata_nv pata_amd ata_generic usbhid usbcore usb_common hid_logitech_dj
[MODULES] dm-mod
[MODULES] dm-snapshot
[MODULES] dm-crypt
[MODULES] rtc_cmos
[MODULES] scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua
[MODULES] reiserfs
[MODULES] fglrx
[MODULES] sata_nv
[MODULES] usbcore
[MODULES] ohci_hcd
[MODULES] uhci-hcd
[MODULES] ehci_hcd
[MODULES] xhci-hcd
[MODULES] usbhid
[MODULES] hid-logitech-dj
[MODULES] hid-generic
[MODULES] hid-holtek-kbd
[MODULES] hid-lenovo-tpkbd
[MODULES] hid-logitech-dj
[MODULES] hid-ortek
[MODULES] hid-roccat-arvo
[MODULES] hid-roccat-isku
[MODULES] hid-samsung
[MODULES] hid-apple
[MODULES] hid-belkin
[MODULES] hid-cherry
[MODULES] hid-ezkey
[MODULES] hid-microsoft
[MODULES] linear
[MODULES] dm-crypt
[MODULES] sha256_generic sha256_generic cbc cryptomgr
[MODULES]       Unsupported kernel (3.11.0-1.g16dd1ca-default)
Kernel Modules: thermal_sys thermal processor fan sata_nv pata_amd ata_generic usb-common usbcore usbhid hid-logitech-dj dm-mod dm-snapshot dm-crypt scsi_dh scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua reiserfs button amd_iommu_v2 fglrx ohci-hcd uhci-hcd ehci-hcd xhci-hcd hid-generic hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung linear sha256_generic cbc

I asked the question because of the last [MODULES] line of the output. The repository where I got the kernel is the same repository where I got mkinitrd.


It looks as if “mkinitrd” is making a list of modules used by the running kernel, but apparently does not trust the output because of a version check failure.

You might want to open a bugzilla report (at the opensuse bugzilla). It seems that “mkinitrd” needs updating.

Whether that’s the cause of your problem is a different question, though it very well might be.

I filed a report at bugzilla early this morning. I’ll keep an eye on that report and also for pertinent updates. Thanks to all.