Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
travier opened this issue Mar 17, 2023 · 4 comments
Open
Labels
enhancement New feature or request

Comments

@travier
Copy link
Member

travier commented Mar 17, 2023

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 travier changed the title Would it be possible to do A/B updates using BootNext from https://github.com/rhboot/efibootmgr? Would it be possible to do A/B updates using BootNext from efibootmgr? Mar 17, 2023
@travier
Copy link
Member Author

travier commented Mar 17, 2023

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 travier added the enhancement New feature or request label Mar 17, 2023
@travier
Copy link
Member Author

travier commented Mar 17, 2023

Related to rhboot/shim#502

@martinezjavier
Copy link

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

@pzmarzly
Copy link

pzmarzly commented Oct 10, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants