9:58 a.m.
On Sat, Jan 30, 2021 at 11:46 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jan 30, 2021 at 6:43 AM Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> On Sat, Jan 30, 2021 at 11:28 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Mon, Jan 18, 2021 at 10:21 AM Ben Cotton <bcotton(a)redhat.com> 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.