On Sat, Jan 30, 2021 at 11:46 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Sat, Jan 30, 2021 at 6:43 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > On Sat, Jan 30, 2021 at 11:28 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > 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? > > > > No, currently grub2 provides the expected binary there on ARMv7 and > > ATM shim provides no extra value as there's not current intention to > > provide it. The pieces we have in place have worked quite well for IoT > > on ARMv7. > > > > There has been some mutterings from the arm ecosystem as there's a > > number of companies there interested in secure boot on ARMv7 but I'm > > yet to see any actual commitments in that space. With the ability for > > U-Boot now to support it and the EBBR spec evolving to add it that may > > change later in the year and if that does happen it would be easy > > enough to adjust to add it in. > > Would it be too much extra work to see if we can get that added as > part of the next rev of the shim package? We already know one is > coming in about a month, so it'd be nice to just get that in place > regardless if possible. My understanding is yes it's more work, and I explicitly don't want to put extra pressure on that team for something that adds no current value or useful functionality to ARMv7. I feel getting a new version of shim out for the other architectures in a timely manner is of more value to the project as a whole. _______________________________________________ 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
