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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
