From Fedora Project Wiki
(Announcing the Change proposal)
(Change submitted to FESCo)
Line 45: Line 45:
  
 
== Current status ==
 
== Current status ==
[[Category:ChangeAnnounced]]
+
[[Category:ChangeReadyForFesco]]
 
<!-- 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 -->
Line 62: 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
 
-->
 
-->
* FESCo issue: <will be assigned by Wrangler>
+
* FESCo issue: [https://pagure.io/fesco/issue/2563 #2563]
 
* Tracker bug: <will be assigned by Wrangler>
 
* Tracker bug: <will be assigned by Wrangler>
 
* Release notes tracker: <will be assigned by Wrangler>
 
* Release notes tracker: <will be assigned by Wrangler>

Revision as of 14:36, 26 January 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-01-26
  • FESCo issue: #2563
  • Tracker bug: <will be assigned by Wrangler>
  • Release notes tracker: <will be assigned by Wrangler>

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