(Initial page) |
m (Update) |
||
Line 7: | Line 7: | ||
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. | 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. | ||
== Owner == | |||
* [[User:Siosm| Timothée Ravier]] <siosm@fedoraproject.org> | |||
* [[User:Tpopela| Tomáš Popela]] <tpopela@fedoraproject.org> | |||
* [[User:Walters| Colin Walters]] <walters@fedoraproject.org> | |||
* | |||
< | |||
* | |||
* | |||
== Current status == | == Current status == | ||
[[Category:ChangePageIncomplete]] | [[Category:ChangePageIncomplete]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
Line 31: | Line 24: | ||
<!-- Select proper category, default is Self Contained Change --> | <!-- Select proper category, default is Self Contained Change --> | ||
[[Category:SelfContainedChange]] | [[Category:SelfContainedChange]] | ||
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/ | * Targeted release: [https://docs.fedoraproject.org/en-US/releases/f38/ Fedora Linux 38] | ||
* 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 | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
Line 47: | Line 39: | ||
== Detailed Description == | == Detailed Description == | ||
This will | 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: | |||
** https://github.com/fedora-silverblue/issue-tracker/issues/355 | |||
** 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: | |||
** https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/ | |||
** https://github.com/fedora-silverblue/issue-tracker/issues/120 | |||
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 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 == | == 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. --> | <!-- 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 == | == 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. | |||
<!-- 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? | ||
Line 84: | Line 94: | ||
== Scope == | == 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 | |||
* Release engineering: | * Policies and guidelines: N/A | ||
* Trademark approval: N/A | |||
* Alignment with Objectives: N/A | |||
* Policies and guidelines: N/A | |||
* Trademark approval: N/A | |||
* Alignment with Objectives: | |||
== Upgrade/compatibility impact == | == 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 == | == 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 == | == User Experience == | ||
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/. | |||
== Dependencies == | == Dependencies == | ||
N/A | |||
== Contingency Plan == | == 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 | |||
* Contingency deadline: | |||
* Blocks release? | |||
== 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/. | |||
== Release Notes == | == Release Notes == | ||
Will have to be written. | |||
<!-- 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 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. | <!-- 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. |
Revision as of 22:43, 8 November 2022
Enable bootupd for Fedora Silverblue & Kinoite
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.
Owner
- Timothée Ravier <siosm@fedoraproject.org>
- Tomáš Popela <tpopela@fedoraproject.org>
- Colin Walters <walters@fedoraproject.org>
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2022-11-08
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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 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
None so far.
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.
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
- Trademark approval: N/A
- 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
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/.
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.