Would it be possible to do A/B updates using `BootNext` from efibootmgr?

[travier]

Bootupd would write the new bootloader in a new place (B), set BootNext to a new boot entry with this bootloader. And then on reboot would check that the boot succeeded and would do the reverse for the next update (use A).

See: https://github.com/rhboot/efibootmgr

[travier]

If this works, that would potentially let us enable boot loader updates by default (just like it is on dnf based Fedora) has the update itself would be safe.

[travier]

Related to rhboot/shim#502

[martinezjavier]

#454 is something that could be complementary to this and make the update mechanism safer as well.

[pzmarzly]

This was recently discussed at Linux Plumbers Conference 2024 talk no more bootloader: please use the kernel instead (given by @marta-lewandowska, while the project is co-developed with @vathpela). The main concert raised by the audience was NVRAM durability - writing to BootNext on every update could wear down the flash storage, and thus brick the motherboard.

This is a valid concern, one that I've heard before elsewhere, only the last time it was about monitors potentially dying because of f.lux and Lunar.app. The Lunar.app developer disagrees with this, but I guess collecting more data (by conducting experiments on common hardware) would be great.

But even if motherboard chips were to die after the 100K writes like some theorise, that'd still give us space for 50K updates (2 operations: we set BootNext, the firmware unsets BootNext), which is a lot, even if someone updates kernel many times a day (kernel developers). We should be careful not to perform more writes than we need - e.g. rather than creating/deleting the boot entries on every update, we only change BootNext. How? We could create current and next entries on first installation, and then just one-time activate the next entry by setting the BootNext on update:

0001 coreos-current (\EFI\boot\bootx64.efi)
0002 coreos-next (\EFI\boot\bootx64-next.efi)
0003 Windows Boot Manager (\EFI\Microsoft\Boot\Bootmgfw.efi)
BootOrder: 0001,0003
BootNext: 0002

Does that make sense?

[gregory-lee-bartholomew]

It's too bad UEFI doesn't let you point at a directory instead of a specific executable. It'd be great if you could just drop UKIs into a directory on the ESP and then the firmware would iterate over them in version-sorted order until one succeeded.