On Tue, Nov 15, 2022, at 12:00 PM, Robbie Harwood wrote:
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.
There's lots of nuance going on here. What both bootupd and your shim prototype are
doing is effectively moving the "payload" into /usr and not have RPM directly
writing to /efi (or /boot/efi, wherever it's mounted).
This also then directly leads into a next issue:
https://github.com/coreos/bootupd/issues/50
Basically, `rpm -q shim` becomes a lie - or at least, starts to mean something else[1].
So part of the role of bootupd here is just to become the API to query and manage state.
It is also kind of aiming to abstract out the differences across platforms, i.e. we were
discussing bringing BIOS and PReP under management too in
https://github.com/coreos/bootupd/issues/398
So basically the rationale for bootupd is to become a (relatively thin) layer for managing
this stuff since it is decoupled from the kernel+rootfs lifecycle (but, delivered inside
that).
[1] In a similar vein of course, `rpm -q kernel` can often be a lie after live updates
but before rebooting, and similar for userspace services that aren't restarted or old
libraries loaded. But, admins have known about those for a long time, or if they
don't they learn the hard way.