Changes/uEFIforARMv7

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

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 29
• Last updated: 2018-07-03
• Tracker bug: <will be assigned by the Wrangler>

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 (not a System Wide Change)

• 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