On Mon, Nov 21, 2022 at 4:17 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Mon, Nov 21, 2022 at 03:55:45PM -0500, Neal Gompa wrote: > > On Mon, Nov 21, 2022 at 3:53 PM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> wrote: > > > > > > > https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd > > > > == Summary == > > > > > > > > By design, ostree does not manage bootloader updates as they can not > > > > (yet) happen in a transactional, atomic and safe fashion. Thus bootupd > > > > (https://github.com/coreos/bootupd) was created to solve this issue > > > > and enable admin-lead bootloader updates. This change is about > > > > enabling bootupd integration in Fedora Silverblue and Fedora Kinoite > > > > to make bootloader updates easier. > > > > > > This change does strikes me as something that shouldn't be necessary. > > > The boot loader needs to updated, this is pretty clear, but I think we should > > > have the technology to just update the boot loader in atomic (*) fashion without > > > involving the admin. > > > > > > 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. Similarly, when on battery, the upgrade could be delayed if > > > battery power is below some fraction. The only case that we really need to > > > worry about is the user unplugging the power cord or pressing a button for force > > > a hard poweroff or reboot. But I think it should be enough to just pop up a > > > notification message: "critical system update in progress, do not reboot or > > > power-off" for the duration. > > > > > > Bootupd+bootupctl creates a lot of interface for the admin > > > (status, update, adopt-and-update, validate). This is additional stuff > > > to learn. 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!), > > > that ESP is mounted on /boot/efi, etc. I think this will be problematic > > > in the long term because it hardcodes assumptions about the system > > > and duplicates logic that is already implemented in other places. > > > > > > Also, bootupd does up-calls into the package manager to query state. > > > Information should flow from the package management system into lower-level > > > components, and not the other way around. The package management system > > > should just call into lower-level helpers with specific component > > > paths and versions to upgrade, and those components shouldn't ever need > > > to look at the big picture. Mixing the paradigms results in fragility. > > > > > > 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. > > > > > > > We could do the same thing SUSE does and switch to calling > > scripts/tools to install into /boot and /boot/efi rather than doing it > > directly from RPM. That would simplify the logic of bootupd and allow > > it to just call these tools instead of having to go back and forth > > between the package manager and the system environment. > > We already have such scripts: kernel-install and the plugins. The > kernel %post (or %posttrans?) just calls kernel-install. Doing that > kernel-install invocation from another context should just work. > We don't. We have it for the kernel, but not for shim, grub2, or anything else. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
