Timothée Ravier <siosm(a)fedoraproject.org> 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#issuecommen...
? 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