temporary disk swap mangled UEFI multibooting

English Install/Boot/Login
1

Based upon https://en.opensuse.org/openSUSE:UEFI I was able to

# efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
# efibootmgr
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004,0005,0003
Boot0000* opensusetw
Boot0003* CD/DVD Drive
Boot0004* UEFI OS
Boot0005* Hard Drive

Prior to the swap, TW’s Grub menu began approximately as follows:

memtest86 7.4 EFI
openSUSE TW
openSUSE 15.0
openSUSE 15.1
Debian 10 Buster
Tubuntu 18.04
Linuxmint 19
etc.

This was restored by the above efibootmgr -c command.

The proximate cause of need was something I didn’t save, but the following template would be close enough:

# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0004,0005,0003
Boot0000* ubuntu
Boot0001* ubuntu
Boot0002* ubuntu
Boot0003* CD/DVD Drive
Boot0004* UEFI OS
Boot0005* Hard Drive

How it got that way was a consequence of my UEFI installation media => Boot Linux System thread setup, removing the SSD, attaching an empty HD in its place, installing 15.2, then testing “Boot Linux System” from installation media.

How those three ubuntu entries got there I can’t say. I suppose they were in the back reaches of NVRAM, put there when Kubuntu and Mint got installed, after TW and 15.0 and 15.1 and Debian, and subsequently upgraded, even though I removed all its and Debian’s entries using efibootmgr, and even though I purged bootloader packages from all installations except TW. At least, I thought I purged it from all other. And, even though I adjusted most fstabs, including Kubuntu’s and Mint’s, except TW’s by commenting each ESP partition entry, so that /boot/efi/ when running would not provide access to the ESP except when TW is running.

On first boot after reconnecting the SSD, I expected to get the same UEFI presentation as I had been for more than a year before the storage switch. Instead, I got a grub> prompt. On restart I hit F8 to get the Asus boot menu, whereupon I found no sign of any openSUSE selection, only devices (ordinary and UEFI USB sticks; ordinary and UEFI SATA (SATA6G_3), and multiple ubuntu entries). I chose the UEFI OS entry (0004), and got another grub> prompt. From there I typed in the text of the default selection from a backup copy of grub.cfg, which got me TW booted, apparently normally. Once I found the wiki page, I found its example and used it to add the needed entry that begins this post.

Already I’ve forgotten exactly what happened next, but eventually I rebooted into BIOS again. In UEFI Hard Drive Priorities, only one was listed, UEFI OS (SATA6G_3 <model#>). I selected that entry and was presented both it and opensusetw to select from. I selected opensusetw, with result that there were now two boot options, with opensusetw first, and booting is back to normal via TW’s grub configuration.

Asus Aptio/AMI BIOS date is 20181116, Version 1402 x64, ME Firmware version 11.8.55.3510, PCH Stepping AO.

Anyone know if mangling of UEFI entries as happened to me today is typical of disk swaps in UEFI PCs?

2

Hi
I think from memory I saw that occur with an ASUS K55A I have here (it’s a parts only machine now), never worried about it since it’s easy to create new entries on the fly…

3

I’m not sure that anything is typical. Different implementations behave differently.

On my Dell system, the BIOS always want to clean up. It allows me to have only two named boot entries. And it only allows two because I have two hard drives with an EFI partition on each drive. If I create a third entry, then on next boot one entry will disappear. If I always use grub for booting Windows, then after a month or two the Windows boot entry will disappear. So I hit F12 during boot to get the BIOS boot menu and boot Windows that way.

On my Lenovo system, there are many entries. If I delete a named entry, then it will come back on the next boot unless I also delete the “.efi” boot file associated with that entry. And if, some time later (even a year later), that boot file gets back there, then the BIOS will restore the corresponding named boot entry. Also, if I change the boot order with “efibootmgr -o”, then the BIOS will put it back to prior boot order. If I don’t want that, I have to change the boot order in the BIOS settings. If I temporarily switch to CSM booting (legacy booting), then when I restore UEFI booting the BIOS will make up its own mind on the boot order, and I have to set it up all over again.

Using a KVM virtual machine, with the OVMF implementation of UEFI, the behavior is more like that of my Dell system.