EFI boot entries disappear

blac1175 · 2024-02-08 06:25:12

Hi!

I cannot get the EFI boot entries to stick. Every time I reboot, only the boot entry that I added last is preserved, the other boot entry disappears. How can I have two boot entries, persistently, so I can choose between them at boot time?

More details:

My motherboard is an Asrock B660M Steel Legend, with UEFI 13.01.

I checked that secure boot is disabled in the BIOS:
Security \ Secure Boot
System Mode State: User
Secure Boot: Disabled
Secure Boot Mode: Standard

My system has two Arch linux root partitions: nvme0n1p3 and nvme0n1p4:

# fdisk /dev/nvme0n1
Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

Command (m for help): p
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: KINGSTON SNV2S1000G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 27AA8F76-4F51-5141-ACDE-520C24613241

Device             Start       End   Sectors  Size Type
/dev/nvme0n1p1      2048   2099199   2097152    1G EFI System
/dev/nvme0n1p2   2099200  69208063  67108864   32G Linux swap
/dev/nvme0n1p3  69208064 278923263 209715200  100G Linux root (x86-64)
/dev/nvme0n1p4 278923264 488638463 209715200  100G Linux filesystem

Command (m for help): q

I have only one Arch boot entry, called "Arch old":

# efibootmgr -u
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: KingstonDataTraveler 2.01.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)
Boot0002* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/USB(0,0)/CDROM(1,0x1b2000,0x1e000)
Boot0003* Arch old      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/File(\vmlinuz-linux)root=UUID=46b2b993-6999-4154-9b85-5438d0bf0a40 rw initrd=\initramfs-linux.img

So I add a second one:

# efibootmgr -c -u -L "Arch new" --disk /dev/nvme0n1 --part 1 --loader /vmlinuz-linux 'root=UUID=61030ac7-0f02-4579-a3b4-6b15bf769cd6 rw initrd=\initramfs-linux.img'
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,0001,0002
Boot0001* UEFI: KingstonDataTraveler 2.01.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)
Boot0002* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/USB(0,0)/CDROM(1,0x1b2000,0x1e000)
Boot0003* Arch old      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/File(\vmlinuz-linux)root=UUID=46b2b993-6999-4154-9b85-5438d0bf0a40 rw initrd=\initramfs-linux.img
Boot0000* Arch new      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/File(\vmlinuz-linux)root=UUID=61030ac7-0f02-4579-a3b4-6b15bf769cd6 rw initrd=\initramfs-linux.img

And I verify that it was really added:

# efibootmgr -u
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,0001,0002
Boot0000* Arch new      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/File(\vmlinuz-linux)root=UUID=61030ac7-0f02-4579-a3b4-6b15bf769cd6 rw initrd=\initramfs-linux.img
Boot0001* UEFI: KingstonDataTraveler 2.01.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)
Boot0002* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/USB(0,0)/CDROM(1,0x1b2000,0x1e000)
Boot0003* Arch old      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/File(\vmlinuz-linux)root=UUID=46b2b993-6999-4154-9b85-5438d0bf0a40 rw initrd=\initramfs-linux.img

Then I reboot, but on boot, there is only one option, "Arch new". Once I boot into "Arch new", these are my boot entries:

# efibootmgr -u
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002
Boot0000* Arch new      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/\vmlinuz-linuxroot=UUID=61030ac7-0f02-4579-a3b4-6b15bf769cd6 rw initrd=\initramfs-linux.img
Boot0001* UEFI: KingstonDataTraveler 2.01.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)
Boot0002* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/USB(0,0)/CDROM(1,0x1b2000,0x1e000)

As you see, Boot0003 "Arch old" disappeared. So I re-add it:

# efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Arch old" --loader /vmlinuz-linux --unicode 'root=UUID=46b2b993-6999-4154-9b85-5438d0bf0a40 rw initrd=\initramfs-linux.img'
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0003,0000,0001,0002
Boot0000* Arch new      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/\vmlinuz-linuxroot=UUID=61030ac7-0f02-4579-a3b4-6b15bf769cd6 rw initrd=\initramfs-linux.img
Boot0001* UEFI: KingstonDataTraveler 2.01.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)
Boot0002* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/USB(0,0)/CDROM(1,0x1b2000,0x1e000)
Boot0003* Arch old      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/\vmlinuz-linuxroot=UUID=46b2b993-6999-4154-9b85-5438d0bf0a40 rw initrd=\initramfs-linux.img

And I verify that it is really there:

# efibootmgr -u
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0003,0000,0001,0002
Boot0000* Arch new      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/\vmlinuz-linuxroot=UUID=61030ac7-0f02-4579-a3b4-6b15bf769cd6 rw initrd=\initramfs-linux.img
Boot0001* UEFI: KingstonDataTraveler 2.01.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)
Boot0002* UEFI: SanDisk PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/USB(0,0)/CDROM(1,0x1b2000,0x1e000)
Boot0003* Arch old      HD(1,GPT,9bafc35f-65c7-664c-91ec-c3f18a1dd4c1,0x800,0x200000)/\vmlinuz-linuxroot=UUID=46b2b993-6999-4154-9b85-5438d0bf0a40 rw initrd=\initramfs-linux.img

But when I reboot, there is again just one boot entry, this time "Arch old". And after I boot "Arch old", and check the boot entries, I get back to the start of this post. So in a way, I can switch between the two setups, but it's really not convenient, and I want to have the option to switch at boot time.

Thanks,
Balint

d.ALT · 2024-02-08 08:02:22

Do entry persist when adding it via bcfg?
I think you're affected by a bad UEFI implementation... (which is strange, usually I have never found incorrect UEFI implementations on ASRock products)
Please also have a look at Boot entries are randomly removed.

What others options are available (if any) for the Secure Boot Mode: Standard setting?

mkooner · 2024-02-12 01:15:47

Have you tried regressing or updating your bios version?

blac1175 · 2024-02-12 06:05:23

Thanks, everyone.

I tried bcfg, but it did not help, I got the same behavior with boot entries disappearing except the last added one. I tried adding an EFI executable to the fallback path on the boot partition, but that did not change anything. I tried updating from the preexisting BIOS version to the newest one, but that did not change anything, either. The only thing I hav not tried is the "efibootmgr -e 3" trick.

Today I gave up, and installed refind, which works around the problem: the BIOS just needs to remember one boot entry for refind, and I can boot either system from refind. It's sad that there are so many buggy EFI implementations out there...

cryptearth · 2024-02-12 06:52:46

To me it looks like the expected behaviour: You tried to add the very same bootloader twice just with a different parameter for the actual partition. To me it's to be expected that the uefi sees this as a duplicate and hence cleans itself up on POST/drive detection.
I don't know the uefi spec from the top of my had but I guess if different parameters are to be used to distinguish two different entries it's likely only optional and hence your uefi not fully implementing it doesn't violate the spec and hence can't be called a buggy implementation.
That aside - although I guess you have your reasons for such dual booting use the very same kernel and initrd for two different setups only makes sense if the base systems themselfs are kept in sync with eachother. Otherwise that's a job for a more sophisticated bootmanager such as grub ... or refind you ended up with. The job of uefi is only to keep track of different bootloaders - not of thier configurations.

blac1175 · 2024-02-12 18:25:14

That's a very good point - I never thought that UEFI could intentionally deduplicate these entries, but it makes sense. Yes, indeed, these entries only differ in the parameters, the bootloader is the same kernel EFISTUB. So yes, it might not be a bug at all.

As for why I set it up this way: mostly out of ignorance. As I was setting up the second Arch installation, it was not clear to me that there is anything wrong with directly reusing the boot partition. I had a weird feeling about it, but ignored it Then after the first kernel update done on one Arch installation my other Arch installation did not find the kernel modules, and at that point I realized why naively reusing the boot partition is a bad idea So one day I'll probably fix this (for now, I just deal with the hassle of updating the kernel when I boot a system where the kernel modules are not in sync with the booted kernel).

Thanks, I think my problem is solved, and I now understand that this is likely not even a bug.

cryptearth · 2024-02-13 20:16:12

To maybe give some additional input:

Just to play around I have a dual-boot with windows. As windows comes with its own bootloader there're several ways to set it up:
- use uefi to select which os to boot
- use linux based grub and chain windows
- use windows based bootmgr and chain linux (yes, that's actual possible both with uefi and already was back in the days before uefi)

I ended up with removing the windows entry from my uefi but use os-prober to have an entry in my grub.

My point is this: Having multiple OS on the same system drive - nothin wrong with this. Using modern uefi to select between DIFFERNT bootloaders - that's how the spec was designed. But try to give different configs/options to the SAME bootloader - I guess this is where this went the way of the dodo.
Also, as said and as you replied: On linux a efistub kernel has to be in sync with the OS it's starting. When I have a 6.7.x boot kernel but a not-yet-updated 6.6.x OS - it sure fails during boot as loading the kernel modules will likely fail. And to me it looks like that's what happened here.

What I would recommend (although I haven'T tested it myself yet): Do one regular arch install and call it the primary using grub as the boot manager. Then do the secondary but without installing grub once again for it. Rahter reboot into the primary and have os-prober figure out an entry for the secondary arch install.
What seems to be required for this: As you use ONE bootloader for TWO systems you should split /boot and /efi: Use /boot for the kernel and initrd and /efi just for grub. This way the kernel and initrd images are contained within thier respective root partitions and grub only has to switch between partition X and Y when setting root to load the kernel and initrd. Trying to use a combined /boot on the ESP is likely to fail without additional config like specific naming of the kernel and initrd images - and likely some manual grub config work.

Arch Linux

#1 2024-02-08 06:25:12

EFI boot entries disappear

#2 2024-02-08 08:02:22

Re: EFI boot entries disappear

#3 2024-02-12 01:15:47

Re: EFI boot entries disappear

#4 2024-02-12 06:05:23

Re: EFI boot entries disappear

#5 2024-02-12 06:52:46

Re: EFI boot entries disappear

#6 2024-02-12 18:25:14

Re: EFI boot entries disappear

#7 2024-02-13 20:16:12

Re: EFI boot entries disappear

Board footer