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 ==
By design, ostree does not manage bootloader updates as they can not
(yet) happen in a transactional, atomic and safe fashion. Thus 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.
== Owner ==
* [[User:Siosm| Timothée Ravier]] <siosm(a)fedoraproject.org>
* [[User:Tpopela| Tomáš Popela]] <tpopela(a)fedoraproject.org>
* [[User:Walters| Colin Walters]] <walters(a)fedoraproject.org>
== Detailed Description ==
Adding bootupd full bootupd support has two immediate benefits:
* User will be able to easily update the bootloader on their system.
This will let them apply Secure Boot dbx updates that block old
bootloaders with known vulnerabilities from loading. See:
* We can start planning for the removal of the ostree-grub2 package
from the images to solve the "all deployments are shown twice in GRUB"
issue. This bug comes from the fact that old GRUB versions that do not
have BLS support and we thus can not only rely on BLS support in
ostree to generate boot and have to also update the grub configuration
for every updates via the scripts in the ostree-grub2 package. This
has already (indirectly) caused a major upgrade issue on
Silverblue/Kinoite requiring manual interventions from all users. See:
Note that we can not yet enable unattended bootloader updates as even
though bootupd tries hard hard to make those updates as safe as
possible, it is currently not possible that they are safe if the
system crashes (or loses power) at the wrong time. The following
change in shim (https://github.com/rhboot/shim/pull/502
) should help
Thus bootloaders updates will remain a manually user triggered
operation for now.
Also note that this change currently relies on the image being
composed via rpm-ostree in unified core, which is the subject of the
following change also proposed for Fedora 38:
== Feedback ==
None so far.
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
Fedora Silverblue and Fedora Kinoite users can easily do bootloaders
updates (that includes security fixes) and we can remove support for
legacy GRUB versions thus simplify the upgrade process and making it
== Scope ==
* Proposal owners: Testing of the integration and new builds. The code
changes are mostly done and the integration changes are mostly already
ready as bootupd has already been integrated in a similar fashion in
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
There should be not visible change for users when upgrading. The
change only impacts the way the images are composed on the server.
== How To Test ==
We will extend the test instructions once the unified core changes
have landed. You can follow:
== User Experience ==
For now, users will have to update their bootloader manually via the
command line. Integration to GNOME Software and Plasma Discover might
be interesting to make that easier.
Once the fallback EFI feature is available in shim (and support
implemented in bootupd), we can consider implementing automated
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert the change in the rpm-ostree
manifests. Owners will do it. Nothing to do for users.
* Contingency deadline: Can happen anytime.
* Blocks release? No
== Documentation ==
We will write docs to let users update their bootloaders manually.
They will look very similar to
== Release Notes ==
Will have to be written.
He / Him / His
Fedora Program Manager