Timothée Ravier <siosm@xxxxxxxxxxxxxxxxx> writes: >> 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.) > > I don't think I understand the problem here. Do shim updates usually > change all of those files at once? What's blocking us from updating > them one by one? Conceptually, we need to be able to update most of them in the event of a security issue. Shim releases are infrequent due to needing signing, which means that as a signed unit they update more at once. In the issue you linked, I described what would be a safe order to apply updates to them in, but that's not *transactional* (a system that takes a reboot during the small window of moving files around could see some from old and some from new). > Note that bootupd is not trying to solve the "safe" part of bootloader > updates: we're aware that the system should not crash while the > bootloader is being updated. See > https://github.com/coreos/bootupd#questions-and-answers If your model doesn't permit the system to cease execution during bootloader updates, then I'm not sure why you need bootupd at all - traditional RPM updating will work just fine (assuming the A/B change we've been talking about). But the "Questions and answers" section doesn't read that way to me: it mentions that "forcibly pulling the power during OS updates" is a case ostree wants to support and doesn't explicitly negate that for the bootloader. I'm happy to send a PR to update that text if that's not what's meant. > Thus that's why we're requiring interactions from an admin to apply > the update as only they can now when the system is the less likely to > crash. Are you referring to https://github.com/fedora-silverblue/issue-tracker/issues/120#issuecomment-1177515110 ? I didn't think that was generally something admins expected to be doing, but would be happy to be wrong about that. Be well, --Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
