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. -- 真実はいつも一つ！/ 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
