From Fedora Project Wiki
mNo edit summary
m (Update to Fedora Atomic Desktops)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Enable bootupd for Fedora Silverblue & Kinoite =
= Enable bootupd for Fedora Atomic Desktops and Fedora IoT =




== Summary ==
== Summary ==


By design, ostree does not manage bootloader updates as they can not (yet) happen in a safe fashion. To solve this issue, bootupd (https://github.com/coreos/bootupd) was created. bootupd is a small socket activated program that takes care of updating the bootloader. It currently only supports EFI booted systems and rpm-ostree based systems. The updates are triggered by an administrator and are not (yet) automated for safety reasons. This change is about enabling bootupd integration in Fedora Silverblue and Fedora Kinoite to make bootloader updates easier. bootupd is already used in Fedora CoreOS.
By design, ostree does not manage bootloader updates as they can not (yet) happen in a safe fashion. To solve this issue, bootupd (https://github.com/coreos/bootupd) was created. bootupd is a small socket activated program that takes care of updating the bootloader. It currently only supports EFI booted systems and rpm-ostree based systems. The updates are triggered by an administrator and are not (yet) automated for safety reasons. This change is about enabling bootupd integration in Fedora Atomic Desktops and Fedora IoT to make bootloader updates easier. bootupd is already used in Fedora CoreOS.


== Owner ==
== Owner ==


* Name:[[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš Popela]], [[User:Walters| Colin Walters]]  
* Name:[[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš Popela]], [[User:Walters| Colin Walters]], [[User: Pwhalen| Paul Whalen]]  
* Email: <siosm@fedoraproject.org>, <tpopela@fedoraproject.org>, <walters@fedoraproject.org>
* Email: <siosm@fedoraproject.org>, <tpopela@fedoraproject.org>, <walters@fedoraproject.org>, <pwhalen@fedoraproject.org>




Line 34: Line 34:
* FESCo issue: [https://pagure.io/fesco/issue/2900 #2900]
* FESCo issue: [https://pagure.io/fesco/issue/2900 #2900]
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2150982 #2150982]
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2150982 #2150982]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/932 #932]
* Release notes tracker: [https://gitlab.com/fedora/docs/fedora-linux-documentation/release-notes/-/issues/47 #47]


== Detailed Description ==
== Detailed Description ==
Line 44: Line 44:
** https://bugzilla.redhat.com/show_bug.cgi?id=2127995
** https://bugzilla.redhat.com/show_bug.cgi?id=2127995


* 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:
* 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/IoT requiring manual interventions from all users. See:
** https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/
** https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/
** https://github.com/fedora-silverblue/issue-tracker/issues/120
** https://github.com/fedora-silverblue/issue-tracker/issues/120
Line 65: Line 65:
== Benefit to Fedora ==
== 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 more reliable.
Fedora Atomic Desktops and Fedora IoT 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 more reliable.


<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?

Latest revision as of 09:10, 7 June 2024

Enable bootupd for Fedora Atomic Desktops and Fedora IoT

Summary

By design, ostree does not manage bootloader updates as they can not (yet) happen in a safe fashion. To solve this issue, bootupd (https://github.com/coreos/bootupd) was created. bootupd is a small socket activated program that takes care of updating the bootloader. It currently only supports EFI booted systems and rpm-ostree based systems. The updates are triggered by an administrator and are not (yet) automated for safety reasons. This change is about enabling bootupd integration in Fedora Atomic Desktops and Fedora IoT to make bootloader updates easier. bootupd is already used in Fedora CoreOS.

Owner


Current status

Detailed Description

Adding full bootupd support has two immediate benefits:

Note that we can not yet enable unattended bootloader updates as even though bootupd tries 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 with that.

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: https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore

Feedback

> What's the plan to apply the outstanding security updates (shim, grub2, and dbx push from June) to fedora silverblue 36 + 37 that aren't covered by this change?

We'll try to backport as much as possible of this change to Fedora 37 and Fedora 36 to let users updates their bootloaders. If we require Anaconda changes (unlikely but not 100% sure at the time this is written) then those changes will not be backported as we don't respin the installer ISOs.


Benefit to Fedora

Fedora Atomic Desktops and Fedora IoT 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 more reliable.


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 Fedora CoreOS.
  • 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: https://github.com/fedora-silverblue/issue-tracker/issues/120 and https://github.com/fedora-silverblue/issue-tracker/issues/355.

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 updates.

Dependencies

N/A

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 https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/.

Release Notes

Will have to be written.