From Fedora Project Wiki
(Add trackers)
 
(3 intermediate revisions by the same user 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 147: Line 155:
 
-->
 
-->
 
To be written once process is complete
 
To be written once process is complete
 
[[Category:ChangeReadyForWrangler]]
 
<!-- 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]]
 

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

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