On Mon, Jan 03, 2022 at 05:17:19PM +0000, Steve McIntyre wrote:
>
> On Mon, Jan 03, 2022 at 08:52:48AM -0800, Elliott Mitchell wrote:
> >
> arm64 machines categorically do *not* have any capability to run this
> way. It has never been a thing. Instead, systems running GRUB will
> load GRUB as a UEFI binary from an EFI System Partition (ESP) and go
> from there. Depending on the exact installation on your system, you
> may have an ESP on removable storage (SD?), on hard drive / SSD, or
> maybe on internal eMMC or similar. It's possible you could be loading
> from the network too, but I assume you'd know if that was happening.
Finally figured out what was occurring. I believe your statement "a UEFI
binary from an EFI System Partition (ESP)" is wrong. Appears Tianocore
will load UEFI binaries from diskslices which simply contain filesystems
it understands.
> You have not identified the exact platform you're using, so I've no
> idea exactly which of the above options is most likely.
A cheap and popular ARM64 device which got a Tianocore implementation
fairly quickly due to its level of popularity. Trick is it doesn't have
NVRAM available for storage of EFI variables, so `grub-install` cannot
make itself the default boot method.
I would suggest the "EFI variables are not supported on this system."
warning/error message needs more information.
In Tianocore's configuration (boot menu) I needed to go in and select
"Add boot method" and navigate to where `grub-install` put grubaa64.efi.
Then I simply needed to tell Tianocore to have that as the highest
priority boot method.
> >Or at least that is a simple explanation for why traces of
> >2.02+dfsg1-20+deb10u4 continue to persist, while 2.04-20 appears
> >reluctant.
>
> My first guess would be that either:
>
> * You have more than one ESP on your system somewhere, and the system
> is finding an old grub binary that way; or
>
> * The old grub is in the removable media path and you haven't managed
> to replace it yet (see my first mail for details on how to do
> that).
I finally found the 2.02+dfsg1-20+deb10u4 "grubaa64.efi".
It was on /dev/sda128 which was marked with a type UUID of
bc13c2ff-59e6-4262-a352-b275fd6f7172 ("Linux extended boot" according to
`fdisk`).
/dev/sda128 contained an ISO9660 filesystem which was the previous
Debian netinst ISO image.
The message "EFI variables are not supported on this system." was less
than wonderful for figuring out what to do next.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sig...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
