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 > <zbys...@in.waw.pl> 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. 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
