Hi,
tl;dr: Grub boots my OS just fine, but it gives "error: out of memory."
when attempting to boot loopback accessed ISOs and (worryingly) also
while attempting "ls (hd1,gpt1)/ISOs/xxxx.iso" at the "grub >" prompt.
How do I go about finding out where the memory has gone? [supplementary,
related questions highlighted with ## below.]
I'll start by saying this was all previously working just fine. I'm
assuming that it (potentially) stopped working when I replaced the
motherboard, which means Grub now gets booted from different
hardware/firmware.
I'm using Grub 2.06-13~deb12u1, which is just a regular, "off the
shelf", Debian build of grub.
Grub boots my OS (Debian 12 - Bookworm) just fine.
I have several grub "menuentry"s that use something like...
menuentry "Debian GNU/Linux Live (Bookworm/kernel 6.1.0-35-amd64)" {
search --no-floppy --fs-uuid 73929bb1-21ff-4183-9241-e1d2856cda54 --set=root
set isofile="/ISOs/debian-live-12.11.0-amd64-standard.iso"
loopback loop $isofile
linux (loop)/live/vmlinuz-6.1.0-35-amd64 boot=live findiso=${isofile}
components
initrd (loop)/live/initrd.img-6.1.0-35-amd64
}
... and I'm pretty confident they're all fine (because they all
previously worked as expected/intended).
But now, it just gives me "error: out of memory".
I'm assuming the difference is that the changed motherboard is now doing
something different. It was previously a Gigabyte motherboard, now Asus
H170M-PLUS with Intel i7-6700 @ 3.4GHz and 32GB dram. I just use
integrated graphics, not PCIe graphics. It boots through UEFI.
Sizes I'm trying to boot are, for example:
Debian Live: vmlinuz 7.9M initrd.img 57M (ISO is 1.5G)
SystemRescue: vmlinuz 14M sysresccd.img 104M (ISO is 1.1G)
... not too outrageous? [##]
In contrast, my (working) Debian OS has vmlinuz 7.9M and initrd.img 44M.
Surprisingly, if I go to the Grub shell, I even get "out of memory"
errors when I just try to do something simple like...
grub > ls (hd1,gpt1)/ISOs/debian-live-12.11.0-amd64-standard.iso
... surely, that's not right?
I've spent a lot of time Googling around and found lots of "out of
memory" Grub errors elsewhere, with the fix usually being either to (i)
reduce the graphics resolution (GRUB_GFXMODE) (ii) reduce the video
memory in the BIOS/UEFI (iii) reduce the size of the initrd.
Unfortunately, there doesn't seem to be much concrete information, just
a lot of "try this..." sort of "fumbling around in the dark"...
Obviously, I've tried the first two, without success. I'm pretty much
stuck with the initrd sizes that I'm supplied with though!
From what I've read, it looks as though Grub just gets the first 1GB of
memory to play around in and several chunks of that are already reserved
by the motherboard firmware, leaving not much free for Grub.
Is that correct? If so, what do I need to look at to put some numbers on
all of this? [##]
I've found the lsmmap and lsefimmap commands which look as though
they're in the right area, but what specifically do I need to look at?
[##] (I can supply phone pic screenshots if any use? I've discovered
"set pager=1" too!)
Also from what I've seen, a big problem is the firmware allocating a big
chunk of memory for the integrated graphics.
I *think* I've reduced this to the minimum (32MB) but the Asus UEFI
isn't at all clear or user friendly, so not 100% confident on that - can
I check what it's done in the lsmmap and lsefimmap commands somehow? [##]
Any other suggestions or pointers where to go on this? Are there any
other diags/debug that might be useful to understand what's happening? [##]
I'm intending to update Debian from v12 (Bookworm) to the (new-ish) v13
(Trixie) in around 3 month time, which will bring grub up to v2.12-9.
In the meantime, grub v2.12-1 is also available as a backport too.
Has anything changed between Grub 2.06-13 and these versions,
particularly in relation to EFI/memory allocation etc, that may make it
worthwhile upgrading grub/Debian sooner than planned? [##]
This isn't a blocking issue (yet?) - at least my main OS boots when
needed, it's just nice to have other ISO based tools readily available
in Grub, without having to mess around with USB sticks etc!
Thanks for your help everyone,
Alan D.
