Grub crashing in mm.c when trying to boot Fedora 39 live USB

Hi,

I created a Fedora 39 live USB stick to install Fedora 39 on my new desktop PC (running fine under Windows 11 Pro). I can boot the USB stick and reach the grub menu. After I select the first item in the menu to launch Fedora 39 live, I get the following error message and the PC halts.

error: ../../grub-core/kern/mm.c:552:out of memory.

I understand this happens in grub even before the Linux kernel is started. I used the Fedora-Workstation-Live-x86_64-39-1.5.iso for the USB stick creation. I tried Ubuntu 23.10 live using the same USB stick and it worked. So I don’t think anything is wrong with my PC’s hardware or the USB stick.

Is this a grub bug?

Configuration

  • Intel i7-14700K CPU
  • Asus ProArt Z790-CREATOR WIFI motherboard
  • 4 x Ripjaws S5 DDr5-5600 CL36 32GB UDIMMs => total of 128GB RAM (maximum for this CPU)
  • Secure Boot for “other OS” activated in the BIOS (same crash if Secure Boot “Windows UEFI” was set in the BIOS)

If booting from that ISO the machine should never display the grub menu but boot directly to the live fedora environment where the user can start an install or test fedora. When booting directly to the live environment it should see the system as it is and not limit the available memory.

With hundreds of installations of fedora over the years and many different releases I have never once seen a live media iso display a grub menu during boot.

How was the file written to the USB? Using dd? mediawriter? rufus? or something else?
Was it copied onto the usb device or was it written as an iso onto the device so the usb device appears exactly as the iso?

1 Like

For some unknown reason Fedora Mediawriter isn’t working reliably on my fresh Windows 11 Pro installation. So I resorted to using Rufus. And I remember Rufus asking something about downloading a grub component matching the grub release detected in the ISO file.

To eliminate any Windows or antivirus interference in the USB stick creation, I just recreated the Fedora Live USB stick using plain old “dd” command line method on a RHEL 9.3 server.

sudo dd if=Fedora-Workstation-Live-x86_64-39-1.5.iso of=/dev/sdf bs=8M status=progress oflag=direct

Unfortunately the result is the same. First a boot menu is displayed looking like this.

GRUB version 2.06
-------------------------------
Start Fedora-Workstation-Live 39
Test this media & start Fedora-Workstation-Live 39
Troubleshooting -->

When I select “Start Fedora-Workstation-Live 39”, I get

error: ../../grub-core/kern/mm.c:552:out of memory.

A wild guess that could be totally wrong:

With 128GB of ram, it might be possible that there is some kind of integer overflow and grub things that the available memory is very small.

To test this, you could remove some of the memory modules and see what happens.

I have been thinking along these lines. But the same version of grub is used in RHEL 9.3 which is certainly running well on servers with much more RAM than 128 GB.

Removing UDIMMs would be very painful because it would require me to unmount the CPU cooler and the put back termal paste before mounting the CPU cooler again.

I finally opened the PC case and removed 3 out of the 4 UDIMMs leaving only 32 GB of RAM. Unfortunately grub 2.06 on the Fedora USB Live USB stick (using a different USB device) still fails in the same way.

error: ../../grub-core/kern/mm.c:552:out of memory.

I also booted again an Ubuntu 23.10 Live USB stick which is working as expected. This uses grub 2.12rc1. So grub 2.12rc1 works well for my system whereas grub 2.06 keeps failing.

I checked the Fedora Rawhide repository: grub 2.06 is still being used there. So it’s quite possible Fedora 40 will stick with grub 2.06.

Thanks for trying. At this point I believe you should report this to https://bugz.fedoraproject.org/grub2 and report anything you tried and your configuration. Also that Ubuntu grub works.

The Fedora grub2 is a heavily modified version of 2.06, so it may or may not have bagported fixes from later version of upstream grub.

Thanks.

I just submitted to bugzilla.

Hello @mtadault ,
I think this is the issue you are having, and it is related to grub2 linux - Grub2 loopback command out of memory - Unix & Linux Stack Exchange.
It would appear to be something about the image size? So is the size limit related to page size of memory not physical memory amount?

Hi @jakfrost,

I had a look at the grub.cfg file on the Fedora live boot iso. I didn’t see any loopback command. See below.

What do you mean by “image size”? The size of the iso file? I write my boot USB sticks using the dd command to be as close as possible to the desired USB boot stick layout. I checked the checksum of the iso file. It has not been altered.

What is “memory page size”? How do you modify this?

$ sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-39-1.5.iso /mnt
$ cat /mnt/boot/grub2/grub.cfg
set default="1"

function load_video {
  insmod all_video
}

load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
insmod chain

set timeout=60
### END /etc/grub.d/00_header ###

search --no-floppy --set=root -l 'Fedora-WS-Live-39-1-5'

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Start Fedora-Workstation-Live 39' --class fedora --class gnu-linux --class gnu --class os {
        linux /images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-39-1-5  rd.live.image quiet rhgb
        initrd /images/pxeboot/initrd.img
}
menuentry 'Test this media & start Fedora-Workstation-Live 39' --class fedora --class gnu-linux --class gnu --class os {        linux /images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-39-1-5  rd.live.image rd.live.check quiet
        initrd /images/pxeboot/initrd.img
}
submenu 'Troubleshooting -->' {
        menuentry 'Start Fedora-Workstation-Live 39 in basic graphics mode' --class fedora --class gnu-linux --class gnu --class os {
                linux /images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-39-1-5  rd.live.image nomodeset vga=791 quiet rhgb
                initrd /images/pxeboot/initrd.img
        }
        menuentry 'Boot first drive' --class fedora --class gnu-linux --class gnu --class os {
                chainloader (hd0)+1
        }
        menuentry 'Boot second drive' --class fedora --class gnu-linux --class gnu --class os {
                chainloader (hd1)+1
        }
}

I was referring to the actual image being loaded by the media and how it is initially loaded into memory.

This is BIOS settings I thought, and page size on large memory setups is important I believe to the OS being booted. Especially in the case of a live image that loads into ram. At least that’s my take on it FWIW.