Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux