Pbrobinson (talk | contribs) No edit summary |
m (Add release notes tracker) |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
<!-- Self Contained or System Wide Change Proposal? | <!-- Self Contained or System Wide Change Proposal? | ||
Use this guide to determine to which category your proposed change belongs to. | Use this guide to determine to which category your proposed change belongs to. | ||
| Line 47: | Line 45: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/30 | Fedora 30 ]] | ||
* 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 57: | Line 55: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1602948 #1602948] | ||
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/283 #283] | |||
== Detailed Description == | == Detailed Description == | ||
| Line 75: | Line 74: | ||
* Release engineering: [https://pagure.io/releng/issue/7606 #7606] (a check of an impact with Release Engineering is needed) | * Release engineering: [https://pagure.io/releng/issue/7606 #7606] (a check of an impact with Release Engineering is needed) | ||
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A | ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* Policies and guidelines: N/A I don't believe this changes any policies or guidelines <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Policies and guidelines: N/A I don't believe this changes any policies or guidelines <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 154: | Line 153: | ||
To be written once process is complete | To be written once process is complete | ||
[[Category: | [[Category:ChangeAcceptedF30]] | ||
<!-- 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 --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Latest revision as of 17:22, 21 January 2019
uEFI for ARMv7
Summary
Move to uEFI as the default boot mechanism for ARMv7 devices.
Owner
- Name: Peter Robinson
- Email: pbrobinson at fedoraproject dot org
- Release notes owner:
Current status
- Targeted release: Fedora 30
- Last updated: 2019-01-21
- Tracker bug: #1602948
- Release notes tracker: #283
Detailed Description
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has served us very well and has allowed us to standardise the ARMv7 boot process with the vast majority of devices booting this way OOTB due to the support being in a wide variety of u-boot releases. Over recent years there have been a number of improvement to uEFI including robust support in u-boot. We've supported uEFI on aarch64 as the only way of booting Fedora supporting both Tianocore, proprietary uEFI implementations and since Fedora 27 we've supported uEFI via u-boot too. The uEFI provided by u-boot is now stable enough that we can now move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi and have a single standard booth path/stack for both ARMv7 and aarch64.
Benefit to Fedora
This allows ARMv7 to move to grub2 providing the same experience to ARMv7 users as all other architectures across the distribution. It simplifies a number of software stacks across the distribution due to being able to use a single install/support/upgrade path as well as providing a single set of docs.
Scope
- Proposal owners: Patches, updates to the process, testing
- Other developers: System component owners will need to review and merge patches for certain components.
- Release engineering: #7606 (a check of an impact with Release Engineering is needed)
- List of deliverables: N/A
- Policies and guidelines: N/A I don't believe this changes any policies or guidelines
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Upgrades from prior versions of Fedora will continue to work as they do currently. Devices booting with extlinux will continue to upgrade and work as planned. For recent (F-25 and later) clean installs there will be a documented migration process for those that wish to migrate to grub2 boot process. For older installs (those without a VFAT partition for firmware) will need to do a clean install. Devices with non Fedora built u-boot will need to ensure they have a recent enough u-boot to support the required uEFI functionality.
How To Test
The process for testing will be the same as aarch64. This process will be further updated and expanded once all the components are in place and the final process is known.
User Experience
The user experience will be the same as uEFI on aarch64 and x86_64 with the grub2 menu and features. This will provide a consistent experience across all Fedora architectures and resolves a number of issues seen with the basic extlinux menu system on ARMv7.
Dependencies
There's patches need for the following software in Fedora:
- anaconda stack - anaconda/blivet/lorax
- build dependencies - oz/imagefactory
- grub2-efi build for ARMv7
- support in virt stack - virt-manager/virt-install
Contingency Plan
- Contingency mechanism: Revert back to current extlinux boot process. The support for this process will remain and these images will continue to be built along side the new images until we're certain the new boot process is robust.
- Contingency deadline: Beta Freeze
- Blocks release? Yes
- Blocks product? IoT
Documentation
Yes. There will need to be a review of the documentation pertaining to ARMv7, in a lot of cases this will be deleting the old process so the universal distribution defaults are the only docs.
Release Notes
To be written once process is complete