On Fri, Jan 10, 2025 at 07:44:29PM +0000, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1 > Discussion thread - > https://discussion.fedoraproject.org/t/f42-change-proposal-unification-of-boot-loader-updates-phase-1-system-wide/142035 > > This is a proposed Change for Fedora Linux. > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > > Begin the process of using single tool (likely bootupd) for most boot > loader updates, especially grub and shim. This decouples package > installation, e.g., via rpm transaction, from actual update in `/boot` > and `/boot/efi`. This change does not affect zipl and systemd-boot. > > {{admon/important||The implementation details for this change are not > fully fleshed out yet but we believe that there is a general agreement > that this is the right way to go, so we are submitting it to start the > discussion around how we should implement it. We will update the > change based on feedback from those discussions.}} > > == Owner == > > * Name/Emails: > ** [[User:Siosm| Timothée Ravier]] siosm@xxxxxxxxxxxxxxxxx (Atomic > Desktops, CoreOS, bootc) > ** [[User:Walters| Colin Walters]] walters@xxxxxxxxxx (bootupd, bootc) > ** [[User:mlewando| Marta Lewandowska]] bazylia@xxxxx (grub2, shim) > > > > == Detailed Description == > > Our goal is to make boot loader updates in all environments: rpm mode, > image mode, etc., safer and more reliable, and to add a fallback > option so that a system is always bootable. We want to use a single > interface, bootupd, to perform the actual boot loader update on a > system once all new packages have been installed on that system. > > On package mode systems (i.e. Workstation, Server, etc.), most > components are updated monolithically along with boot loader packages, > which automatically install into the `/boot` and/or `/boot/efi` > directories, overwriting binaries that were there. Notably, kernel > installation is performed via systemd script kernel-install, which > runs at the end of the rpm transaction. Each distribution has a single > directory structure constituting its bootpath, and if anything goes > wrong during the subsequent boot, repair can be difficult or even > impossible. > > On image mode systems (i.e. bootc, CoreOS, IoT, Atomic Desktops), the > boot loader update is decoupled from the system update, but, bootupd, > once triggered, will also overwrite entries in `/boot` & `/boot/efi`, > and any problem with the boot loaders has the potential to create an > unbootable and unrecoverable system. > > Rather than using different, yet equally precarious, methods for > updating these critical components, we want to adapt bootupd to work > on all systems in order to make boot loader updates easier and safer. > It would additionally be aware of dependencies between packages, such > as boot loaders and kernels. bootupd would (likely) be the interface > that is used on all systems to perform the actual update once all new > packages are available, and it would in the future retain a fallback > option in case any problem arises during the subsequent boot process. > > === This change will be split into two phases === > > ''Phase 1 (this change, proposed for Fedora 42)'' > * Install the following packages into `/usr/lib/<pkg>/<arch>` rather > than `/boot` & `/boot/efi` > ** grub2 > ** shim > * Separate rpm actions that happen at build time vs. runtime: This is confusing. When talking about rpms, 'build time' is when the package is being built. 'runtime' would normally be understood to be the time when the content installed by the rpms is being used after installation. I guess this is about separating what happens during package installation and later… But this is hard to understand right now. > ** Add a mechanism that installs the bootloader for package mode > installations as part of a RPM post trans. It is not yet defined how > that will happen. Options that were suggested: > *** Add a dumb Bash script that copies the bootloader to the ESP > *** Add a new action verb to kernel-install, which will run script(s) > for given component > *** Adapt bootupd to cover this case > * Teach new boot loader location (`/usr/…`) to bootupd (needed for > rpm-ostree & Bootable Containers variants) > * Extend systemd package-notes to support PE files > > ''Phase 2 (will be proposed for Fedora 43)'' > * Add A/B support, BootNext to bootupd > https://github.com/coreos/bootupd/issues/440 > * Unify on bootupd to perform all boot loader updates at both system > install (e.g. Anaconda) time and for updates > * Install bootupd on dnf and image based systems by default > * Consider switching to a static GRUB configuration file (to be detailed) > > === Phase 1 (this change, proposed for Fedora 42) === > > In phase 1 of this change, we will focus on moving the content > included in the grub and shim packages from `/boot` and `/boot/efi` to > `/usr` and adding the logic needed to install them to `/boot` as part > of a posttrans script. This would be great. > Moving the content from `/boot` and `/boot/efi` to `/usr` (in the RPM > packages) is a pre-requisite for all the potential future improvements > as it decouples the bootloader installation phase via the RPM (that > happens offline for all image mode systems and image builds in > general) from the actual update in the ESP and any runtime EFI > variable updates. > > As we move the bootloader and shim to `/usr`, we now need a mechanism > to sync the content from `/usr` to `/boot` and the ESP (and the MBR > for BIOS systems, but we already have to do that). In all cases, the > current suggestion is to do this synchronization step as part of a > posttrans trigger at the end of the RPM transaction. > > The first suggested option is to add a “dumb” Bash script that copies > the new bootloader to the ESP partition. > > The second suggested option is to add scripts to the kernel/install.d > directory. Currently, when a new kernel gets installed, kernel-install > (systemd) runs and invokes a number of bash and python scripts in > `/usr/lib/kernel/install.d/` which make the initramfs, create BLS > entries, etc. We could extend kernel-install to add a new action that > will be triggered when the relevant components (shim, grub2, sd-boot) > are updated. > > The third option is to adapt bootupd to install the updated bootloader > to cover this case and run as part of the posttrans trigger. It's a very good question which of the three approaches should be taken. I don't think kernel-install is the tool that should be used to install a bootloader. As the name says, it is for kernels, and has a lot of logic for details of how the initrds, µcode, modules, etc. should be handled. If we were to extend this with logic for the bootloader, most existing plugins wouldn't make any sense and would most likely need to be disabled. systemd has 'bootctl install/update' that install or updates the sd-boot bootloader. It has logic for updating EFI files and variables, comparing versions in binaries for conditional updates, etc. So this would seem a much better place to add functionality related to bootloader installation. In the past we talked in systemd upstream about adding support in 'bootctl install' to generalize it to allow some files to placed in a directory structure somewhere under /usr and install those files into the ESP. I think the details were never really figured out. But maybe this idea should be pursued further. Zbyszek -- _______________________________________________ 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
