I'm suddenly booting into BIOS/UEFI instead of to 22.04 login screen

[watchpocket]

A few weeks back I noticed that my desktop workstation was no longer booting directly into the login screen for Ubuntu MATE 22.04, but straight to the BIOS/UEFI.

From the BIOS screen I can hit the F1 key, select the "Boot" menu and from there select which OS to boot into (but, of course, I shouldn't have to do that).

I have 22.04 on an internal nvme drive, 20.04 on a 2nd internal nvme drive, and a backup 20.04 on an internal SSD. I do not use Microsoft Windows.

I can access the GRUB menu by pressing ESC, and choose which OS to boot to from there, but I suspect some recent software update (or perhaps kernel update) caused this change.

Any tips on where I should begin to troubleshoot? And has this happened to anyone else? Thanks.

[sudodus]

Boot [the awkward way] to the Ubuntu system that you want to be the default one and run

sudo update-grub

Then reboot. Did it solve the problem? Did something change? In that case what happens now? Or is it the same problem as before?

[watchpocket]

The problem doesn't occur on reboots. It also doesn't occur after complete shutdown and waiting a few minutes.

It occurs when I boot up the next morning, or after some longer (longer than 5 minutes) time period. So I don't yet know if the situation has changed.

I'm going to try doing a shutdown and then waiting an hour.

Btw, I believe I have a grub on all 3 of my OS installs. (I entered the sudo update-grub command on all 3.)

How do I determine which grub is the active one? Thanks.

[tea for one]

Btw, I believe I have a grub on all 3 of my OS installs. (I entered the sudo update-grub command on all 3.)
How do I determine which grub is the active one? Thanks.

The active one will be the last OS where you updated grub.

[sudodus]

The problem doesn't occur on reboots. It also doesn't occur after complete shutdown and waiting a few minutes.

It occurs when I boot up the next morning, or after some longer (longer than 5 minutes) time period. So I don't yet know if the situation has changed.

I would suspect that one of the drives is a slow starter. Maybe it will work better, if you add some seconds waiting time at boot. You can do that via editing the file

/etc/default/grub

to increase the GRUB_TIMEOUT variable and after that running again

sudo update-grub

from the system, that should have priority. See this link.

[ubfan1]

You can always just edit the /boot/grub/grub.cfg file and change the wording on the menu items. Or make a unique /etc/grub.d/40_custom for each disk. With three disks, each getting grub installed, the order you run update-grub doesn't matter, the bootorder determines which runs. But if the first fails, then the second one may get run. Might be a good idea to run the smartmontools package smartctl on your disks.

[MAFoElffen]

You didn't say what make/model/kind of system it is...

From changing personalities from just booted, to a difference after it has sat for awhile (overnight, days, etc.), I would also check the voltage of the CMOS battery. A long-shot, but suspect.

There is a way to do that "programatically"... On shutdown, do

dd if=/dev/nvram of=cmos_ram_01.bin

On startup do it again to a comparison file

dd if=/dev/nvram of=cmos_ram_02.bin 
TEST=$(cmp -b cmos_ram_01.bin cmos_ram_02.bin) # This will printout any bytes that differ
if [! -z "$TEST" ]
then 
  logger "NVRAM corrupted." # This will enter a message into the syslog
fi

[oldfred]

Ubuntu's default install is to one ESP on first drive. Whatever UEFI/BIOS defines as first drive.
Do you have separate ESP on each drive or just the one?

An update grub only updates menu.
But a grub install resets settings in UEFI boot menu & ESP to use that install as default boot. Then grub menu should have all installs in it. Major update to grub may do a new grub-install, resetting that install to default.
Boot into preferred install and manually do a sudo grub-install to reset that to default boot.

Often easier to run Boot-Repair to see where everything is at.
But you can check GUID/partUUID used by UEFI settings.
sudo efibootmgr -v
lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint ,uuid,partuuid

And if ESP using default 0077 entry difficult to see entry, Boot-Repair changes to older entry of "defaults" in fstab, which may be less secure, but lets you see files when mounted. Otherwise you can use live installer & manually mount.

In ESP will be a 3 line grub.cfg that uses UUID of install. So with 3 installs, it could be any of them. Compare using lsblk -f or above command. You can manually edit or when booted into preferred default, do a sudo grub-install to make that one the default.

[watchpocket]

> You didn't say what make/model/kind of system it is.

I built my desktop workstation computer myself. The only relevant info I can think of to answer this is in my sig.


> Whatever UEFI/BIOS defines as first drive.

The first drive to boot is defined in UEFI/BIOS as my 22.04 nvme1 Jammy Jellyfish.


> Do you have separate ESP on each drive or just the one?

I have an ESP on each of the three drives.


> In ESP will be a 3 line grub.cfg that uses UUID of install.

--> cat /boot/efi/EFI/grub/grub.cfg 

search.fs_uuid 3bcf9a37-e310-4945-87a8-dac0932a16cb root set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

(The above identical file -- with same UUID number -- is also in /boot/efi/EFI/ubuntu/grub.cfg)


> Boot into preferred install and manually do a sudo grub-install to reset that to default boot.

Before I do that, I will lay out some likely relevant general info here:

--> sudo efibootmgr -v 

BootCurrent: 0001

Timeout: 1 seconds

BootOrder: 0001,0000,0002,0006

Boot0000* 20.04__Focal-Fossa    HD(1,GPT,337ce8d2-65a0-4051-8c12-55cc22666e7e,0x4000,0xc9000)/File(\EFI\UBUNTU\SHIMX64.EFI)

Boot0001* 22.04_NVMe1__Jammy-Jellyfish    HD(1,GPT,90af4214-eca8-4265-8e5f-9c2e3301bba9,0x4000,0xc939a)/File(\EFI\UBUNTU\SHIMX64.EFI)

Boot0002* 20.04_SSD____Focal-Fossa    HD(1,GPT,684141f2-20c3-41be-b2c4-7058d9488896,0x4000,0x113229)/File(\EFI\UBUNTU\SHIMX64.EFI)

Boot0006* grub    HD(1,GPT,684141f2-20c3-41be-b2c4-7058d9488896,0x4000,0x113229)/File(\EFI\GRUB\SHIMX64.EFI)

--> lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid 

NAME        FSTYPE   SIZE FSUSED LABEL       PARTLABEL                  MOUNTPOINT UUID                                 PARTUUID
sda                894.3G                                                                                               
├─sda1      vfat   550.3M        SSD_ESP     SSD_EFI-system-partition              6DE5-0FF8                            684141f2-20c3-41be-b2c4-7058d9488896
└─sda2      ext4   893.7G        20.04_SSD   UbuntuMATE-20.04_SSD                  21697ef7-83e3-4414-a859-91841f61dce8 7cc6f822-eb23-4829-9039-6d09e6e0ca55
sdb                894.3G                                                                                               
└─sdb1      ext4   894.3G        WeirdBeard  WeirdBeard_data                       70e15e24-a75c-4115-9c83-29cb585676f6 5ab70820-78e7-466e-9c0f-101054d5df9b
nvme0n1            931.5G                                                                                               
├─nvme0n1p1 vfat     402M        NVME0_ESP   nvme0_EFI-system-partition            2BD2-4199                            337ce8d2-65a0-4051-8c12-55cc22666e7e
└─nvme0n1p2 ext4   931.1G        20.04_NVMe0 UbuntuMATE-20.04                      07041e0f-1cde-4caf-9b1d-86851e9601ed 0657b873-53c2-4a40-9e60-3b26c891fd1b
nvme1n1            931.5G                                                                                               
├─nvme1n1p1 vfat   402.5M  10.3M NVME1_ESP   nvme1_EFI-system-partition /boot/efi  E23B-29C2                            90af4214-eca8-4265-8e5f-9c2e3301bba9
└─nvme1n1p2 ext4   931.1G    53G 22.04_NVMe1 UbuntuMATE-22.04_nvme1     /          3bcf9a37-e310-4945-87a8-dac0932a16cb 77706804-715d-4276-9824-a184ed00df4f

Also, and this may be important here (though I think this file is correct and has been serving me well for months),
I have an /etc/grub.d/06_custom file.
(It's 258 lines; ignore all the "*......." - they're invisible characters denoting spaces; same for "____" which denotes a line-continuation).

That file is on pastebin at https://paste.ubuntu.com/p/tQhsBzDpWr/

Thanks for looking at this info.

[MAFoElffen]

"Asus ROG Crosshair VIII Hero wifi" was released July 1, 2019. About 4 years ago or so. Life expectancy of a CMOS battery is 3-5 years.

Possible. But can be ruled out easy enough on that board. (not a laptop of notepad, where it is somethings is 'under' the motherboard.)