"Colin Walters" <walters(a)verbum.org> writes:
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).
No, the install script install script in an RPM trigger, so the write is
still carried out by RPM.
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].
I don't agree. Just because a user can mess with files on the system
doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all
paths on the filesystem just in case they've done so, or create a daemon
to provide an interface for doing that.
Be well,
--Robbie