From Fedora Project Wiki
(re targeting change for F41)
m (Add release notes)
 
(14 intermediate revisions by 4 users not shown)
Line 1: Line 1:
= Enable bootupd for Fedora Silverblue & Kinoite =
= 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, [https://github.com/coreos/bootupd bootupd] was created.
bootupd is a small program that takes care of updating the bootloader. It currently supports BIOS and EFI booted systems but only rpm-ostree based systems. The updates are triggered by an administrator and are not (yet) automated for safety reasons.


== Summary ==
This change is about enabling bootupd integration in Fedora Atomic Desktops and Fedora IoT to make bootloader updates easier and, hopefully in the future, automated.


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


== Current status ==
== Current status ==


[[Category:ChangeAcceptedF40]]
[[Category:ChangeAcceptedF41]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
[[Category:SelfContainedChange]]


* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f41/ Fedora Linux 41]
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f41/ Fedora Linux 41]
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
Bugzilla state meanings:
ASSIGNED -> accepted by FESCo with ongoing development
MODIFIED -> change is substantially done and testable
ON_QA -> change is fully code complete
-->
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VRJ7CRQUZ7SNEDW4AIOHKKJ7TMPTOX5A/ devel thread]
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VRJ7CRQUZ7SNEDW4AIOHKKJ7TMPTOX5A/ devel thread]
* 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 36:
** 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 53: Line 45:


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
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
Progress on this change is tracked in: https://gitlab.com/fedora/ostree/sig/-/issues/1.


== Feedback ==
== 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?


> 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 will not backport this change to a previous Fedora release.


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.
Users that need to update their bootloader can do so manually using the instructions from the [https://fedoramagazine.org/manual-action-needed-to-resolve-boot-failure-for-fedora-atomic-desktops-and-fedora-iot/ Manual action needed to resolve boot failure for Fedora Atomic Desktops and Fedora IoT] Fedora Magazine article.


<!-- 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. -->
<s>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.</s>


== 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?
 
      Be sure to include the following areas if relevant:
      If this is a major capability update, what has changed?
          For example: This change introduces Python 5 that runs without the Global Interpreter Lock and is fully multithreaded.
      If this is a new functionality, what capabilities does it bring?
          For example: This change allows package upgrades to be performed automatically and rolled-back at will.
      Does this improve some specific package or set of packages?
          For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.
      Does this improve specific Spins or Editions?
          For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server.
      Does this make the distribution more efficient?
          For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end.
      Is this an improvement to maintainer processes?
          For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly.
      Is this an improvement targeted as specific contributors?
          For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors.
 
    When a Change has multiple benefits, it's better to list them all.
 
    Consider these Change pages from previous editions as inspiration:
    https://fedoraproject.org/wiki/Changes/Annobin (low-level and technical, invisible to users)
    https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo (low-level, but visible to advanced users)
    https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration (primarily a UX change)
    https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
    https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->


== Scope ==
== Scope ==
Line 110: Line 77:
== How To Test ==
== 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.
On a system with bootupd installed (i.e. a version of Fedora with this change included), run:
 
<pre>
$ sudo bootupctl status
$ sudo bootupctl adopt-and-update
$ sudo bootupctl status
$ sudo bootupctl validate
</pre>
 
Your bootloader should now be updated.
 
New systems directly installed from a version with this change can directly do an update:
 
<pre>
$ sudo bootupctl status
$ sudo bootupctl update
$ sudo bootupctl status
$ sudo bootupctl validate
</pre>
 
On systems updated from previous Fedora releases, there may be validation errors as some components (the 32 bits variants) are missing as they were not installed by Anaconda in the past. This can be safely ignored:
 
<pre>
$ sudo bootupctl validate
Removed: BOOT/fbia32.efi
Removed: BOOT/fbx64.efi
Removed: fedora/grubia32.efi
Removed: fedora/BOOTIA32.CSV
Removed: fedora/shimia32.efi
Removed: fedora/mmia32.efi
Removed: BOOT/BOOTIA32.EFI
error: Caught validation errors
</pre>
 
To test the initial adoption and update again, you can remove `/boot/bootupd-state.json` and try again:
 
<pre>
$ sudo rm /boot/bootupd-state.json
$ sudo bootupctl status
$ sudo bootupctl update
$ sudo bootupctl status
$ sudo bootupctl validate
</pre>
 
Until we get [https://github.com/coreos/bootupd/issues/707 #707] ([https://github.com/coreos/bootupd/pull/715 PR#715]), you will have to manually reset the systemd unit in case of failures:
 
<pre>
$ sudo systemctl reset-failed bootupd.service
</pre>
 
<s>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.</s>


== User Experience ==
== 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.
For now, users will have to update their bootloader manually via the command line. <s>Integration to GNOME Software and Plasma Discover might be interesting to make that easier.</s>
 
<s>Once the fallback EFI feature is available in shim (and support implemented in bootupd), we can consider implementing automated updates.</s>


Once the fallback EFI feature is available in shim (and support implemented in bootupd), we can consider implementing automated updates.
Once the remaining issues listed in https://gitlab.com/fedora/ostree/sig/-/issues/1 are resolved, we will enabled automatic bootloader updates.


== Dependencies ==
== Dependencies ==
Line 125: Line 144:


* Contingency mechanism: Revert the change in the rpm-ostree manifests. Owners will do it. Nothing to do for users.
* Contingency mechanism: Revert the change in the rpm-ostree manifests. Owners will do it. Nothing to do for users.
* Contingency deadline: Can happen anytime.
* Contingency deadline: Before final freeze as this change needs to be included in the installation ISOs as Anaconda behaves differently if bootupd is included or not in the installed system.
* Blocks release? No
* Blocks release? No


== Documentation ==
== 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/.
<s>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/.</s>
 
We don't need specific documentation anymore for that as we enabled bootloader updates by default.


== Release Notes ==
== Release Notes ==


Will have to be written.
On Atomic Desktops, the bootloader is now automatically updated using bootupd. New systems are now installed with a static GRUB configuration which relies only on the Boot Loader Specification configuration files and is not regenerated for each update.
 
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
 
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->

Latest revision as of 17:01, 24 October 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 was created.

bootupd is a small program that takes care of updating the bootloader. It currently supports BIOS and EFI booted systems but only 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 and, hopefully in the future, automated.

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

Progress on this change is tracked in: https://gitlab.com/fedora/ostree/sig/-/issues/1.

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 will not backport this change to a previous Fedora release.

Users that need to update their bootloader can do so manually using the instructions from the Manual action needed to resolve boot failure for Fedora Atomic Desktops and Fedora IoT Fedora Magazine article.

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

On a system with bootupd installed (i.e. a version of Fedora with this change included), run:

$ sudo bootupctl status
$ sudo bootupctl adopt-and-update
$ sudo bootupctl status
$ sudo bootupctl validate

Your bootloader should now be updated.

New systems directly installed from a version with this change can directly do an update:

$ sudo bootupctl status
$ sudo bootupctl update
$ sudo bootupctl status
$ sudo bootupctl validate

On systems updated from previous Fedora releases, there may be validation errors as some components (the 32 bits variants) are missing as they were not installed by Anaconda in the past. This can be safely ignored:

$ sudo bootupctl validate
Removed: BOOT/fbia32.efi
Removed: BOOT/fbx64.efi
Removed: fedora/grubia32.efi
Removed: fedora/BOOTIA32.CSV
Removed: fedora/shimia32.efi
Removed: fedora/mmia32.efi
Removed: BOOT/BOOTIA32.EFI
error: Caught validation errors

To test the initial adoption and update again, you can remove /boot/bootupd-state.json and try again:

$ sudo rm /boot/bootupd-state.json
$ sudo bootupctl status
$ sudo bootupctl update
$ sudo bootupctl status
$ sudo bootupctl validate

Until we get #707 (PR#715), you will have to manually reset the systemd unit in case of failures:

$ sudo systemctl reset-failed bootupd.service

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.

Once the remaining issues listed in https://gitlab.com/fedora/ostree/sig/-/issues/1 are resolved, we will enabled automatic bootloader 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: Before final freeze as this change needs to be included in the installation ISOs as Anaconda behaves differently if bootupd is included or not in the installed system.
  • 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/.

We don't need specific documentation anymore for that as we enabled bootloader updates by default.

Release Notes

On Atomic Desktops, the bootloader is now automatically updated using bootupd. New systems are now installed with a static GRUB configuration which relies only on the Boot Loader Specification configuration files and is not regenerated for each update.