On Mon, Jan 18, 2021 at 10:21 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/ARMv7UEFI > > == Summary == > > Move ARMv7 to use UEFI as default for all armhfp generated images > > == Owner == > * Name: [[User:pbrobinson| Peter Robinson]] > * Email: pbrobinson at fedoraproject dot org > > > == 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: [https://pagure.io/releng/issue/9946 #9946] (a > check of an impact with Release Engineering is needed) > * 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 > Will we also get a shim binary for this? The shim spec file has noted that it's possible to produce one for ARMv7, we just haven't had a need for it yet, since we don't use UEFI for ARM. Now that this is changing, will we get one? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
