menu-selection keys do not work (intermittently, but frequently making boot choice impossible!)

[Mary S]

This has started happening in the last month or so. I have a clean LTS 20.04.1 that is kept up to date.

On boot, the menu is presented to select what to boot, but quite often (currently about 90% of boots), NONE OF THE KEYS WORK, so I cannot select what to boot!

Randomly, sometimes the keys do work.

This used to work fine all the time, so maybe it's a fairly recent change to grub?

I've seen various other similar bugs with various potential solutions, and I've tried most of them with no luck.

To me, there seems to be some kind of timing issue that causes the keyboard not to be detected properly some of the time, and is making boot-choice IMPOSSIBLE!

This is a critical bug for me, and it's making it impossible for me to boot into Windows (in my dual boot), which is making the computer almost useless for me!

As a note, I would hope that an LTS release *never* changed grub unless _ritical_ as without a working grub, I cannot use Ubuntu! Thankfully, Ubuntu is my default, so I can always boot into that, and the keyboard is always fine there, but this is a very annoying problem that's making my PC only half-useful, so please can you give this urgent attention and fix it, thanks!!

my system info:

$ lsb_release -rd
Description: Ubuntu 20.04.1 LTS
Release: 20.04

$ apt-cache policy grub2
grub2:
  Installed: (none)
  Candidate: 2.04-1ubuntu26.7
  Version table:
     2.04-1ubuntu26.7 500
        500 http://gb.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
     2.04-1ubuntu26.2 500
        500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages
     2.04-1ubuntu26 500
        500 http://gb.archive.ubuntu.com/ubuntu focal/universe amd64 Packages

What I expected: to be able to choose an OS to boot
What happened: the keys do not work, so I cannot choose anything and the default is always selected instead).
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.14
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2020-02-23 (320 days ago)
InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1)
NonfreeKernelModules: nvidia_modeset nvidia
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 5.4.0-59.65-generic 5.4.78
Tags: focal
Uname: Linux 5.4.0-59-generic x86_64
UpgradeStatus: Upgraded to focal on 2020-09-29 (100 days ago)
UserGroups: adm audio cdrom dip docker kvm libvirt lpadmin microk8s plugdev sambashare sudo
_MarkForUpload: True
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2020-02-23 (367 days ago)
InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1)
NonfreeKernelModules: nvidia_modeset nvidia
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 5.4.0-65.73-generic 5.4.78
Tags: focal
Uname: Linux 5.4.0-65-generic x86_64
UpgradeStatus: Upgraded to focal on 2020-09-29 (147 days ago)
UserGroups: adm audio cdrom dip docker kvm libvirt lpadmin microk8s plugdev sambashare sudo
_MarkForUpload: True

[Mary S (marystern)]

It's a USB keyboard that I'm using.

[Julian Andres Klode (juliank)]

I see that too but it is a BIOS issue - the keyboard sometimes is not initialized properly. Please check if it works for you before grub when that problem occurs.

This bug is also missing data, please run apport-collect 1910571 to collect details.

[Mary S (marystern)]

apport information

[Mary S (marystern)]

apport information

[Mary S (marystern)]

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Table at 0xDA31A000.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
 Vendor: American Megatrends Inc.
 Version: 1403
 Release Date: 10/31/2019
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 16 MB
 Characteristics:
  PCI is supported
  APM is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  Boot from CD is supported
  Selectable boot is supported
  BIOS ROM is socketed
  EDD is supported
  5.25"/1.2 MB floppy services are supported (int 13h)
  3.5"/720 kB floppy services are supported (int 13h)
  3.5"/2.88 MB floppy services are supported (int 13h)
  Print screen service is supported (int 5h)
  8042 keyboard services are supported (int 9h)
  Serial services are supported (int 14h)
  Printer services are supported (int 17h)
  ACPI is supported
  USB legacy is supported
  BIOS boot specification is supported
  Targeted content distribution is supported
  UEFI is supported
 BIOS Revision: 5.14

[Mary S (marystern)]

Can anyone tell if this BIOS works or not from the version info?

(it did seem reliable for many months before starting to fail recently which is a bit odd if it's a BIOS bug...)

What's the best way to test a key before grub: just see if I can go into BIOS menu?

[Mary S (marystern)]

My BIOS keys seem fine (and the USB mouse in the BIOS setup too).

I'm on v1403 x64 (10/31/2019) vs the latest v3001 (2020/12/9), for ASUS Prime X570 PRO, but there don't seem to be any keyboard fixes (although some fixes mention "system stability" whatever that might mean...).

https://www.asus.com/Motherboards-Components/Motherboards/All-series/PRIME-X570-PRO/HelpDesk_Download

When I get a chance I'll try to upgrade my BIOS (a bit wary to do this unless 100% necessary though), and I'll report back here.

Is there any way to get grub to debug/log/say what it finds (ie whether or not it's detected the keyboard and why not)?

[Mary S (marystern)]

So, I updated to BIOS v3405 (2021/02/05), and the keys STILL do NOT work! :(

So, the problem still exists: please investigate/fix! :)

[Mary S (marystern)]

(not sure why this is marked as "incomplete": do you need any other info from me?)

[Mary S (marystern)]

apport information

[Mary S (marystern)]

apport information

[Mary S (marystern)]

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.
Table at 0xCB9F9000.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
 Vendor: American Megatrends Inc.
 Version: 3405
 Release Date: 02/01/2021
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 16 MB
 Characteristics:
  PCI is supported
  APM is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  Boot from CD is supported
  Selectable boot is supported
  BIOS ROM is socketed
  EDD is supported
  5.25"/1.2 MB floppy services are supported (int 13h)
  3.5"/720 kB floppy services are supported (int 13h)
  3.5"/2.88 MB floppy services are supported (int 13h)
  Print screen service is supported (int 5h)
  8042 keyboard services are supported (int 9h)
  Serial services are supported (int 14h)
  Printer services are supported (int 17h)
  ACPI is supported
  USB legacy is supported
  BIOS boot specification is supported
  Targeted content distribution is supported
  UEFI is supported
 BIOS Revision: 5.17

[Mary S (marystern)]

@juliank

re: "Please check if it works for you before grub when that problem occurs."

.. how do I do that please?

[Mary S (marystern)]

(FYI: keys work find inside BIOS setup).

[Mary S (marystern)]

I've tested this now a number of times, and 99% of the time, the boot selection does NOT work!

Is it possible for me to regress grub to an older version that worked (my alternative boot systems are currently inaccessible, so this is CRITICAL for me)? If so, can you tell me how, thanks.

Alternatively, can you at least help by pointing me towards the source versions and I'll try to help find the problem by going through the changes that might have broken this?

[Mary S (marystern)]

As it seems grub won't be fixed, can you please at least tell me if it's a good idea or not to replace grub with systemd-boot, and if Ubuntu is planning to migrate to this too later?

ref: https://askubuntu.com/questions/1225791/how-to-replace-grub-with-bootloader-systemd-boot-in-ubuntu-20-04

[Mary S (marystern)]

Hmm, apparently this is not well supported?

ref: https://askubuntu.com/questions/1318789/ubuntu-v20-does-not-detect-systemd-boot-as-installed

[Mary S (marystern)]

For anyone who's interested, I installed systemd-boot as per the link above, but my ESP partition was too small (Windows creates a 100Mb partition but a 1Gb is more useful for dual boots). So, I created a new ESP on my second disk, and pointed efibootmgr -d to use it. Eventually, this seems to at least boot Windows and Ubuntu now, so some progress. I haven't got to removing grub and lilo yet (as per the second link above), so we'll see how well Ubuntu updates...

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]