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

[Steve McIntyre]

Hi Elliott,

On Mon, Jan 03, 2022 at 08:52:48AM -0800, Elliott Mitchell wrote:
>On Mon, Jan 03, 2022 at 02:35:48PM +0000, Steve McIntyre wrote:
>> 
>> 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).

The MBR/gap style is *totally specific* to the old-school x86 BIOS way
of doing things:

 * A tiny 16-bit x86 asm loader is added into the boot sector; it uses
   BIOS routines to load the GRUB core image from the raw space after
   the partition table and execute it.

 * The core image contains enough functionality (display, filesystems,
   storage drivers, etc.) to be able to find load further modules from
   the /boot filesystem. It loads those, runs the menu, etc.

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.

You have not identified the exact platform you're using, so I've no
idea exactly which of the above options is most likely.

>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.

Nope, sorry.

>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).

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"