I have encountered a situation where grub-efi-amd64 reports

    error: out of memory

in the pre-boot environment despite the system having an adequate amount
of RAM (8 GB). This occurs when attempting to load an ISO9660 image file
via loopback, e.g.

    loopback loop /path/to/debian-live-11.2.0-amd64-standard.iso

    (note that this ISO file is ~1 GB in size)

This issue is easily reproducible in VirtualBox with an EFI-based VM. I
do notice that a somewhat smaller ISO (systemrescue-10.01-amd64.iso,
~740 MB) is able to be loaded via loopback and booted. Also, this issue
does NOT occur on grub-pc with an equally-spec'ed BIOS-based VM; that
one can boot the same ISO file just fine.

This issue appears to match the following one from the Ubuntu side:

https://bugs.launchpad.net/bugs/1842320

That one revolved more around loading larger initrd files, which
prevented some users' installed systems from booting. The issue was
resolved earlier this year, so assuming it is the same as this one, a
fix should be readily available.

You have at most 4 GB of usable memory, high memory is not used here,
and hardware can fail to DMA if you try to use it, it's all very hard.

Yes, so please just try the 2.12~rc1-9 in unstable and see if it
fixes your issue.

Hi Julian,

I've confirmed that this version no longer gives the "out of memory"
error, and can load and boot the ISO images that previously failed.

Is this a long way from making it into stable? Or at least -backports?

Things are quite complex with the memory management patch set, while
I have a backport to 2.06 in Ubuntu, I also did not release the final
patch set there yet. There was concern of additional regressions from
that. But we know for sure the current state was regressing some, but
I guess they are all regressed now if that makes sense.

I can try to get the patches together for a stable update, but I think
we might want to wait until the final set landed in Ubuntu updates for
LTS so we don't get the regression potential on both ends (and we have
more control over the update phasing in Ubuntu than Debian).

For a wholesale upload of grub 2.12 to stable, we need to wait for
the final 2.12 release and also we don't plan to do this if we can
backport any security patches coming up to 2.06.

I think generally this is a low priority issue for Debian if you
can't loopback large images, and Debian doesn't have initrds as huge
as Ubuntu so that never became a significant issue.

Thanks for explaining the backstory on this issue. I was not aware that
the Ubuntu-side fix had yet to be finalized.

(I'm surprised that this has remained an issue so late in the EFI game.
I've avoided it till now by sticking to BIOS boot mode on my systems,
but that's just me---the rest of the world has moved on.)

Would bookworm-backports be a more feasible target in the short term?

The use case for this is booting into a live rescue system on an ISO
file on a hard drive, along the lines of what grml-rescueboot allows.
This is useful not just as a boot option when the regular OS eats
itself, but also as a way to run (re)imaging and other diagnostics that
are not possible when the OS partition is active.

I hope to avoid having to enable "Legacy Boot Mode" just to get this
working again...