No keyboard in the GRUB menu

I’ve swapped my PS/2 keyboard for a wireless one with a USB-C dongle. Since then, the keyboard no longer works in the GRUB boot menu. I can’t select the kernel or edit the command line. The keyboard works again once booting has started: I can enter my LUKS password.

I imagine it’s some sort of module that I need to add to GRUB, but which one?

# sudo dmesg | grep keyb

[    1.091327] hid-generic 0003:1D57:FA60.0001: input,hidraw0: USB HID v11.01 Keyboard [JLab Work] on usb-0000:01:00.0-1/input0
[    1.214485] hid-generic 0003:1D57:FA60.0004: input,hidraw3: USB HID v11.01 Keyboard [JLab Work] on usb-0000:01:00.0-1/input3

UPDATE:
Moved from USB-C to USB-2. We’ll see tomorrow after the reboot what has changed – or not…

[17001.552085] hid-generic 0003:1D57:FA60.000A: input,hidraw0: USB HID v11.01 Keyboard [JLab Work] on usb-0000:01:00.0-7.4.3/input0
[17001.708069] hid-generic 0003:1D57:FA60.000D: input,hidraw3: USB HID v11.01 Keyboard [JLab Work] on usb-0000:01:00.0-7.4.3/input3

No effect.

UPDATE 2:

GRUB_PRELOAD_MODULES="part_gpt part_msdos nvme usb usb_keyboard"
GRUB_TERMINAL_INPUT="console usb_keyboard"

No improvement. The keyboard is recognised, but when I press a key, the character is repeated 15 times.

UPDATE 3:

PS/2 adapter: No effect. No keyboard at all anymore.

The USB-C port you are using is probably not able to be used by the bios during boot but the driver for that port is then loaded during startup. Do you have a USB port that can be used for bios access? Probably a USB A port or a different USB C port.

Hi Jeff. The BIOS is able to use all USB ports. GRUB isn’t. I tried USB-C on board, USB-2 via monitor hub, USB-2 on board and PS/2 on board using adapters. To be clear the usb-c dongle was connected to an usb-2 adapter which in turn was connected to a ps/2 adapter. IIRC I had to enable legacy USB in the BIOS too.
Thanks for your interest. This is clearly a grub issue.

At one point, a combination of modules had the keyoard working in grub, but it was unusable e.g. pressing the letter ‘c’ resulted in ‘cccccccccccccccc’; you can imagine what it was doing with the arrows to select a specific kernel!

Board is an Asrock B550m Pro4 with a 5600GT APU.

I’ll take a stab at this.
If BIOS adjustments do not work, you can try to force GRUB to load the necessary drivers by editing /etc/default/grub and adding the following lines:

GRUB_TERMINAL_INPUT="usb_keyboard"
GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"

After saving the file, I regenerated the configuration by running sudo grub2-mkconfig -o /boot/grub2/grub.cfg (for BIOS systems) or sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg (for UEFI systems).
This helped me a while back, hope it helps you as well…Good Luck!

EDIT for the second command: and on UEFI system:

 sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
[sudo] password for me: 
Generating grub configuration file ...
Found Arch Linux on /dev/nvme0n1p2
Found CachyOS on /dev/nvme1n1p3
Adding boot menu entry for UEFI Firmware Settings ...

Hi,
Thank you so much for giving a try at this. After doing what you specified, the screen displayed errors. I can’t scroll or abort because no keyboard.

GRUB_TERMINAL_INPUT="usb_keyboard"
GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"

I added that and immediately got an error of which I provide a screen capture.
I looked for the proper files on 'boot ’ and they are there.

$ sudo find /boot/ -name "*hci.mod"
/boot/grub2/i386-pc/ehci.mod
/boot/grub2/i386-pc/ohci.mod
/boot/grub2/i386-pc/ahci.mod
/boot/grub2/i386-pc/uhci.mod
shizuma@shizuma:~$ sudo find /boot/ -name "usb*"
/boot/grub2/i386-pc/usb_keyboard.mod
/boot/grub2/i386-pc/usbtest.mod
/boot/grub2/i386-pc/usbms.mod
/boot/grub2/i386-pc/usbserial_pl2303.mod
/boot/grub2/i386-pc/usb.mod
/boot/grub2/i386-pc/usbserial_ftdi.mod
/boot/grub2/i386-pc/usbserial_common.mod
/boot/grub2/i386-pc/usbserial_usbdebug.mod

hd0 is an nvme ssd and partition 2 is /boot/

had to recover files on /boot/ grub2/grub.cfg from a clone so this time I made a backup /boot/ grub2/grub.cfg.bak to stay in place for the future failed test.

Just an idea I got. It seems that when you specify modules to load by GRUB_PRELOAD_MODULES, it replaces completely the modules grub would normally load. So you need to know thaat list and append them to GRUB_PRELOAD_MODULES. Makes sense?

As I said earlier, I had partial success with these settings:

NO!!!
The first command is correct. The second should fail with this result!

$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Running `grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg' will overwrite the GRUB wrapper.
Please run `grub2-mkconfig -o /boot/grub2/grub.cfg' instead to update grub.cfg.
GRUB configuration file was not updated.

The second command has not been used for several years and if it did work would prevent ever updating grub for new kernels when updating a kernel.

You can see that both types of booting (legacy and uefi) only use the one grub.cfg file by running the command ls -l /etc/grub2*. It should give you this return.

$ ls -l /etc/grub2*
lrwxrwxrwx. 1 root root 22 Jun  4 19:00 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 22 Jun  4 19:00 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg

Note that both entries are symlinks to the same file /boot/grub2/grub.cfg

Thanks, but irrelevant here, I use a BIOS system, not EFI.

Not irrelevant at all.
The same command is used for both BIOS boot and for UEFI boot so users must understand that the second command presented by @chillzone is improper in ALL fedora systems. My comment was directed to correct the invalid instructions and not specifically for your issue.

That’s precisely the point. This thread was opened primarily to fix my issue, not to educate the rest of the users. In other words, you’re off topic IMHO.

I edited my post but find a different outcome?

ls /etc/default && bat /etc/default/grub
grub  pcscd  useradd
─────┬───────────────────────────────────────────────────────────────────────────────────────────────────────
     │ File: /etc/default/grub
─────┼───────────────────────────────────────────────────────────────────────────────────────────────────────
   1 │ GRUB_TIMEOUT=5
   2 │ GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
   3 │ GRUB_DEFAULT=saved
   4 │ GRUB_DISABLE_SUBMENU=true
   5 │ GRUB_TERMINAL_OUTPUT="console"
   6 │ GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-6ef70a0e-7f05-46d4-acdf-b2b350cdbde6 rhgb quiet rd.driver.blackl
     │ ist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core"
   7 │ GRUB_DISABLE_RECOVERY="true"
   8 │ GRUB_ENABLE_BLSCFG=true
─────┴───────────────────────────────────────────────────────────────────────────────────────────────────────


Note that Fedora changed some years back and does not EVER modify the file that is created during installation at /boot/efi/EFI/fedora/grub.cfg. That file became a pointer file with this type content that redirects grub to the grub.cfg file located at /boot/grub2/grub.cfg.

$ sudo cat /boot/efi/EFI/fedora/grub.cfg
search --no-floppy --root-dev-only --fs-uuid --set=dev \<UUID for the /boot partition\>
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

When fedora performs a kernel update the only grub.cfg file modified is the one at /boot/grub2/grub.cfg and if the user chooses to alter the one contained under the /boot/efi directory it never gets changed with future kernel updates. Thus the user is stuck with the config at the time they manually altered that file and cannot boot newer kernels until they once again alter that file.

Other OSes may perform differently.

I don’t know what fedora version you may be running, nor if you are running that command under another OS, but as noted above this is off topic for the particular issue in the title of this thread.

I’ll take your word on the matter. :wink:

inxi -S
System:
  Host: cachyos-x8664-butter Kernel: 7.1.3-cachyserver1.fc44.x86_64
    arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.7.3 Distro: Ultramarine Linux 44 (Plasma
    Edition) flyingfish

I do run a few different kernels. (I’m a private tester) :slight_smile:

Cachyos kernels on a fedora system do not behave the same as a clean fedora system with fedora kernels – especially when using Ultramarine.