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

[Elliott Mitchell]

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

The platform is Tianocore built for the particular hardware.

While the hardware does have a SD controller, since there is no card
present it couldn't be loaded from there (no eMMC).  As such it is
definitely coming from what Linux sees as /dev/sda (via USB3 since that
hardware is available).

Now, since everything on the VFAT filesystem used by both the initial
stage loader and Tianocore was moved to a subdirectory, the older
version isn't coming from there (unless Tianocore does the equivalent of
a `find` during load, which seems unlikely).

As such I'm pretty sure Tianocore is finding the older GRUB by looking in
the gap between the GPT entries and data start.


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

The former isn't possible.  I am though wondering if use of the
"--removable" option will resolve the situation.  When it comes down to
it, all storage media is removable just an issue of how difficult it is
to remove and replace.  Since this one is via USB3 it is pretty simple to
swap out, but I could see internal storage being attached via USB3...


-- 
(\___(\___(\______          --=> 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