> 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? 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 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. > 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. While we do have that as a goal, we don't support legacy BIOS right now thus the reason why this proposal is focusing on EFI systems: https://github.com/coreos/bootupd/issues/53 _______________________________________________ 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
