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. _______________________________________________ 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
