On Mon, Jan 03, 2022 at 02:35:48PM +0000, Steve McIntyre wrote: > > On Sun, Dec 26, 2021 at 05:12:38PM -0800, Elliott Mitchell wrote: > > > >Hopefully the subject tells the tale. Due to some odd hardware, I need > >to force `grub-install` to install the EFI version of GRUB into the > >MBR/boot area gap. Unfortunately the documentation suggest none of > >`grub-install`'s options can get this result. As a result I've got a > >problem. > > > >The background: I'm trying to get GRUB installed on a very popular ARM64 > >device which has a full Tianocore/UEFI image available. Unfortunately > >while it is full Tianocore, the device lacks any private NVRAM and thus > >is unable to store EFI variables. > > > >`grub-install` tries to do a "normal" UEFI installation, which fails due > >to lack of EFI variables. As a result I need GRUB to install in the > >MBR/GPT gap, but none of `grub-install`'s options appear to cause this. > > What you're asking for here won't work; arm64 devices don't/can't use > the embedding MBR/gap style of GRUB installation - that's x86 only. Instead, > what you need is to do an EFI installation but with a couple of extra > options chosen. Run "dpkg-reconfigure -plow grub-efi-arm64" and say: > > * "yes" to "Force extra installation to the EFI removable media path?" > * "no" to "Update NVRAM variables to automatically boot into Debian?" > > and and you should be fine from now on.
Justify the statement "arm64 devices don't/can't use the embedding MBR/gap style of GRUB installation". I concur that is not the normal way of doing EFI installation on ARM64 devices, but in this case I've got a device which is unable to store persistent variables (if you sacrifice a SD Card it can store them, but otherwise it loses them on restart). Yet somehow despite restarting from a mostly clean slate an older installation of 2.02+dfsg1-20+deb10u4 keeps managing to manifest, while 2.04-20 is unable to be loaded. My conclusion is 2.02+dfsg1-20+deb10u4 was able to successfully install in the embedding area despite not being supposed to work. Meanwhile I'm guessing Tianocore/ARM64 inherited the ability to boot from the embedding area, despite using that being strongly discouraged. 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. (now back to pondering whether grub-uboot may still be a more maintainable for this installation) -- (\___(\___(\______ --=> 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
