> As we've talked about before, it's not possible to make updates > 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, grub2, > 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. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
