Jump to content
funtoo forums
  • 0
erikr

Keyboard wont work during initramfs execution

Question

Over time I have experienced problem that my keyboard does not work during early boot, the time where I am supposed to make key-map selection on system-rescue-cd, but - more important - at the time I am expected to enter encryption key to unlock my encrypted partitions. If I end up in rescue mode I can't do anything, not even ctrl-alt-delete to reboot.

I have had the problem on my current and previous hardware if I am using debian-sources (4.8 and 4.14). I have this problem with all kernels I have tested with my present hardware (ASUS Prime Z370). 

Naturally it failes with my ordinary logitech k750 keyboard but it also fails with a ordinary plain USB cable connected USB-keyboard.

I have played around with different settings in kernel (gentoo-sources) to build in or not support for USB, logitech modules, the fundamental USB HIDBP, etc and cannot observe any difference during boot (but I managed to disable mouse in KDE).

I can see that the logitech modules are loaded when booting debian-kernel but it still wont work.

This is the latest dmesg where HID is loaded

[    1.239301] hidraw: raw HID events driver (C) Jiri Kosina
[    1.239542] usbcore: registered new interface driver usbhid
[    1.239780] usbhid: USB HID core driver

.
.
.

[   20.619928] logitech-djreceiver 0003:046D:C52B.0003: hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-5.1/input2
[   20.732809] input: Logitech K750 as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.2/0003:046D:C52B.0003/0003:046D:4002.0005/input/input9
[   20.732897] logitech-hidpp-device 0003:046D:4002.0005: input,hidraw2: USB HID v1.11 Keyboard [Logitech K750] on usb-0000:00:14.0-5.1:1
[   21.154637] usbcore: registered new interface driver snd-usb-audio
[   25.298802] logitech-hidpp-device 0003:046D:4002.0005: HID++ 2.0 device connected.

I am quite sure that luks is opened long before the 20 seconds and the HID is hidraw.

The very same rows with the very same keyboard on a working setup where I can enter the password:

One difference I found is that in a working boot (where keyboard is working) the same rows as above seems to happen earlier:

Dec 30 09:20:37 nuffsan kernel: [    2.440038] usb 8-2.1: new full-speed USB device number 4 using xhci_hcd
Dec 30 09:20:37 nuffsan kernel: [    2.624861] usb 8-2.1: New USB device found, idVendor=046d, idProduct=c52b
Dec 30 09:20:37 nuffsan kernel: [    2.624866] usb 8-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Dec 30 09:20:37 nuffsan kernel: [    2.624869] usb 8-2.1: Product: USB Receiver
Dec 30 09:20:37 nuffsan kernel: [    2.624872] usb 8-2.1: Manufacturer: Logitech
Dec 30 09:20:37 nuffsan kernel: [    2.628778] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb8/8-2/8-2.1/8-2.1:1.0/0003:046D:C52B.0001/input/input5
Dec 30 09:20:37 nuffsan kernel: [    2.680543] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input0
Dec 30 09:20:37 nuffsan kernel: [    2.683897] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb8/8-2/8-2.1/8-2.1:1.1/0003:046D:C52B.0002/input/input6
Dec 30 09:20:37 nuffsan kernel: [    2.735411] hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input1
Dec 30 09:20:37 nuffsan kernel: [    2.738136] hid-generic 0003:046D:C52B.0003: hiddev1,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input2
.
.
.
Dec 30 09:20:38 nuffsan kernel: [   12.393989] cryptsetup (4105) used greatest stack depth: 13648 bytes left
Dec 30 09:20:38 nuffsan kernel: [   20.241508] cryptsetup (4179) used greatest stack depth: 13520 bytes left

Password was entered before 12 and 20 seconds.

I use the very same and slightly modified linuxrc and initrd.scripts. Modification is an own luks open function that is similar but independent from the cryptroot-stuff. Instead I open encrypted partitions specified at kernel line in specified order right before BTRFS scan is performed. Eventually I might send a patch.

I have tried the solution mentioned in https://forums.gentoo.org/viewtopic-t-1063372.html but it didn't work.

Share this post


Link to post
Share on other sites

0 answers to this question

Recommended Posts

There have been no answers to this question yet

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...