(Created page with "<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> = Unified Kernel Support Phase 1 = {{Change_Proposal_Banner}} == Summary == <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fe...") |
(→Owner) |
||
Line 20: | Line 20: | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
--> | --> | ||
== Current status == | == Current status == |
Revision as of 14:38, 26 September 2022
Unified Kernel Support Phase 1
Summary
Add support for unified kernels images to Fedora.
Owner
- Name: Gerd Hoffmann
- Email: kraxel@redhat.com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2022-09-26
- 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
The goal is to move away from initrd images being generated on the installed machine. They are generated while building the kernel package instead, then shipped as part of a unified kernel image.
A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature. The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot.
Main motivation for this move is to make the distro more robust and more secure.
Feedback
Benefit to Fedora
Scope
- Proposal owners:
- Other developers:
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
Upgrade/compatibility impact
How To Test
User Experience
Dependencies
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Documentation
N/A (not a System Wide Change)