< Changes
Pbrobinson (talk | contribs) (Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...") |
(Add trackers) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 45: | Line 45: | ||
== Current status == | == Current status == | ||
[[Category:ChangeAcceptedF34]] | |||
<!-- 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:ChangeReadyForWrangler--> | |||
[[Category:SelfContainedChange]] | |||
* Targeted release: [[Releases/34 | Fedora 34 ]] | * Targeted release: [[Releases/34 | Fedora 34 ]] | ||
* 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}} | ||
| Line 55: | Line 62: | ||
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: | * FESCo issue: [https://pagure.io/fesco/issue/2563 #2563] | ||
* Release notes tracker: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1924097 #1924097] | ||
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/648 #648] | |||
== Detailed Description == | == Detailed Description == | ||
| Line 73: | Line 81: | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: | * Release engineering: [https://pagure.io/releng/issue/9946 #9946] (a check of an impact with Release Engineering is needed) | ||
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 147: | Line 155: | ||
--> | --> | ||
To be written once process is complete | To be written once process is complete | ||
Latest revision as of 15:51, 2 February 2021
uEFI for ARMv7
Summary
Move ARMv7 to use UEFI as default for all armhfp generated images
Owner
- Name: Peter Robinson
- Email: pbrobinson at fedoraproject dot org
- Release notes owner:
Current status
- Targeted release: Fedora 34
- Last updated: 2021-02-02
- FESCo issue: #2563
- Tracker bug: #1924097
- Release notes tracker: #648
Detailed Description
In Fedora 30 we tried to move ARMv7 to UEFI and as part of that change we got all the infrastructure changes in place as described in that change. It turned out there were issues with upstream kernel, bootloaders and a number of other pieces out of our control. Those pieces of the puzzle are now fixed and we've been building the core pieces since before Fedora 33 so we know it's now fixed and working having engaged with upstream since.
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: Changes to kickstarts.
- Other developers: None, all the required changes landed as part of the prior feature, this is just flipping the switch.
- Release engineering: #9946 (a check of an impact with Release Engineering is needed)
- List of deliverables: N/A
- Policies and guidelines: N/A
- 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 standardises the arm architectures ultimately making things more straight forward and eventually allowing code clean up.
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 are no dependencies. The changes required are artefact output. I will work with release engineering on this.
Contingency Plan
- Contingency mechanism: Revert back to current extlinux boot process. The IoT Edition has been supporting this method since Fedora 33 and it's reported to work fine. We produced prototype Workstation/Server/Minimal images in Fedora 33 with few issues.
- Contingency deadline: Beta Freeze
- Blocks release? Yes
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