On Mon, Nov 21, 2022 at 4:17 PM Zbigniew Jędrzejewski-Szmek
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(a)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
> > 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
> > 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
> > 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
> > 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
> > 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
> > different bootloader. In other words, I understand and won't block this
> > but doesn't make me particularly happy. It seems that it's code that
> > 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!