Timothée Ravier <siosm(a)fedoraproject.org> writes:
> As we've talked about before, it's not possible to make
> transactional. It involves, per spec and depending on processor
> architecture, updating multiple files in different directories,
> potentially on different filesystems entirely, one of which is fat32.
I should probably have used only 'safe' here. My understanding of the
"fallback work" was that with it, we could do updates automatically and retry
them after failures without risking ending up in a state where we have no working
bootloader. The update process would look like this:
1. Verify current bootloader hash
2. Fix it if not good
3. Copy current version to fallback
4. Update bootloader to new version
What I've indeed forgotten to specify is that this only applies to EFI (so probably
only x86 & aarch64) for now as that's what's implemented in bootupd.
Am I missing something?
Bootloaders are not single files. Consider UEFI:
For grub2, there's both a .efi and some configuration that I'll handwave
for purposes of this conversation. For shim, it's more like 4 things -
the main shim*64.efi, fallback.efi, boot.efi, and boot.csv. These all
serve different purposes, and need to get loaded from specific parts of
the ESP. (Recall here that fat32 doesn't have symlinks, either.)
While I think it will surprise no one that I don't agree with doing so,
bootupd claims the additional goal of supporting Legacy BIOS. For that,
you also need to consider updates to the MBR, which isn't a file at all.