Bug#1002670: grub2-common: Unable to force MBR/embedding installation

[Elliott Mitchell]

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+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445