From Fedora Project Wiki
(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...")
 
Line 73: Line 73:
 
<!-- 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: (a check of an impact with Release Engineering is needed)  
+
* 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 -->
  

Revision as of 12:38, 16 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-16
  • Tracker bug:
  • Release notes tracker:

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