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?
What's the plan to apply the outstanding security updates (shim,
and dbx push from June) to fedora silverblue 36 + 37 that aren't covered
by this change?
We definitely want to backport all that to F36/37. This will only be possible for changes
not in Anaconda, as we don't respin the installers. I'm not 100% sur yet we'll
need Anaconda changes but mentioning it here in case it turns out we do.
Thanks for the comments, I'll update the proposal.