-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
BootNext
from https://github.com/rhboot/efibootmgr?BootNext
from efibootmgr?
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. |
Related to rhboot/shim#502 |
#454 is something that could be complementary to this and make the update mechanism safer as well. |
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
Does that make sense? |
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
The text was updated successfully, but these errors were encountered: