On Mon, Nov 21, 2022 at 05:08:40PM -0500, Colin Walters wrote: > > > On Mon, Nov 21, 2022, at 3:52 PM, Zbigniew Jędrzejewski-Szmek wrote: > > > In particular, two reasons why an upgrade might be interrupted were raised: > > power being cut and the system crashing. Bootupd (or any other daemon) cannot > > do much about crashes so this isn't a good motivation. For power, we have > > partial solutions: software-initited poweroffs or reboots should be delayed by > > systemd inhibitors. > > Oh yes, definitely an obvious omission from the current code. Filed https://github.com/coreos/bootupd/issues/403 - thanks! > > > Bootupd+bootupctl creates a lot of interface for the admin > > (status, update, adopt-and-update, validate). This is additional stuff > > to learn. > > Yeah, totally valid comment; though `adopt-and-update` is not something most admins will need to know. I've been thinking lately that `rpm-ostree upgrade` should at least *also* display information when bootupd needs to be invoked too. (And if we did that then combined with the "dnf image" bit then typing `dnf update` would show this too, which should help a lot. Plus having clients like gnome-software also become aware of bootupd was part of the idea) Hmm, so this seems like the wrong direction: gnome-software shouldn't need to know about such low-level details. If gnome-software needs to handle bootloader updates in a special way, it means that bootloader updates become visible to the user, and this shouldn't be necessary. > > It is also additional logic to implement: bootupd must understand > > EFI and boot partitions, mount points, what to do during upgrades, etc. > > I took a brief look at the code and it makes various assumptions about > > how the partitions are named (instead of using part-type uuids!), > > Part of the rationale of for this is that in order to do redundant disk EFI, we can't use the discoverable UUIDs. Or at least, it'd need to be queried per disk and not globally. I filed https://github.com/systemd/systemd/issues/25540 (/dev/disk/by-partuuid should have a variant which includes the disk) for this. > > Also, bootupd does up-calls into the package manager to query state. > > No - at least, not in the way you're thinking. bootupd has a separation between "image build phase" and the client side. The package management query only happens during image builds (e.g. rpm-ostree compose image/tree today) which are normally server side. Ah, OK. Thanks for for the explanation. > > Information should flow from the package management system into lower-level > > components > > Yes...though did you read https://github.com/coreos/bootupd/issues/50 and the sub-thread with Robbie on this? If we want to support lifecycling bootloader updates separately from the RPM database, that inherently calls for having the "package manager" (or more generally, the OS updater, which may not actually "manage packages" at least by default) *not* invoke bootloader updates - at least by default. > > To connect this with the previous comment - on the client side, bootupd has its own notion of "update payload" which is just a bit of JSON that today captures the NEVRA of the component RPMs (but could obviously support content not from RPM too). > > To state this all another way, remember *today* with systems using MBR/BIOS and grub2, `dnf update` does *not* update the MBR and hence `rpm -q grub2` is misleading. So we already have a situation in which the RPM database is not the same thing as the bootloader state. > > > The raison d'être for bootupd seems to be updates of grub. I guess there isn't > > much that can be done in the short term: grub doesn't provide a way to do > > updates atomically, and we need to do those updates, and bootupd seems to be a > > reasonable interim solution to wrap them. But I hope this will stop being > > necessary, and either grub will provide such functionality and/or we'll use a > > different bootloader. In other words, I understand and won't block this Change, > > but doesn't make me particularly happy. It seems that it's code that will be > > used for some time and then go away. > > Thanks, I agree with all of this in general; though, there's going to be a really long tail on "go away", particularly when one tries to scope in actually switching bootloaders... Yeah, this is all a thorny problem. I'm not pretending to have any idea how to solve this comprehensively, but as I wrote before, building tools that interact with the user seems like the wrong direction. I think it's fine to add some temporary tooling (if a few years can be considered temporary) to make the update safer. But the end goal should be for those updates to happen in the background without any interaction. Zbyszek _______________________________________________ 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
