When booting a Fedora 39 Live USB stick, the grub boot selection menu is shown. After choosing to start Fedora 39 Live, grub hangs with the following error message. 'error: ../../grub-core/kern/mm.c:552:out of memory.' PC configuration - Intel i7-14700K CPU - Asus ProArt Z790-CREATOR WIFI motherboard - 4 x G.Skill Ripjaws S5 DDr5-5600 CL36 32 GB UDIMMs => total of 128 GB 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) I can boot Ubuntu 23.10 (which uses grub 2.12rc1) Live USB stick and everything works. I have tried the following but Fedora 39 Workstation grub keeps hanging on this PC. - use different USB stick - use only one 32 GB UDIMM (instead of 4) => total memory of 32 GB - use Fedora-Silverblue-ostree-x86_64-39-1.5.iso or Fedora-KDE-Live-x86_64-39-1.5.iso - check RAM with memtest86 release 10 (built into PC firmware) for more than 7 hours => no RAM error detected Reproducible: Always Steps to Reproduce: 1. Get file 'Fedora-Workstation-Live-x86_64-39-1.5.iso' 2. Create USB stick using 'sudo dd if=Fedora-Workstation-Live-x86_64-39-1.5.iso of=/dev/sdf status=progress' 3. Boot PC using USB stick 4. When 'Grub version 2.06' boot selection is displayed, select 'Start Fedora-Workstation-Live 39' Actual Results: Grub hangs before booting the Linux kernel and shows the following error message: 'error: ../../grub-core/kern/mm.c:552:out of memory.' Need to turn off the PC and restart it. Expected Results: Fedora 39 Workstation boots and shows the Fedora desktop
Forget to mention: Windows 11 Pro runs fine on this new PC
Same error, so far I tried every possible way to write the ISO on multiple usb stick, including Fedora Media Writer on Fedora 39, dd, rufus on windows, balena etcher (both on fedora and windows), Ventoy, Ventoy custom (medicat), manually dumping the iso onto the usb stick. PC configuration: - Intel i7-13700K - Asus ProArt Z790-CREATOR WIFI motherboard - 2 x Crucial Pro DDr5-5600 32 GB UDIMMs - Same boot configuration, tried everything under the sun for BIOS settings.
Hi Michael, fedoraproject.i2yi8, Can you please do the following to enable a bit more debug output: While at the grub boot menu, press 'e' which will allow you to edit the grub boot script. Then add the following line: set debug=regions Finally, press Ctrl+x to boot. It should display some logs related to memory management. Paste the result here so we can take a look. Thanks, Nicolas
Hello Nicolas, Thanks for responding so quickly. I have copied (by hand, I hope there is no typo) the output logs from set debug=regions: ``` Booting a command list kern/mm.c:165: Using memory for heap: start=0xb4ed000, end=0xb5ed000 kern/mm.c:191: Can we extend into region above? 0xb4ed000 + 100000 + 0 ?=? 0xb5ed000 kern/mm.c:196: Yes: extending a region (0xb5ed000 -> 0xb5ed000) -> (0xb4ed000 -> 0xb5ed000) kern/mm.c:165: Using memory for heap: start=0xb3ed000, end=0xb4ed000 kern/mm.c:191: Can we extend into region above? 0xb3ed000 + 100000 + 0 ?=? 0xb4ed000 kern/mm.c:196: Yes: extending a region (0xb4ed000 -> 0xb5ed000) -> (0xb3ed000 -> 0xb5ed000) kern/mm.c:165: Using memory for heap: start=0xb3ed000, end=0xb4ed000 kern/mm.c:191: Can we extend into region above? 0xb3ed000 + 100000 + 0 ?=? 0xb4ed000 kern/mm.c:196: Yes: extending a region (0xb4ed000 -> 0xd5ed000) -> (0xb3ed000 -> 0xd5ed000) kern/mm.c:165: Using memory for heap: start=0xa5b1000, end=0xb3ed000 kern/mm.c:191: Can we extend into region above? 0xa5b1000 + e3c000 + 0 ?=? 0xb3ed000 kern/mm.c:196: Yes: extending a region (0xb3ed000 -> 0xd5ed000) -> (0xa5b1000 -> 0xd5ed000) kern/mm.c:165: Using memory for heap: start=0x524d000, end=0xa5b1000 kern/mm.c:191: Can we extend into region above? 0x524d000 + 5364000 + 0 ?=? 0xa5b1000 kern/mm.c:196: Yes: extending a region (0xa5b1000 -> 0xd5ed000) -> (0x534d000 -> 0xd5ed000) kern/mm.c:165: Using memory for heap: start=0x23d79000, end=0x27027000 kern/mm.c:191: Can we extend into region above? 0x23d79000 + 32ae000 + 0 ?=? 0x524d000 kern/mm.c:240: Can we extend into region below? 0x524d000 + 40 + 839ffc0 + 0 ?=? 0x23d79000 kern/mm.c:274: No: considering a new region at 0x23d79000 of size 32ae000 error: ../../grub-core/kern/mm.c:552:out of memory. Press any key to continue... ``` I hope this could help. If you need anything more, feel free to ask. I will do my best to respond as quickly as possible. Thanks, Corentin
Hi Nicolas, Thanks for looking into this issue. My output log is very similar to Corentin's kern/mm.c: 165: Using memory for heap: start=0x9454000, end=0xa231000 kern/mm.c: 191: Can we extend into region above? 0x9454000 + ddd000 + 0 ?=? 0xa231000 kern/mm.c:196: Yes: extending a region: (0xa231000 -> 0xc331000) -> (0x9454000 -> 0xc331000) kern/mm.c: 165: Using memory for heap: start=0x21d9d000, end=0x268dd000 kern/mm.c:191: Can we extend into region above? 0x21d9d000 + 4b40000 +0 ?=? 0x9454000 kern/mm.c:240: Can we extend into region below? 0x9454000 + 40 + 2edcfc0 + 0 ?=? 0x21d9d000 kern/mm.c:274: No: considering a new region at 0x21d9d000 of size 4b40000 kern/mm.c:165: Using memory for heap: start=0x1ed5f000, end=0x1fd33000 kern/mm.c:191: Can we extend into region above? 0x1ed5f000 + fd4000 + 0 ?=? 0x9454000 kern/mm.c:240: Can we extend into region below? 0x9454000 + 40 + 2edcfc0 + 0 ?=? 0x1ed5f000 kern/mm.c: 191: Can we extend into region above? 0x1ed5f000 + fd4000 + 0 ?=? 0x21d9d000 kern/mm.c:240: Can we extend into region below? 0x21d9d000 + 40 + 4b3ffc0 + 0 ?=? 0x1ed5f000 kern/m.c:274: No: considering a new region at 0x1ed5f000 of size fd4000 error : ../../grub-core/kern/mm.c:552:out of memory. Thanks, Michael
Hi Corentin, Michael, As this issue seems to happen on identical motherboards, I am wondering if it could be a motherboard firmware issue. Can you please post your motherboard firmware version and see if you can update it if there is a newer version ? Thanks, Nicolas
Hello Nicolas, I have the latest revision of the bios (2102 - 2024/03/19). Every other Firmware are up to date. Thanks, Corentin
Hi Nicolas, I was running BIOS version 1801. So I upgraded to BIOS version 2102 (19 March 2024). Unfortunately grub 2.06 of Fedora 39 Workstation Live is still hanging with: "error : ../../grub-core/kern/mm.c:552:out of memory." grub of Ubuntu 23.10 (which uses grub 2.12rc1) works well: Ubuntu 23.10 starts well. So this version of grub has no issue with this motherboard and firmware. Best regards, Michael Tadault
Hi Nicolas, I had the same problem with a HP ZBook. I reduced the dedicated memory of the integrated GPU from 512MB to 128MB (in BIOS settings). It's quite strange that on a 64GB machine, the area under 4GB is filled up that the 128MB is so much missing. :( Kind regards, Krisztian
Hi Krisztian, Did you manage to boot after you reduced the GPU memory ? Also what is the exact hardware on your HP Zbook ? (motherboard (chipset), cpu, memory layout (4 x 16GB ?) etc ...) Thanks, Nicolas
Hi Nicolas, Sorry, I forgot to write: The booting was succesful with 128MB GPU memory. HP ZBook Fury 16 G9 Mobile Workstation PC/89C6, BIOS U96 Ver. 01.10.00 01/18/2024 CPU: 12th Gen Intel(R) Core(TM) i7-12850HX RAM: 4 x 16GB Base Board Information Manufacturer: HP Product Name: 89C6 Version: KBC Version 15.68.00 Video: Intel Corporation Alder Lake-HX GT1 [UHD Graphics 770] (rev 0c) NVIDIA Corporation GA107GLM [RTX A2000 8GB Laptop GPU] (rev a1) lsmem RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x000000007fffffff 2G online yes 0 0x0000000100000000-0x00000010ffffffff 64G online yes 2-33 Memory block size: 2G Total online memory: 66G Total offline memory: 0B I don't know what is the +2G :) With installed Fedora 39 the memory map in boot log: (The installed version boots with 512MB GPU RAM :) ) kernel: BIOS-provided physical RAM map: kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000258c0fff] usable kernel: BIOS-e820: [mem 0x00000000258c1000-0x00000000258c1fff] reserved kernel: BIOS-e820: [mem 0x00000000258c2000-0x000000002f8d8fff] usable kernel: BIOS-e820: [mem 0x000000002f8d9000-0x000000003592ffff] reserved kernel: BIOS-e820: [mem 0x0000000035930000-0x0000000035b2ffff] ACPI NVS kernel: BIOS-e820: [mem 0x0000000035b30000-0x0000000035bfefff] ACPI data kernel: BIOS-e820: [mem 0x0000000035bff000-0x0000000035bfffff] usable kernel: BIOS-e820: [mem 0x0000000035c00000-0x000000003bffffff] reserved kernel: BIOS-e820: [mem 0x000000003d400000-0x000000003d5fffff] reserved kernel: BIOS-e820: [mem 0x0000000040000000-0x00000000547fffff] reserved kernel: BIOS-e820: [mem 0x00000000c0000000-0x00000000cfffffff] reserved kernel: BIOS-e820: [mem 0x00000000fed20000-0x00000000fed7ffff] reserved kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved kernel: BIOS-e820: [mem 0x0000000100000000-0x00000010ab7fffff] usable Kind regards, Krisztian
Hi Krisztian, Thanks for chiming in. Hi Nicolas, Following Krisztian's post, I thought to remove my AMD Radeon RX 7900XTX GPU from the equation. So I unplugged this GPU so that my PC only uses the iGPU built into the Intel Core i7-14700K CPU. I tried to boot a Fedora Live 40 USB stick since its GRUB crashes with an out of memory error like the Fedora Live 39 USB stick. - With the default 64MB RAM allocated to the iGPU, GRUB still crashes. - With only 32MB RAM allocated to the iGPU, GRUB still crashes. So unfortunately using the iGPU and minimizing the RAM allocated to the iGPU does not prevent GRUB from crashing with an out of memory error. Below the memory map produced my the Ubuntu 23.10 kernel if this can be helpful. I temporarily use Ubuntu 23.10 since Fedora 39/40 GRUB crashes on my PC. [ 0.000000] Linux version 6.5.0-28-generic (buildd@lcy02-amd64-001) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 (Ubuntu 6.5.0-28.29-generic 6.5.13) [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-28-generic root=UUID=75a459ef-5d22-4528-9bc6-53a19b59bbd8 ro quiet splash [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai [ 0.000000] x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009efff] reserved [ 0.000000] BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fd32fff] usable [ 0.000000] BIOS-e820: [mem 0x000000001fd33000-0x000000001fd33fff] reserved [ 0.000000] BIOS-e820: [mem 0x000000001fd34000-0x0000000021d9bfff] usable [ 0.000000] BIOS-e820: [mem 0x0000000021d9c000-0x0000000021d9cfff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000021d9d000-0x000000002e45efff] usable [ 0.000000] BIOS-e820: [mem 0x000000002e45f000-0x000000003215efff] reserved [ 0.000000] BIOS-e820: [mem 0x000000003215f000-0x00000000323e9fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000323ea000-0x000000003261efff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000003261f000-0x0000000033efefff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000033eff000-0x0000000033efffff] usable [ 0.000000] BIOS-e820: [mem 0x0000000033f00000-0x0000000039ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x000000003a400000-0x000000003a7fffff] reserved [ 0.000000] BIOS-e820: [mem 0x000000003b000000-0x00000000407fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000c0000000-0x00000000cfffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed20000-0x00000000fed7ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000020bf7fffff] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] e820: update [mem 0x138bf018-0x138da257] usable ==> usable [ 0.000000] e820: update [mem 0x138bf018-0x138da257] usable ==> usable [ 0.000000] e820: update [mem 0x138ac018-0x138be057] usable ==> usable [ 0.000000] e820: update [mem 0x138ac018-0x138be057] usable ==> usable [ 0.000000] e820: update [mem 0x13893018-0x138abc57] usable ==> usable [ 0.000000] e820: update [mem 0x13893018-0x138abc57] usable ==> usable [ 0.000000] extended physical RAM map: [ 0.000000] reserve setup_data: [mem 0x0000000000000000-0x000000000009dfff] usable [ 0.000000] reserve setup_data: [mem 0x000000000009e000-0x000000000009efff] reserved [ 0.000000] reserve setup_data: [mem 0x000000000009f000-0x000000000009ffff] usable [ 0.000000] reserve setup_data: [mem 0x00000000000a0000-0x00000000000fffff] reserved [ 0.000000] reserve setup_data: [mem 0x0000000000100000-0x0000000013893017] usable [ 0.000000] reserve setup_data: [mem 0x0000000013893018-0x00000000138abc57] usable [ 0.000000] reserve setup_data: [mem 0x00000000138abc58-0x00000000138ac017] usable [ 0.000000] reserve setup_data: [mem 0x00000000138ac018-0x00000000138be057] usable [ 0.000000] reserve setup_data: [mem 0x00000000138be058-0x00000000138bf017] usable [ 0.000000] reserve setup_data: [mem 0x00000000138bf018-0x00000000138da257] usable [ 0.000000] reserve setup_data: [mem 0x00000000138da258-0x000000001fd32fff] usable [ 0.000000] reserve setup_data: [mem 0x000000001fd33000-0x000000001fd33fff] reserved [ 0.000000] reserve setup_data: [mem 0x000000001fd34000-0x0000000021d9bfff] usable [ 0.000000] reserve setup_data: [mem 0x0000000021d9c000-0x0000000021d9cfff] reserved [ 0.000000] reserve setup_data: [mem 0x0000000021d9d000-0x000000002e45efff] usable [ 0.000000] reserve setup_data: [mem 0x000000002e45f000-0x000000003215efff] reserved [ 0.000000] reserve setup_data: [mem 0x000000003215f000-0x00000000323e9fff] ACPI data [ 0.000000] reserve setup_data: [mem 0x00000000323ea000-0x000000003261efff] ACPI NVS [ 0.000000] reserve setup_data: [mem 0x000000003261f000-0x0000000033efefff] reserved [ 0.000000] reserve setup_data: [mem 0x0000000033eff000-0x0000000033efffff] usable [ 0.000000] reserve setup_data: [mem 0x0000000033f00000-0x0000000039ffffff] reserved [ 0.000000] reserve setup_data: [mem 0x000000003a400000-0x000000003a7fffff] reserved [ 0.000000] reserve setup_data: [mem 0x000000003b000000-0x00000000407fffff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000c0000000-0x00000000cfffffff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000fe000000-0x00000000fe010fff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000fed00000-0x00000000fed00fff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000fed20000-0x00000000fed7ffff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] reserve setup_data: [mem 0x0000000100000000-0x00000020bf7fffff] usable [ 0.000000] efi: EFI v2.8 by American Megatrends [ 0.000000] efi: ACPI=0x323e9000 ACPI 2.0=0x323e9014 TPMFinalLog=0x3250b000 SMBIOS=0x3394b000 SMBIOS 3.0=0x3394a000 MEMATTR=0x29bcb298 ESRT=0x29dbdc18 MOKvar=0x339da000 INITRD=0x1c374318 RNG=0x3233fc18 TPMEventLog=0x19a0c018 [ 0.000000] random: crng init done [ 0.000000] efi: Remove mem88: MMIO range=[0xc0000000-0xcfffffff] (256MB) from e820 map [ 0.000000] e820: remove [mem 0xc0000000-0xcfffffff] reserved [ 0.000000] efi: Not removing mem89: MMIO range=[0xfe000000-0xfe010fff] (68KB) from e820 map [ 0.000000] efi: Not removing mem90: MMIO range=[0xfec00000-0xfec00fff] (4KB) from e820 map [ 0.000000] efi: Not removing mem91: MMIO range=[0xfed00000-0xfed00fff] (4KB) from e820 map [ 0.000000] efi: Not removing mem93: MMIO range=[0xfee00000-0xfee00fff] (4KB) from e820 map [ 0.000000] efi: Remove mem94: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map [ 0.000000] e820: remove [mem 0xff000000-0xffffffff] reserved [ 0.000000] secureboot: Secure boot disabled Best regards, Michael
Hi Michael & team, I jumped into this issue; unfortunately I am not able to reproduce the issue so I am asking you the following: once you are on the grub menu, type 'c' to jump to the command line and then type the 'lsefimmap' command, the latter shows the memory mappings and with it we may have a better idea of the issue. Perhaps it would be a good idea to run this command on your fedora / ubuntu and compare both outputs but in theory it should be the same.
Created attachment 2032860 [details] EFI memory map reported by Fedora 40 GRUB Output of the lsefimmap command on Fedora 40 GRUB
Created attachment 2032861 [details] EFI memory map reported by Ubuntu 23.10 GRUB Output of the lsefimmap command on Ubuntu 23.10 GRUB
Hi Leo, Thanks for jumping into this issue. I understand there is no way to write to a filesystem from the GRUB CLI. So I have taken screenshots of the output of the lsefimmap GRUB command on both Ubuntu 23.10 (GRUB working on my system) and Fedora 40 (GRUB crashing on my system). I have put the screenshots in PDF files and attached each PDF file to this bug report. Best regards, Michael
Hi Leo, Sorry for the delay... I created lsefimmap outputs: - Fedora 40 Live, 256MB Video RAM, booting, result: MP4 because no paging with lsefimmap (about 90s time to display all lines...) - Fedora 40 Live, 512MB Video RAM, NOT booting, result: MP4 because no paging with lsefimmap - Fedora 39 installed, 512MB Video RAM, booting, result: 8 screen JPGs, there was paging with lsefimmap (different GRUB?) How can I share the result? (1,1 GB) I can upload here if it is OK. Or I can send a Google Photos link. Kind regards, Krisztian Steber
(In reply to Michael Tadault from comment #16) > Hi Leo, > > Thanks for jumping into this issue. > > I understand there is no way to write to a filesystem from the GRUB CLI. So > I have taken screenshots of the output of the lsefimmap GRUB command on both > Ubuntu 23.10 (GRUB working on my system) and Fedora 40 (GRUB crashing on my > system). I have put the screenshots in PDF files and attached each PDF file > to this bug report. Hi Michael, Thanks for uploading this content (and sorry for the delay on this ticket), I will take a look asap. In the other hand, we (the rhel bootloader team) are about to update rawhide based on grub2 2.12 version so of course I this ticket would be an ideal candidate to test the new rpms. I will let you know when you can start testing. > > Best regards, > > Michael
(In reply to Leo Sandoval from comment #18) > (In reply to Michael Tadault from comment #16) > Hi Michael, > > Thanks for uploading this content (and sorry for the delay on this ticket), > I will take a look asap. > > In the other hand, we (the rhel bootloader team) are about to update rawhide > based on grub2 2.12 version so of course I this ticket would be an ideal > candidate to test the new rpms. I will let you know when you can start > testing. Hi Leo, Will also be willing to test ! Let me know when it's available in rawhide.
Retried it today, and now it seems to work with the latest ISO of Fedora 40.
Hi fedoraproject.i2yi8, thanks you for letting us know! Michael or Krisztian, could either of you please confirm whether the latest iso is working for you as well?
Hi, I tried again with Fedora-Workstation-Live-x86_64-40-1.14.iso just downloaded from https://fedoraproject.org/workstation/download Grub is still crashing with 'error: ../../grub-core/kern/mm.c:552:out of memory.' All the files in this ISO image are dated from mid-April 2024. So doesn't look very new. Are there any newer Fedora 40 iso images to download? Best regards, Michael Tadault
Just tried with Fedora-Everything-netinst-x86_64-Rawhide-20240729.n.0.iso from latest nightly build "Fedora Rawhide - Everything boot" available here: https://openqa.fedoraproject.org/nightlies.html Grub 2.06 is still crashing with 'error: ../../grub-core/kern/mm.c:552:out of memory.' :-(
Hi, I can confirm "Fedora-Workstation-Live-x86_64-40-1.14.iso" is crashing. Best regards, Krisztian Steber
I am working with a partner (SAP) who is also seeing this exact issue (error: ../../grub-core/kern/mm.c:552:out of memory) when provisioning a ppc64le machine with RHEL-9.5 and RHEL-10.0. RHEL-9.4 and below work. TFTP BOOT --------------------------------------------------- Server IP.....................10.98.87.247 Client IP.....................10.98.84.190 Gateway IP....................10.98.84.1 Subnet Mask...................255.255.252.0 ( 1 ) Filename.................bootloader/lsh40124.wdf.sap.corp/image TFTP Retries..................5 Block Size....................512 FINAL PACKET COUNT = 4046 FINAL FILE SIZE = 2071204 BYTES Elapsed time since release of system processors: 34719 mins 58 secs Welcome to GRUB! error: ../../grub-core/kern/mm.c:552:out of memory. OF stdout device is: /vdevice/vty@30000000 Preparing to boot Linux version 5.14.0-478.el9.ppc64le (mockbuild.eng.rdu2.redhat.com) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-48.el9) #1 SMP Tue Jul 9 14:22:08 EDT 2024 Detected machine type: 0000000000000101 command line: BOOT_IMAGE=/images/lsh40124.wdf.sap.corp/kernel grub2_postfix= inst.ks=http://ix4000.wdf.sap.corp/bkr/kickstart/124 inst.leavebootorder netboot_method=grub2 Max number of cores passed to firmware: 256 (NR_CPUS = 2048) Calling ibm,client-architecture-support... done memory layout at init: memory_limit : 0000000000000000 (16 MB aligned) alloc_bottom : 0000000010690000 alloc_top : 0000000020000000 alloc_top_hi : 0000000020000000 rmo_top : 0000000020000000 ram_top : 0000000020000000 instantiating rtas at 0x000000001ec10000... done prom_hold_cpus: skipped copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x00000000107a0000 -> 0x00000000107a1a2b Device tree struct 0x00000000107b0000 -> 0x00000000107d0000 Quiescing Open Firmware ... Booting Linux via __start() @ 0x000000000d6f0000 ... [ 0.000000] radix-mmu: Page sizes from device-tree: [ 0.000000] radix-mmu: Page size shift = 12 AP=0x0 [ 0.000000] radix-mmu: Page size shift = 16 AP=0x5 [ 0.000000] radix-mmu: Page size shift = 21 AP=0x1 [ 0.000000] radix-mmu: Page size shift = 30 AP=0x2 [ 0.000000] Activating Kernel Userspace Access Prevention [ 0.000000] Activating Kernel Userspace Execution Prevention [ 0.000000] radix-mmu: Mapped 0x0000000000000000-0x0000000002800000 with 2.00 MiB pages (exec) [ 0.000000] radix-mmu: Mapped 0x0000000002800000-0x0000007d00000000 with 2.00 MiB pages [ 0.000000] lpar: Using radix MMU under hypervisor [ 0.000000] Linux version 5.14.0-478.el9.ppc64le (mockbuild.eng.rdu2.redhat.com) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-48.el9) #1 SMP Tue Jul 9 14:22:08 EDT 2024 [ 0.000000] The list of certified hardware and cloud instances for Red Hat Enterprise Linux 9 can be viewed at the Red Hat Ecosystem Catalog, https://catalog.redhat.com. [ 0.000000] Secure boot mode disabled [ 0.000000] Using pSeries machine description [ 0.000000] printk: legacy bootconsole [udbg0] enabled [ 0.000000] Partition configured for 192 cpus. [ 0.000000] CPU maps initialized for 8 threads per core [ 0.000000] numa: Partition configured for 32 NUMA nodes. [ 0.000000] ----------------------------------------------------- [ 0.000000] phys_mem_size = 0x7d00000000 [ 0.000000] dcache_bsize = 0x80 [ 0.000000] icache_bsize = 0x80 [ 0.000000] cpu_features = 0x001c00eb8f5f9187 [ 0.000000] possible = 0x001ffbfbcf5fb187 [ 0.000000] always = 0x0000000380008181 [ 0.000000] cpu_user_features = 0xdc0065c2 0xaef60000 [ 0.000000] mmu_features = 0xbc007641 [ 0.000000] firmware_features = 0x00000dbfc45bfc57 [ 0.000000] vmalloc start = 0xc008000000000000 [ 0.000000] IO start = 0xc00a000000000000 [ 0.000000] vmemmap start = 0xc00c000000000000 [ 0.000000] ----------------------------------------------------- [ 0.000000] numa: NODE_DATA [mem 0x1f3f962500-0x1f3f96a27f] [ 0.000000] numa: NODE_DATA [mem 0x3e7f9c8280-0x3e7f9cffff] [ 0.000000] numa: NODE_DATA [mem 0x5dbf9c8280-0x5dbf9cffff] [ 0.000000] numa: NODE_DATA [mem 0x7cfca10280-0x7cfca17fff] [ 0.000000] rfi-flush: fallback displacement flush available [ 0.000000] count-cache-flush: hardware flush enabled. [ 0.000000] link-stack-flush: software flush enabled. [ 0.000000] stf-barrier: eieio barrier available [ 0.000000] lpar: H_BLOCK_REMOVE supports base psize:0 psize:0 block size:8 [ 0.000000] PPC64 nvram contains 15360 bytes [ 0.000000] barrier-nospec: using ORI speculation barrier [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000007cffffffff] [ 0.000000] Device empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000001f3fffffff] [ 0.000000] node 1: [mem 0x0000001f40000000-0x0000003e7fffffff] [ 0.000000] node 2: [mem 0x0000003e80000000-0x0000005dbfffffff] [ 0.000000] node 3: [mem 0x0000005dc0000000-0x0000007cffffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000001f3fffffff] [ 0.000000] Initmem setup node 1 [mem 0x0000001f40000000-0x0000003e7fffffff] [ 0.000000] Initmem setup node 2 [mem 0x0000003e80000000-0x0000005dbfffffff] [ 0.000000] Initmem setup node 3 [mem 0x0000005dc0000000-0x0000007cffffffff] [ 0.000000] Initializing node 4 as memoryless [ 0.000000] Initmem setup node 4 as memoryless [ 0.000000] Initializing node 5 as memoryless [ 0.000000] Initmem setup node 5 as memoryless [ 0.000000] Initializing node 6 as memoryless [ 0.000000] Initmem setup node 6 as memoryless [ 0.000000] Initializing node 7 as memoryless [ 0.000000] Initmem setup node 7 as memoryless [ 0.000000] Initializing node 8 as memoryless [ 0.000000] Initmem setup node 8 as memoryless [ 0.000000] Initializing node 9 as memoryless [ 0.000000] Initmem setup node 9 as memoryless [ 0.000000] Initializing node 10 as memoryless [ 0.000000] Initmem setup node 10 as memoryless [ 0.000000] Initializing node 11 as memoryless [ 0.000000] Initmem setup node 11 as memoryless [ 0.000000] Initializing node 12 as memoryless [ 0.000000] Initmem setup node 12 as memoryless [ 0.000000] Initializing node 13 as memoryless [ 0.000000] Initmem setup node 13 as memoryless [ 0.000000] Initializing node 14 as memoryless [ 0.000000] Initmem setup node 14 as memoryless [ 0.000000] Initializing node 15 as memoryless [ 0.000000] Initmem setup node 15 as memoryless [ 0.000000] Initializing node 16 as memoryless [ 0.000000] Initmem setup node 16 as memoryless [ 0.000000] Initializing node 17 as memoryless [ 0.000000] Initmem setup node 17 as memoryless [ 0.000000] Initializing node 18 as memoryless [ 0.000000] Initmem setup node 18 as memoryless [ 0.000000] Initializing node 19 as memoryless [ 0.000000] Initmem setup node 19 as memoryless [ 0.000000] Initializing node 20 as memoryless [ 0.000000] Initmem setup node 20 as memoryless [ 0.000000] Initializing node 21 as memoryless [ 0.000000] Initmem setup node 21 as memoryless [ 0.000000] Initializing node 22 as memoryless [ 0.000000] Initmem setup node 22 as memoryless [ 0.000000] Initializing node 23 as memoryless [ 0.000000] Initmem setup node 23 as memoryless [ 0.000000] Initializing node 24 as memoryless [ 0.000000] Initmem setup node 24 as memoryless [ 0.000000] Initializing node 25 as memoryless [ 0.000000] Initmem setup node 25 as memoryless [ 0.000000] Initializing node 26 as memoryless [ 0.000000] Initmem setup node 26 as memoryless [ 0.000000] Initializing node 27 as memoryless [ 0.000000] Initmem setup node 27 as memoryless [ 0.000000] Initializing node 28 as memoryless [ 0.000000] Initmem setup node 28 as memoryless [ 0.000000] Initializing node 29 as memoryless [ 0.000000] Initmem setup node 29 as memoryless [ 0.000000] Initializing node 30 as memoryless [ 0.000000] Initmem setup node 30 as memoryless [ 0.000000] Initializing node 31 as memoryless [ 0.000000] Initmem setup node 31 as memoryless [ 0.000000] percpu: Embedded 10 pages/cpu s609832 r0 d45528 u655360 [ 0.000000] Kernel command line: BOOT_IMAGE=/images/lsh40124.wdf.sap.corp/kernel grub2_postfix= inst.ks=http://ix4000.wdf.sap.corp/bkr/kickstart/124 inst.leavebootorder netboot_method=grub2 [ 0.000000] Unknown kernel command line parameters "BOOT_IMAGE=/images/lsh40124.wdf.sap.corp/kernel grub2_postfix= netboot_method=grub2", will be passed to user space. [ 0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes [ 0.000000] printk: log_buf_len total cpu_extra contributions: 782336 bytes [ 0.000000] printk: log_buf_len min size: 1048576 bytes [ 0.000000] printk: log_buf_len: 2097152 bytes [ 0.000000] printk: early log buf free: 1038688(99%) [ 0.000000] Fallback order for Node 0: 0 1 2 3 [ 0.000000] Fallback order for Node 1: 1 0 3 2 [ 0.000000] Fallback order for Node 2: 2 3 0 1 [ 0.000000] Fallback order for Node 3: 3 2 1 0 [ 0.000000] Fallback order for Node 4: 4 0 1 2 3 [ 0.000000] Fallback order for Node 5: 5 0 1 3 2 [ 0.000000] Fallback order for Node 6: 6 0 1 2 3 [ 0.000000] Fallback order for Node 7: 7 0 1 3 2 [ 0.000000] Fallback order for Node 8: 8 0 1 2 3 [ 0.000000] Fallback order for Node 9: 9 0 1 3 2 [ 0.000000] Fallback order for Node 10: 10 0 1 2 3 [ 0.000000] Fallback order for Node 11: 11 0 1 3 2 [ 0.000000] Fallback order for Node 12: 12 0 1 2 3 [ 0.000000] Fallback order for Node 13: 13 0 1 3 2 [ 0.000000] Fallback order for Node 14: 14 0 1 2 3 [ 0.000000] Fallback order for Node 15: 15 0 1 3 2 [ 0.000000] Fallback order for Node 16: 16 0 1 2 3 [ 0.000000] Fallback order for Node 17: 17 0 1 3 2 [ 0.000000] Fallback order for Node 18: 18 0 1 2 3 [ 0.000000] Fallback order for Node 19: 19 0 1 3 2 [ 0.000000] Fallback order for Node 20: 20 0 1 2 3 [ 0.000000] Fallback order for Node 21: 21 0 1 3 2 [ 0.000000] Fallback order for Node 22: 22 0 1 2 3 [ 0.000000] Fallback order for Node 23: 23 0 1 3 2 [ 0.000000] Fallback order for Node 24: 24 0 1 2 3 [ 0.000000] Fallback order for Node 25: 25 0 1 3 2 [ 0.000000] Fallback order for Node 26: 26 0 1 2 3 [ 0.000000] Fallback order for Node 27: 27 0 1 3 2 [ 0.000000] Fallback order for Node 28: 28 0 1 2 3 [ 0.000000] Fallback order for Node 29: 29 0 1 3 2 [ 0.000000] Fallback order for Node 30: 30 0 1 2 3 [ 0.000000] Fallback order for Node 31: 31 0 1 3 2 [ 0.000000] Built 4 zonelists, mobility grouping on. Total pages: 8184000 [ 0.000000] Policy zone: Normal [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 523489088K/524288000K available (16512K kernel code, 5888K rwdata, 10240K rodata, 6912K init, 3124K bss, 798912K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=192, Nodes=32 [ 0.000000] ftrace: allocating 41477 entries in 16 pages [ 0.000000] ftrace: allocated 16 pages with 1 groups [ 0.000000] trace event string verifier disabled [ 0.000000] rcu: Hierarchical RCU implementation. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=192. [ 0.000000] Rude variant of Tasks RCU enabled. [ 0.000000] Tracing variant of Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=192 [ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 [ 0.000000] xive: Using IRQ range [400000-4000bf] [ 0.000000] xive: Interrupt handling initialized with spapr backend [ 0.000000] xive: Using priority 7 for all interrupts [ 0.000000] xive: Using 64kB queues [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes to big. [ 0.000000] time_init: 56 bit decrementer (max: 7fffffffffffff) [ 0.000019] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns [ 0.000046] clocksource: timebase mult[1f40000] shift[24] registered [ 0.000419] Console: colour dummy device 80x25 [ 0.000436] printk: legacy console [hvc0] enabled [ 0.000436] printk: legacy console [hvc0] enabled [ 0.000450] printk: legacy bootconsole [udbg0] disabled [ 0.000450] printk: legacy bootconsole [udbg0] disabled [ 0.000662] mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl [ 0.000674] pid_max: default: 196608 minimum: 1536 [ 0.001066] LSM: initializing lsm=lockdown,capability,yama,integrity,selinux,bpf [ 0.001156] Yama: becoming mindful. [ 0.001195] SELinux: Initializing. [ 0.001485] LSM support for eBPF active [ 0.013209] Dentry cache hash table entries: 16777216 (order: 11, 134217728 bytes, vmalloc hugepage) [ 0.019120] Inode-cache hash table entries: 8388608 (order: 10, 67108864 bytes, vmalloc hugepage) [ 0.019455] Mount-cache hash table entries: 262144 (order: 5, 2097152 bytes, vmalloc) [ 0.019666] Mountpoint-cache hash table entries: 262144 (order: 5, 2097152 bytes, vmalloc) [ 0.024134] RCU Tasks Rude: Setting shift to 8 and lim to 1 rcu_task_cb_adjust=1. [ 0.024178] RCU Tasks Trace: Setting shift to 8 and lim to 1 rcu_task_cb_adjust=1. [ 0.024226] POWER10 performance monitor hardware support registered [ 0.024276] rcu: Hierarchical SRCU implementation. [ 0.024280] rcu: Max phase no-delay instances is 1000. [ 0.026307] smp: Bringing up secondary CPUs ... [ 0.092100] smp: Brought up 4 nodes, 192 CPUs [ 0.092124] numa: Node 0 CPUs: 0-47 [ 0.092129] numa: Node 1 CPUs: 48-95 [ 0.092133] numa: Node 2 CPUs: 96-143 [ 0.092137] numa: Node 3 CPUs: 144-191 [ 0.092141] Big cores detected but using small core scheduling [ 0.124269] devtmpfs: initialized [ 0.142903] PCI host bridge /pci@800000020000182 ranges: [ 0.142935] MEM 0x0000040008000000..0x000004000fffffff -> 0x0000000080000000 [ 0.142939] MEM 0x0000040800000000..0x0000040fffffffff -> 0x0006021000000000 [ 0.142986] PCI host bridge /pci@800000020000040 ranges: [ 0.142993] MEM 0x0000040100000000..0x000004017effffff -> 0x0000000080000000 [ 0.142997] MEM 0x0000048000000000..0x000004bfffffffff -> 0x0006c00000000000 [ 0.143014] PCI host bridge /pci@800000020000030 ranges: [ 0.143018] MEM 0x0000040080000000..0x00000400feffffff -> 0x0000000080000000 [ 0.143022] MEM 0x0000044000000000..0x0000047fffffffff -> 0x0006800000000000 [ 0.143119] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.143136] futex hash table entries: 65536 (order: 7, 8388608 bytes, vmalloc hugepage) [ 0.152322] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 0.152638] audit: initializing netlink subsys (disabled) [ 0.152754] audit: type=2000 audit(1720784424.150:1): state=initialized audit_enabled=0 res=1 [ 0.152903] thermal_sys: Registered thermal governor 'fair_share' [ 0.152905] thermal_sys: Registered thermal governor 'step_wise' [ 0.153023] cpuidle: using governor menu [ 0.153402] pstore: Registered nvram as persistent store backend [ 0.153889] EEH: pSeries platform initialized [ 0.154095] plpks: POWER LPAR Platform KeyStore is not supported or enabled [ 0.181109] pseries-rng: Registering arch random hook. [ 0.182568] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible. [ 0.183198] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages [ 0.183209] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page [ 0.183214] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages [ 0.183217] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page [ 0.187176] cryptd: max_cpu_qlen set to 1000 [ 0.187983] iommu: Default domain type: Translated [ 0.187988] iommu: DMA domain TLB invalidation policy: strict mode [ 0.188161] SCSI subsystem initialized [ 0.188198] usbcore: registered new interface driver usbfs [ 0.188206] usbcore: registered new interface driver hub [ 0.188252] usbcore: registered new device driver usb [ 0.188276] pps_core: LinuxPPS API ver. 1 registered [ 0.188279] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti> [ 0.188284] PTP clock support registered [ 0.188525] EDAC MC: Ver: 3.0.0 [ 0.188869] NetLabel: Initializing [ 0.188874] NetLabel: domain hash size = 128 [ 0.188877] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO [ 0.188893] NetLabel: unlabeled traffic allowed by default [ 0.188895] PCI: Probing PCI hardware [ 0.188954] PCI host bridge to bus 0182:70 [ 0.188959] pci_bus 0182:70: root bus resource [mem 0x40008000000-0x4000fffffff] (bus address [0x80000000-0x87ffffff]) [ 0.188965] pci_bus 0182:70: root bus resource [mem 0x40800000000-0x40fffffffff 64bit] (bus address [0x6021000000000-0x60217ffffffff]) [ 0.188970] pci_bus 0182:70: root bus resource [bus 70-ff] [ 0.190097] pci 0182:70:00.0: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.202021] IOMMU table initialized, virtual merging enabled [ 0.202098] PCI host bridge to bus 0040:01 [ 0.202103] pci_bus 0040:01: root bus resource [mem 0x40100000000-0x4017effffff] (bus address [0x80000000-0xfeffffff]) [ 0.202111] pci_bus 0040:01: root bus resource [mem 0x48000000000-0x4bfffffffff 64bit] (bus address [0x6c00000000000-0x6c03fffffffff]) [ 0.202117] pci_bus 0040:01: root bus resource [bus 01-ff] [ 0.203062] pci 0040:01:00.0: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.205278] pci 0040:01:00.0: PME# supported from D3cold [ 0.210579] pci 0040:01:00.0: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.212588] pci 0040:01:00.1: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.214641] pci 0040:01:00.1: PME# supported from D3cold [ 0.219546] pci 0040:01:00.1: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.225953] PCI host bridge to bus 0030:01 [ 0.225966] pci_bus 0030:01: root bus resource [mem 0x40080000000-0x400feffffff] (bus address [0x80000000-0xfeffffff]) [ 0.225971] pci_bus 0030:01: root bus resource [mem 0x44000000000-0x47fffffffff 64bit] (bus address [0x6800000000000-0x6803fffffffff]) [ 0.225976] pci_bus 0030:01: root bus resource [bus 01-ff] [ 0.226953] pci 0030:01:00.0: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.236650] pci 0030:01:00.0: No hypervisor support for SR-IOV on this device, IOV BARs disabled. [ 0.244263] pci 0182:70:00.0: Adding to iommu group 0 [ 0.244327] pci 0182:70:00.0: of_irq_parse_pci: no interrupt-map found, INTx interrupts not available [ 0.244333] PCI: OF: of_irq_parse_pci: possibly some PCI slots don't have level triggered interrupts capability [ 0.246032] pci 0040:01:00.0: Adding to iommu group 1 [ 0.259963] pci 0040:01:00.1: Adding to iommu group 1 [ 0.279986] pci 0030:01:00.0: Adding to iommu group 2 [ 0.299713] EEH: Capable adapter found: recovery enabled. [ 0.299800] vgaarb: loaded [ 0.300566] clocksource: Switched to clocksource timebase [ 0.301255] VFS: Disk quotas dquot_6.6.0 [ 0.301325] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) [ 0.303159] NET: Registered PF_INET protocol family [ 0.303347] IP idents hash table entries: 262144 (order: 5, 2097152 bytes, vmalloc) [ 0.306762] tcp_listen_portaddr_hash hash table entries: 65536 (order: 4, 1048576 bytes, vmalloc) [ 0.306901] Table-perturb hash table entries: 65536 (order: 2, 262144 bytes, vmalloc) [ 0.306950] TCP established hash table entries: 524288 (order: 6, 4194304 bytes, vmalloc) [ 0.307696] TCP bind hash table entries: 65536 (order: 4, 1048576 bytes, vmalloc) [ 0.307820] TCP: Hash tables configured (established 524288 bind 65536) [ 0.308522] MPTCP token hash table entries: 65536 (order: 4, 1572864 bytes, vmalloc) [ 0.308738] UDP hash table entries: 65536 (order: 5, 2097152 bytes, vmalloc) [ 0.309042] UDP-Lite hash table entries: 65536 (order: 5, 2097152 bytes, vmalloc) [ 0.309719] NET: Registered PF_UNIX/PF_LOCAL protocol family [ 0.309732] NET: Registered PF_XDP protocol family [ 0.309975] pci 0040:01:00.0: enabling device (0140 -> 0142) [ 0.310347] pci 0040:01:00.1: enabling device (0140 -> 0142) [ 0.310692] PCI: CLS 128 bytes, default 128 [ 0.311647] vio_register_device_node: node lid missing 'reg' [ 0.311760] vas: GZIP feature is available [ 0.312601] hv-24x7: read 548 catalog entries, created 387 event attrs (0 failures), 387 descs [ 0.321921] Initialise system trusted keyrings [ 0.321957] Key type blacklist registered [ 0.322130] workingset: timestamp_bits=38 max_order=23 bucket_order=0 [ 0.322155] zbud: loaded [ 0.322813] integrity: Platform Keyring initialized [ 0.322822] integrity: Machine keyring initialized [ 0.332580] NET: Registered PF_ALG protocol family [ 0.332588] xor: measuring software checksum speed [ 0.332981] 8regs : 25549 MB/sec [ 0.333429] 8regs_prefetch : 22179 MB/sec [ 0.333819] 32regs : 25425 MB/sec [ 0.334271] 32regs_prefetch : 21926 MB/sec [ 0.334538] altivec : 39171 MB/sec [ 0.334541] xor: using function: altivec (39171 MB/sec) [ 0.334546] Key type asymmetric registered [ 0.334548] Asymmetric key parser 'x509' registered [ 0.334551] Running certificate verification selftests [ 0.335800] Loaded X.509 cert 'Certificate verification self-testing key: f58703bb33ce1b73ee02eccdee5b8817518fe3db' [ 0.336386] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246) [ 0.336497] io scheduler mq-deadline registered [ 0.336503] io scheduler kyber registered [ 0.336551] io scheduler bfq registered [ 0.340340] atomic64_test: passed [ 0.340632] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 0.340637] PowerPC PowerNV PCI Hotplug Driver version: 0.1 [ 0.340950] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 0.341990] rdac: device handler registered [ 0.342161] hp_sw: device handler registered [ 0.342166] emc: device handler registered [ 0.342257] alua: device handler registered [ 0.342468] usbcore: registered new interface driver usbserial_generic [ 0.342476] usbserial: USB Serial support registered for generic [ 0.342503] mousedev: PS/2 mouse device common for all mice [ 0.342584] rtc-generic rtc-generic: registered as rtc0 [ 0.342667] rtc-generic rtc-generic: setting system clock to 2024-07-12T11:40:24 UTC (1720784424) [ 0.342741] xcede: xcede_record_size = 10 [ 0.342745] xcede: Record 0 : hint = 1, latency = 0x1800 tb ticks, Wake-on-irq = 1 [ 0.342749] xcede: Record 1 : hint = 2, latency = 0x3c00 tb ticks, Wake-on-irq = 0 [ 0.342752] cpuidle: Skipping the 2 Extended CEDE idle states [ 0.342755] cpuidle: Fixed up CEDE exit latency to 12 us [ 0.344334] nx_compress_pseries ibm,compression-v1: nx842_OF_upd: device disabled [ 0.344405] hid: raw HID events driver (C) Jiri Kosina [ 0.344431] usbcore: registered new interface driver usbhid [ 0.344433] usbhid: USB HID core driver [ 0.344493] drop_monitor: Initializing network drop monitor service [ 0.352437] Initializing XFRM netlink socket [ 0.352691] NET: Registered PF_INET6 protocol family [ 0.354945] Segment Routing with IPv6 [ 0.354971] NET: Registered PF_PACKET protocol family [ 0.355125] mpls_gso: MPLS GSO support [ 0.355161] secvar-sysfs: Failed to retrieve secvar operations [ 0.355336] registered taskstats version 1 [ 0.361084] Loading compiled-in X.509 certificates [ 0.361687] Loaded X.509 cert 'Red Hat Enterprise Linux kernel signing key: 8b5f0880bddf284afc684a9abe53f492d6c8aadf' [ 0.361994] Loaded X.509 cert 'Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87362bc7229d9f465321773dfd1f77a80' [ 0.362294] Loaded X.509 cert 'Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b72e3852e2014c3a676fc8' [ 0.362453] Loaded X.509 cert 'RH-IMA-CA: Red Hat IMA CA: fb31825dd0e073685b264e3038963673f753959a' [ 0.362470] Loaded X.509 cert 'Nvidia GPU OOT signing 001: 55e1cef88193e60419f0b0ec379c49f77545acf0' [ 0.362628] Loaded X.509 cert 'Red Hat Secure Boot CA 7: c442130fde4c50fa1686bbf0692e3ebc64f5db3e' [ 0.364238] page_owner is disabled [ 0.364555] pstore: Using crash dump compression: deflate [ 0.364570] Key type big_key registered [ 0.364950] Key type encrypted registered [ 0.365028] Secure boot mode disabled [ 0.365034] ima: No TPM chip found, activating TPM-bypass! [ 0.365038] Loading compiled-in module X.509 certificates [ 0.365339] Loaded X.509 cert 'Red Hat Enterprise Linux kernel signing key: 8b5f0880bddf284afc684a9abe53f492d6c8aadf' [ 0.365345] ima: Allocated hash algorithm: sha256 [ 0.365383] Secure boot mode disabled [ 0.365415] Trusted boot mode disabled [ 0.365418] ima: No architecture policies found [ 0.365433] evm: Initialising EVM extended attributes: [ 0.365435] evm: security.selinux [ 0.365438] evm: security.SMACK64 (disabled) [ 0.365440] evm: security.SMACK64EXEC (disabled) [ 0.365442] evm: security.SMACK64TRANSMUTE (disabled) [ 0.365444] evm: security.SMACK64MMAP (disabled) [ 0.365446] evm: security.apparmor (disabled) [ 0.365448] evm: security.ima [ 0.365450] evm: security.capability [ 0.365451] evm: HMAC attrs: 0x1 [ 0.493476] SED: plpks not available [ 0.494783] clk: Disabling unused clocks [ 0.494845] md: Waiting for all devices to be available before autodetect [ 0.494851] md: If you don't use raid, use raid=noautodetect [ 0.494854] md: Autodetecting RAID arrays. [ 0.494857] md: autorun ... [ 0.494859] md: ... autorun DONE. [ 0.494883] List of all partitions: [ 0.494889] No filesystem could mount root, tried: [ 0.494890] [ 0.494898] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 0.494906] CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.14.0-478.el9.ppc64le #1 [ 0.494914] Call Trace: [ 0.494920] [c000001f43207b20] [c0000000008ea450] dump_stack_lvl+0x74/0xa8 [ 0.494931] [c000001f43207b60] [c0000000001557d8] panic+0x17c/0x454 [ 0.494938] [c000001f43207c00] [c000000002005d50] mount_root_generic+0x260/0x294 [ 0.494945] [c000001f43207cd0] [c000000002006258] prepare_namespace+0x2b0/0x320 [ 0.494950] [c000001f43207d50] [c000000002005608] kernel_init_freeable+0x264/0x2a4 [ 0.494955] [c000001f43207db0] [c000000000012760] kernel_init+0x30/0x1a0 [ 0.494959] [c000001f43207e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64 [ 0.507711] Rebooting in 10 seconds..
Hi, let's please keep problems with installing RHEL on PPC in jira, and leave this ticket for fedora and the specific x86 hardware that is affected. While these are all issues with finding enough memory for the initrd, on PPC this seems to be an issue with firmware not allocating enough memory, and a firmware update to 1060 has been reported to fix the issue. Michael and Krisztian, there are not new fedora-40 isos to try, but if you have the patience to try rawhide again, it contains a new release of grub2-2.12. I really don't know if this will work for you or not, but it would be great if you could give it a try. The initrds just keep getting bigger, and I saw from the memory maps that you provided that there simply is nowhere to put the initrd once the kernel has been allocated. We are talking about good ways to remedy this, but in the meantime please do try 2.12 if you can. thank you.
Hi, I just tried booting the Fedora Workstation 41 beta live CD 'Fedora-Workstation-Live-x86_64-41_Beta-1.2.iso'. It uses grub 2.12. Unfortunately I still get 'error: ../../grub-core/kern/mm.c:552:out of memory.' I am wondering why on a PC with 128GB of RAM there are not "memory holes" big enough to fit a large initrd image. Thanks,
Hi Michael, Could you please do a quick test and try turning off the wifi module (in the firmware menu) and try booting. Would it be also possible for you to take a picture of the lsefimmap command output each time (with and without the wifi module enabled) ? Thanks, Nicolas
Created attachment 2049371 [details] EFI Memory Map Fedora 41 Beta - All motherboard peripherals enabled Output of Fedora 41 Beta GRUB 2.12 when all motherboard peripherals were enabled
Created attachment 2049372 [details] EFI Memory Map Fedora 41 Beta - Motherboard Wi-Fi and Bluetooth disabled Output of Fedora Workstation 41 Beta GRUB 2.12 lsefimmap when the Wi-Fi and Bluetooth peripheral was disabled
Created attachment 2049373 [details] EFI Memory Map Fedora 41 Beta - All motherboard peripherals disabled Output of Fedora Workstation 41 Beta GRUB 2.12 lsefimmap when all motherboard peripherals were disabled: Intel 1Gbps LAN, Marvell 10Gbps LAN, Thunderbolt 4, Audio, Serial port. Two PCIe cards were still plugged in the system and active: Mellanox ConnectX-3 10Gbps NIC, AMD Radeon RX 7900 XTX GPU
Hi Nicolas, I tested booting Fedora Workstation 41 Beta (GRUB 2.12) and saved the output of lsefimmap with 3 different motherboard settings. Fedora never booted because GRUB crashed with the out of memory error. -1- with all motherboard peripherals enabled - The configuration I was using up to now and which works well with Windows 11 Pro and Ubuntu. -2- with the Wi-Fi and Bluethooth motherboard peripheral disabled -3- with all motherboard peripherals disabled (Intel 1Gbps LAN, Marvell 10Gbps LAN, Thunderbolt 4, Audio, Serial) Two PCIe cards were plugged in my PC during all these tests: Mellanox ConnectX-3, and AMD Radeon RX 7900 XTX I just attached the output of lsefimmap to this bug report (3 different PDF files). Thanks, Michael
Hi Nicolas, Did you look at the 3 EFI memory maps that I uploaded? I tried Arch Linux and a variant of Arch Linux called Garuda Linux. They all properly boot on my PC. I tried Debian 12.7. The GRUB 2.06 of Debian 12.7 also crashed with an out of memory error. Thanks, Michael
Hi Michael, Apologies, yes I did look at the memory maps, thanks for sending them. We think we might have possibly identified the issue and we're working on a fix. Would you be willing to try a test build when it's available ? Thanks, Nicolas
Yes, I would be glad to try a test build.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I checked the version. I was already updated to 41. I have reproduced this issues on my PC with Fedora Workstation 39, 40, and 41. Thanks for your help.
Hi everyone, If you're willing to try a f41 test build with a potential fix that'd be awesome. https://people.redhat.com/nfrayer/f41-2.12-mem/ Thanks.
Hi Nicolas, How do we use the rpms in the folder you shared to build a bootable USB key? Thanks
Hi, I've uploaded an ISO image that can be flashed on a USB stick. https://people.redhat.com/nfrayer/boot.iso This ISO only contains enough to boot the kernel and systemd, so you won't be able to install fedora from it, but at least it will tell us whether or not the fix works. Please note that you will have to disable Secure Boot as the grub in this ISO is not signed with our keys. To flash it onto a USB stick, I recommend that you use the Fedora Media Writer (or any other ISO flashing tool that you're familiar with). Please paste the screenshots of the boot here once you have tested. Thanks !
Hi, I just booted the experimental ISO image. I get the GRUB 2.12 menu. After pressing the "Install Fedora 41" option, I still get the GRUB "out of memory" error with some messages before. See the attached screenshot. Thanks!
Created attachment 2057879 [details] Experimental GRUB boot error
Hi, I'm having the same issue and I would like to know if there is any progress on this. I had managed to make use and install Majaro and Ubuntu, with the same hardware and BIOS config. I've tried the test image and i have the same output as Michael
I am also experiencing this issue. Please let me know if there is any information I can provide that will assist in finding a solution.
Hi, I just tried Fedora 42 with ISO image "Fedora-Workstation-Live-42-1.1.x86_64.iso" written to a USB key using "dd" on Linux. There is a slight change of behavior: the GRUB out of memory message still appears but is quickly replaced by another error screen. Here is what happens: -1- Boot the USB key -2- "GRUB version 2.12" boot selection menu appears -3- Select "Start Fedora-Live-Workstation" -4- An error screen is briefly shown: "error : ../../grub-core/kern/mm.c:552:out of memory. Press any key to continue..." -5- The previous screen is quickly replaced by another one: "KERNEL PANIC! Please reboot your computer. VFS: Unable to mount root fs on unknown-block(0,0)" I will attach a short video file showing this. The same USB key boots Fedora 42 Workstation Live on another older desktop PC I have. Because I have no choice, Garuda Linux (Arch Linux derivative) and now Ubuntu 24.04 are my daily Linux OS on this desktop PC. They boot on my desktop PC with the exact same hardware and BIOS/firmware configuration. Desktop PC configuration - Intel i7-14700K CPU - Asus ProArt Z790-CREATOR WIFI motherboard - 4 x G.Skill Ripjaws S5 DDr5-5600 CL36 32 GB UDIMMs => total of 128 GB RAM (maximum for this CPU) - Sapphire Radeon RX 7900 XTX Pulse GPU - NVIDIA Mellanox ConnectX-3 Ethernet Single Port SFP+ 10Gbps NIC - Thunderbolt 4.0 on the motherboard I disabled in the BIOS every piece of motherboard hardware not used: 2.5 Gbps Intel NIC, 10 Gbps Aqtion NIC, Wi-Fi 6E and Bluetooth, serial port. Maybe the abundance of hardware creates a memory map with smaller chunks of memory blocks. I understand this may prevent GRUB from loading the Linux kernel and/or initial ram disk. But the other Linux distributions can still do it. Will be willing to test any solution to this issue. Best regards, Michael
Created attachment 2096164 [details] Video showing Fedora 42 GRUB running out of memory and crashing on Asus ProArt Z790-CREATOR WIFI motherboard
I wanted to note here that I am also using an Asus motherboard. It may not make any difference but it seems it may be more than coincidence that each person here who has listed their hardware is using an Asus board. Here is more detail about what I'm running: - Intel i9-12900K CPU - Asus ROG MAXIMUS Z690 HERO - 2 x Corsair DDR5-5200 32GB - EVGA Nvidia GeForce RTX 3080 12GB
grub2-mkconfig -o /boot/grub2/grub.cfg gave me lexer.c:352:syntax error . I found solution making: bash sudo mv /etc/grub.d/45_custom /etc/grub.d/45_custom.disabled (45_custom seem to be corrupted) and bash sudo chmod -x /etc/grub.d/45_grub-customizer_menu_color_helper.bak sudo chmod -x /etc/grub.d/40_uefi-firmware_proxy.bak sudo chmod -x /etc/grub.d/41_uefi-firmware_proxy.bak sudo chmod -x /etc/grub.d/43_custom.bak.disabled sudo chmod -x /etc/grub.d/01_users.bak.disabled Now grub2-mkconfig -o /boot/grub2/grub.cfg is working but not sure than is the best solution
Hi, The same problem: Asus ProArt Z790-CREATOR WIFI motherboard / 13900k / 192GB RAM. I am on Silverblue and something must have been changed between 2025-08-25 and today. My deployment from 25th of August booted correctly and everything deployed today ( even the version from 25th deployed today) fails with out of mem error.
Just to add the system worked for years upgraded from fedora 35/36. It stopped working after just applying update. I have tried to boot past release and the last working is 34. All the versions after it throw out of memory
(In reply to Sebaastian Bleschke from comment #49) > Hi, > The same problem: Asus ProArt Z790-CREATOR WIFI motherboard / 13900k / 192GB > RAM. I am on Silverblue and something must have been changed between > 2025-08-25 and today. My deployment from 25th of August booted correctly and > everything deployed today ( even the version from 25th deployed today) fails > with out of mem error. Hi, Just so that I understand, you deployed f42 Silverblue about a week ago, and it booted fine, and then after applying the update it now fails to boot. Is that right? I installed Silverblue and then updated it and I can see that the initrd ballooned from 146M to 225M, so about 50% larger between the released version and the current version. I imagine that is the reason it is failing now... which makes your issue basically the same as everyone else reporting in this bug. I fail to see why the last working version is 34 if 42 was working for you last week, though. Can you roll back to the 42 deployment? @William Voyek, I also don't think it's a coincidence that you're all using the same motherboard... but there is clearly something wrong in our GRUB if y'all are able to install other OSes but not fedora, even if in some cases their initrd is a bit smaller.
No, the existing fedora 42 was installed years ago and just upgraded to 42 when it was released. I booted new Silverblue deployment on 25th of August and it worked fine. Next upgrade on 1st of September did not boot with the out of memory error and I could not get it working even with the deployment that was working prior to the update. I have tried to boot from usb but it was not working for any release after 34. I installed 34 on a new drive (nvme if it matters) and it booted, upgraded it to 42 - out of memory.
hi Sebaastian, yes I understand that you've had fedora installed for a long time, but you recently updated to 42, which was only released in mid April, after all. I just wanted to be sure that the difference between successful and failed boots was only the update. Normally updates don't cause this issue, but since the "regular" initrd for Silverblue is so large, I believe you're seeing the same issue as others in this bug. Could you please boot just to grub and post the output of the lsefimmap command? Perhaps you could do this both in f34 and booting some newer fedora from USB? thank you. :)
@Marta Lewandowska To your point, I tested several Linux distributions to check which one boots well on my PC (Intel i7-14700K CPU, Asus ProArt Z790-CREATOR WIFI motherboard, 4 x G.Skill Ripjaws S5 DDr5-5600 CL36 32 GB UDIMMs). Below are the results: - Arch Linux archlinux-2025.09.01-x86_64.iso => OK - CachyOS cachyos-desktop-linux-250828.iso => NOK (Grub out of memory error) - Debian 13 debian-13.0.0-amd64-netinst.iso => OK - Fedora nightly Fedora-Everything-netinst-x86_64-43-20250903.n.0.iso => NOK (Grub out of memory error) - Mint linuxmint-22.1-cinnamon-64bit.iso => OK - Ubuntu 24.04 I am dual-booting on this one every week => OK - Ubuntu 25.04 ubuntu-25.04-desktop-amd64.iso => OK Since I got this PC which was carefully built with components supposed to work well with Linux, I could not boot Fedora 39, 40, 41, 42, and probably also 43... :-( I wish there was a supported option to use another bootloader or boot straight into Fedora from UEFI like some other distributions. Best regards, Michael
@Michael Tadault I have just completed nearly the same process with the same result. All the Debian and Ubuntu distros booted OK but all tested versions of Fedora and Fedora based distros would not. @Marta Lewandowska Agreed, it would appear to be specific to something in the Fedora GRUB. I have been able to get my PC to boot Fedora successfully by completely disabling TPM in firmware (along with some other settings although I don't not remember specifically which). This is not a solution for me though as I need to keep it enabled for dual booting a BitLocker encrypted Windows drive. If needed I can gather all of the setting changes I made in the firmware in order to successfully boot
I managed to get output of lsefimmap This one from working Fedora 36 Type Physical start - end #Pages Size Attributes Conv-mem 0000000000000000-000000000009dfff 0000009e 632KiB UC WC WT WB reserved 000000000009e000-000000000009efff 00000001 4KiB UC WC WT WB BS-data 000000000009f000-000000000009ffff 00000001 4KiB UC WC WT WB conv-mem 0000000000100000-000000000c173fff 0000c074 197072KiB UC WC WT WB ldr-code 000000000c174000-0000000013eebfff 00007d78 128480KiB UC WC WT WB BS-data 0000000013eec000-0000000013f6bfff 00000080 512KiB UC WC WT WB conv—mem 0000000013f6c000-000000001460ffff 000006a4 6800KiB UC WC WT WB ldr-code 0000000014610000-000000001488cfff 0000027d 2548KiB UC WC WT WB ldr-data 000000001488d000-0000000014b0efff 00000282 2568KiB UC WC WT WB ldr-code 0000000014b0f000-0000000014bdcfff 000000ce 824KiB UC WC WT WB ldr-data 0000000014bdd000-000000001bbfffff 00007023 114828KiB UC WC WT WB BS-data 000000001bc00000-000000001bffffff 00000400 4MiB UC WC WT WB ldr-data 000000001c000000-000000001c00cfff 0000000d 52KiB UC WC WT WB BS-data 000000001c00d000-000000001c10cfff 00000100 1MiB UC WC WT WB BS-code 000000001c10d000-000000001c128fff 0000001c 112KiB UC WC WT WB BS-data 000000001c129000-000000001c157fff 0000002f 188KiB UC WC WT WB BS-code 000000001c158000-000000001c180fff 00000023 164KiB UC WC WT WB BS-data 000000001c181000-000000001c185fff 00000005 20KiB UC WC WT WB BS-code 000000001c186000-000000001c187ffF 00000002 8KiB UC WC WT WB BS-data 000000001c188000-000000001c18cfff 00000005 20KiB UC HC WT WB BS-code 000000001c18d000-000000001c190fff 00000004 16KiB UC WC WT WB BS-data 000000001c191000-000000001c198fff 00000008 32KiB UC WC WT WB BS-code 000000001c199000-000000001c19afff 00000002 8KiB UC WC WT WB BS-data 000000001c19b000-000000001c1a0fff 00000006 24KiB UC WC WT WB BS-code 000000001c1a1000-000000001c1a1fff 00000001 4KiB UC WC WT WB BS-data 000000001c1a2000-000000001c1ccfff 0000002b 172KiB UC WC WT WB BS-code 000000001c1cd000-000000001c1d0fff 00000004 16KiB UC WC WT WB BS-data 000000001c1d1000-000000001c1d8fff 00000008 32KiB UC WC WT WB BS-code 000000001c1d9000-000000001c1ddfff 00000005 20KiB UC WC WT WB BS-data 000000001c1de000-000000001c1edfff 00000010 64KiB UC WC WT WB BS-code 900000001c1ee000-000000001c234fff 00000047 284KiB UC WC WT WB BS-data 000000001c235000-000000001c2cafff 00000096 600KiB UC WC WT WB ldr-data 000000001c2cb000-000000001c2cbfff 00000001 4KiB UC WC WT WB BS-data 000000001c2cc000-000000001c3d3fff 00000108 1056KiB UC WC WT WB BS-code 000000001c3d4000-000000001c3dafff 00000007 28KiB UC WC WT WB BS-data 000000001c3db000-000000001c3e5fff 0000000b 44KiB UC WC WT WB BS-code 000000001c3e6000-000000001c3eafff 00000005 20KiB UC WC WT WB BS-data 000000001c3eb000-000000001c3f3fff 00000003 36KiB UC WC WT WB BS-code 000000001c3f4000-000000001c437fff 00000044 272KiB UC WC WT WB BS-data 000000001c438000-000000001da54fff 0000161d 22644KiB UC WC WT WB BS-code 000000001da55000-000000001da68fff 00000014 80KiB UC WC WT WB BS-data 000000001da69000-000000001da6cfff 00000004 416KiB UC WC WT WB BS-code 000000001da6d000-000000001da72fff 00000006 24KiB UC WC WT WB BS-data 000000001da73000-000000001e472fff 00000a00 10MiB UC WC WT WB BS-code 000000001e473000-000000001e8dbfff 00000469 4516KiB UC WC WT WB ldr-data 000000001e8dc000-000000001e8eafff 0000000f 60KiB UC WC WT WB conv-mem 000000001e8eb000-000000001ed9bfff 000004b1 4804KiB UC WC WT WB reserved 000000001ed9c000-000000001ed9cfff 00000001 4KiB UC WC WT WB conv-mem 000000001ed9d000-00000000296c0fff 0000a924 173200KiB UC WC WT WB BS-data 00000000296c1000-00000000298d8fff 00000218 2144KiB UC WC WT WB conv-mem 00000000298d9000-00000000298effff 00000017 92KiB UC WC WT WB BS-data 00000000298f0000-00000000298fbfff 0000000C 48KiB UC WC WT WB onv-mem 00000000298fc000-0000000029900fff 00000005 20KiB UC WC WT WB BS-data 0000000029901000-000000002993bfff 0000003b 236KiB UC WC WT WB conv-mem 000000002993c000-0000000029940fff 00000005 20KiB UC WC WT WB BS-data 0000000029941000-0000000029978fff 00000038 224KiB UC WC WT WB conv-mem 0000000029979000-000000002397afff 00000002 8KiB UC WC WT WB BS-data 000000002997b000-00000000299dafff 00000060 384KiB UC WC WT WB conv-mem 00000000299db000-00000000299defff 00000004 16KiB UC WC WT WB BS-data 00000000299df000-000000002fabafff 000060dc 99184KiB UC WC WT WB conv-mem 000000002fabb000-000000002fe16fff 0000035c 3440KiB UC WC WT WB BS-code 000000002fe17000-o000000030b88fff 00000d72 13768KiB UC WC WT WB reserved 0000000030b89000-0000000034888fff 00003d00 61MiB UC WC WT WB ACPI-rec 0000000034889000-0000000034cc1fff 00000439 4324KiB UC WC WT WB ACPI-nvs 0000000034cc2000-0000000034f1efff 0000025d 2420KiB UC WC NT WB RT-data 0000000034f1f000-0000000037f1efff 00003000 48MiB RT UC WC WT WE RT-code 0000000037f1f000-0000000037ffefff 000000e0 896KiB RT UC WC WT WE BS-data 0000000037fff000-0000000037ffffff 00000001 4KiB UC WC WT WB conv—mem 0000000100000000-00000030bf7fffff 02fbf800 195576MiB UC WC WT WB reserved 00000000000a0000-00000000000fffff 00000060 384KiB reserved 0000000038000000-000000003bffffff 00004000 64MiB UC WC WT WB reserved 000000003c400000-000000003c7fffff 00000400 4MiB UC WC WT WB reserved 000000003d000000-000000003dffffff 00001000 16MiB UC WB reserved 000000003e000000-00000000407fffff 00002800 40MiB MMIO 00000000c0000000-00000000cfffffff 00010000 256MiB RT UC MMIO 00000000fe000000-00000000fe010fff 00000011 68KiB RT UC MMIO 00000000fec00000-00000000fec00fff 00000001 4KiB RT UC MMIO 00000000fed00000-00000000fed00fff 00000001 4KiB RT UC reserved 00000000fed20000-00000000fed7ffff 00000060 384KiB MMIO 00000000fee00000-00000000fee00fff 00000001 4KiB RT UC MMIO 00000000ff000000-00000000ffffffff 00001000 16MiB RT UC WT WB WP and this from Fedora 43 (not working) Type Physical start - end #Pages Size Attributes conv—mem 0000000000000000-000000000009dfff 0000009e 632KiB UC WC WT WB reserved 000000000009e000-000000000009efff 00000001 4KiB UC WC WT WB BS-data 000000000009f000-000000000009ffff 00000001 4KiB UC WC WT HB conv—mem 0000000000100000-0000000011eebfff 00011dec 292784KiB UC WC WT WB 1dr-code 0000000011eec000-0000000013eebfff 00002000 32MiB UC WC WT WB BS-data 0000000013eec000-0000000013f6bfff 00000080 512KiB UC WC WT WB conv-mem 0000000013f6c000-00000000143dffff 00000474 4560KiB UC WC WT WB ldr-code 00000000143e0000-00000000147bbfff 000003dc 3952KiB UC WC WT WB ldr-data 00000000147bc000-0000000014b99fff 000003de 3960KiB UC WC WT WB conv-mem 0000000014b9a000-0000000014b9bfff 00000002 8KiB UC WC NT WB 1dr-code 0000000014b9c000-0000000014c6efff 000000d3 844KiB UC WC WT WB ldr-data 0000000014c6f000-000000001bbfffff 00006f91 114244KiB UC WC WT WB BS-data 000000001bc00000-000000001bffffff 00000400 4MiB UC WC WT HB ldr-data 000000001c000000-000000001c00cfff 0000000d 52KiB UC WC WT WB BS-data 000000001c00d000-000000001c10cfff 00000100 1MiB UC WC WT WB BS-code 000000001c10d000-000000001c128fff 0000001c 112KiB UC WC NT WB BS-data 000000001c129000-000000001c157Fff 0000002f 188KiB UC WC NT WB BS-code 000000001c158000-000000001c180fff 00000029 164KiB UC WC WT WB BS-data 000000001c181000-000000001c185fff 00000005 20KiB UC WC WT NB BS-code 000000001c186000-000000001c187fff 00000002 8kiB UC WC WT WB BS-data 000000001c188000-000000001c18cfff 00000005 20KiB UC WC WT WB BS-code 000000001c18d000-000000001c190fff 00000004 16KiB UC WC WT HB BS-data 000000001c191000-000000001c198fff 00000008 32KiB UC WC WT WB BS-code 000000001c199000-000000001c19afff 00000002 8KiB UC WC WT WB BS-data 000000001c19b000-000000001c1a0fff 00000006 24KiB UC WC WT WB BS-code 000000001c1a1000-000000001c1a1fff 00000001 4KiB UC WC WT WB BS-data 000000001c1a2000-000000001c1ccfff 0000002b 172KiB UC WC WT WB BS-code 000000001c1cd000-000000001c1d0fff 00000004 16KiB UC WC WT WB BS-data 000000001c1d1000-000000001c1d8fff 00000008 32KiB UC WC WT WB BS-code 000000001c1d9000-000000001c1ddfff 00000005 20KiB UC WC WT WB BS-data 000000001c1de000-000000001c1edfff 00000010 64KiB UC WC WT WB BS-code 000000001c1ee000-000000001c234dff 00000047 284KiB UC WC WT WB BS-data 000000001c235000-000000001c2cafff 00000096 600KiB UC WC HT WB ldr-data 000000001c2cb000-000000001c2cbfff 00000001 4KiB UC WC WT WB BS-data 000000001c2cc000-000000001c3d3fff 00000108 1056KiB UC WC WT WB BS-code 000000001c3d4000-000000001c3dafff 00000007 28KiB UC WC WT WB BS-data 000000001c3db000-000000001c3e5fff 0000000b 44KiB UC WC WT WB BS-code 000000001c3e6000-000000001c3eafff 00000005 20KiB UC WC WT WB BS-data 000000001c3eb000-000000001c3f3fff 00000009 36KiB UC WC WT WB BS-code 000000001c3f4000-000000001c437fff 00000044 272KiB UC WC WT WB BS-data 000000001c438000-000000001da54fff 0000161d 22644KiB UC WC WT WB BS-code 000000001da55000-000000001da68fff 00000014 80KiB UC WC WT WB BS-data 000000001da69000-0000oo001da6cfff 00000004 16KiB UC WC WT WB BS-code 000000001da6d000-000000001da72fff 00000006 24KiB UC WC WT WB BS-data 000000001da73000-000000001e472fff 00000a00 10MiB UC WC WT WB BS-code 000000001e473000-000000001e8dbfff 00000469 4516KiB UC WC WT WB ldr-data 000000001e8dc000-000000001e8eafff 0000000f 60KiB UC WC WT WB conv-mem 000000001e8eb000-000000001ed9bfff 000004b1 4804KiB UC WC WT WB reserved 000000001ed9c000-000000001ed9cfff 00000001 4KiB UC WC WT WB conv-mem 000000001ed9d000-0000000029a44fff 0000aca8 176800KiB UC WC WT WB BS-data 0000000029a45000-0000000029a5efff 0000001a 104KiB UC WC WT WB conv—mem 0000000029a5f000-0000000029a5ffff 00000001 4KiB UC WC WT WB BS-data 0000000029a60000-0000000029b99fff 0000013a 1256KiB UC WC WT WB conv-mem 0000000029b9a000-0000000029b9efff 00000005 20KiB UC WC WT WB BS-data 0000000029b9f000-0000000023d41fff 000001a3 1676KiB UC WC WT WB conv-mem 0000000029d42000-0000000029d4afff 00000003 36KiB UC WC WT WB BS-data 0000000029d4b000-0000000029da1fff 00000057 348KiB UC WC WT WB conv-mem 0000000029da2000-0000000029da5fff 00000004 16KiB UC WC WT WB BS-data 0000000029da6000-0000000029daffff 0000000a 40KiB UC WC WT WB conv-mem 0000000029db0000-0000000029db6fff 00000007 28KiB UC WC WT WB BS-data 0000000029db7000-0000000029e1cfff 00000066 408KiB UC WC WT WB conv-mem 0000000029e1d000-0000000029e1dfff 00000001 4KiB UC WC WT WB BS-data 0000000029e1e000-0000000029e5dfff 00000040 256KiB UC WC WT WB conv-mem 0000000029e5e000-0000000029e60fff 00000003 12KiB UC WC HT WB BS-data 0000000029e61000-0000000029e80fff 00000020 128KiB UC WC WT WB conv-mem 0000000029e81000-0000000029e81fff 00000001 4KiB UC WC WT WB BS-data 0000000029e82000-000000002bc65fff 00001de4 30608KiB UC WC WT WB conv-mem 000000002bc66000-000000002bc66fff 00000001 4KiB UC WC WT WB BS-data 000000002bc67000-000000002bdc3fff 0000015d 1396KiB UC WC WT WB conv-mem 000000002bdc4000-000000002bdc4fff 00000001 4KiB UC WC WT HB BS-data 000000002bdc5000-000000002fabafff 00003cf6 62424KiB UC WC WT HB conv-mem 000000002fabb000-000000002fe16fff 0000035c 3440KiB UC WC HT HB BS-code 000000002fe17000-0000000030b88fff 00000d72 13768KiB UC WC WT WB reserved 0000000030b89000-0000000034888fff 00003d00 61MiB UC WC WT WB ACPI-rec 0000000034889000-0000000034cc1fff 00000439 4324KiB UC WC WT WB ACPI-nvs 0000000034cc2000-0000000034f1efff 0000025d 2420KiB UC WC WT WB RT-data 0000000034f1f000-0000000037f1efff 00003000 48MiB RT UC WC WT RT-code 0000000037f1f000-0000000037ffefff 000000e0 896KiB RT UC WC WT BS-data 0000000037fff000-0000000037ffffff 00000001 4KiB UC WC WT WB conv-mem 0000000100000000-00000030bf7fffff 02fbf800 195576MiB UC WC WT WB reserved 00000000000a0000-00000000000fffff 00000060 384KiB reserved 0000000038000000-000000003bffffff 00004000 64MiB UC WC HT WB reserved 000000003c400000-000000003c7fffff 00000400 4MiB UC WC HT WB reserved 000000003d000000-000000003dffffff 00001000 16MiB UC WB reserved 000000003e000000-00000000407fffff 00002800 40MiB MMIO 00000000c0000000-00000000cfffffff 00010000 256MiB RT UC MMIO 00000000fe000000-00000000fe010fff 00000011 68KiB RT UC MMIO 00000000fec00000-00000000fec00fff 00000001 4KiB RT UC MMIO 00000000fed00000-00000000fed99fff 00000001 4KiB RT UC reserved 00000000fed20000-00000000fed7ffff 00000060 384KiB MMIO 00000000fee00000-00000000fee00fff 00000001 4KiB RT UC MMIO 00000000ff000000-00000000ffffffff 00001000 16MiB RT UC WT WB WP
Thank you very much for posting those, Sebaastian.
I compared Sebaastian and Michael lsefimmaps and I am NOT seeing a difference between OK and NOK boot systems, confirming a similar/identical EFI memory layout on both setups. NO root cause found yet. * Michael Tadault - NOK - EFI memory map reported by Fedora 40 GRUB https://bugzilla-attachments.redhat.com/attachment.cgi?id=2032860 Memory Type Total Size (in KiB) Total Size (in MiB) conv-mem 133,500,512 130,371.60 MMIO 278,608 272.1 reserved 236,468 230.9 ldr-data 212,752 207.8 BS-data 145,368 142 RT-data 58,368 57 ldr-code 37,488 36.6 BS-code 9,108 8.9 ACPI-rec 2,604 2.5 ACPI-nvs 2,260 2.2 RT-code 896 0.9 - OK - EFI memory map reported by Ubuntu 23.10 GRUB https://bugzilla-attachments.redhat.com/attachment.cgi?id=2032861 Memory Type Total Size (in KiB) Total Size (in MiB) conv-mem 133,500,512 130,371.60 MMIO 278,608 272.1 reserved 236,468 230.9 ldr-data 212,752 207.8 BS-data 145,368 142 RT-data 58,368 57 ldr-code 37,488 36.6 BS-code 9,108 8.9 ACPI-rec 2,604 2.5 ACPI-nvs 2,260 2.2 RT-code 896 0.9 * Sebaastian Bleschke Data comming from https://bugzilla.redhat.com/show_bug.cgi?id=2263643#c56 - NOK - Fedora 43 Memory Type Total Size (KiB) Total Size (MiB) conv-mem 199,419,080 194,745.20 MMIO 278,608 272.1 ldr-data 118,260 115.5 reserved 107,324 104.8 BS-data 99,412 97.1 RT-data 49,152 48 ldr-code 37,488 36.6 BS-code 14,080 13.8 ACPI-rec 4,324 4.2 ACPI-nvs 2,420 2.4 RT-code 896 0.9 - OK - Fedora 36 Memory Type Total Size (KiB) Total Size (MiB) conv-mem 199,419,080 194,745.20 MMIO 262,408 256.3 ldr-code 131,852 128.8 ldr-data 119,952 117.1 reserved 107,324 104.8 BS-data 104,188 101.7 RT-data 49,152 48 BS-code 14,080 13.8 ACPI-rec 4,324 4.2 ACPI-nvs 2,420 2.4 RT-code 896 0.9
Hello, I tried to install a fresh 42 iso and 'error: ../../grub-core/kern/mm.c:552:out of memory.' is still very much present. Every other Linux distribution work just fine. Same Motherboard (Asus ProArt Z790-CREATOR WIFI, BIOS 3002), different CPU (i9 14900K). I found a workaround, for some reason, if you test the media before installing it, you bypass the grub2 mm.c crash sometimes, and you can install Fedora 42. Grub2 post install is working just fine (for now ?). Hope this could help, Corentin
Hello, I also found a workaround for this issue. I disabled "Discrete Thunderbolt" support in the BIOS. Sebastian
Thanks for the update Corentin/Sebastian. Sebastian, once Fedora is installed, can you please try to re-enable the discrete Thunderbolt and boot the installed Fedora ? My (strong) suspicion is that this motherboard series having a lot of on-board modules needs a lot of memory for them so it might be fragmenting it a way that the initramfs from the install media can't be stored in a contiguous memory block. Also I *think* the Fedora install initramfs is bigger than other distros, hence no issues with Ubuntu for example. Thanks for testing and we're still brainstorming to find a way to solve this.
@Nicolas Frayer It was not during installation. I got this error when I tried to upgrade my Fedora 42 Silverblue to kernel 6.16 (check my other messages). I could not boot any kernel after that, even those versions that worked before. I tried to boot different versions from usb - everything after fedora 34 failed to boot. I also install 34 and upgraded it - it did not work too
I have created a new iso [1], this is Fedora Rawhide + memtools module, the latter including some memory tools commands that I want you (Sebastian, Corentin, Michael or any other :) ) to run and post the results, in particular this one `lsmemregions` [2]. This command would tell us the amount of free and allocated memory per region on your setups. There is another command that shows a bit more about how much memory we can allocated, so also run `stress_big_allocations`. Both commands should be available in the grub's prompt when installing the iso on a UEFI machine. The iso will not fix the issue, it just contains an instrumented grub with some more commands but ultimately it will yield the OOM. In the meantime, we are still working on a fix. [1] https://people.redhat.com/lsandova/oom/fedora-rawhide-grub-memtools.iso [2] https://lists.gnu.org/archive/html/grub-devel/2025-09/msg00249.html
Created attachment 2108369 [details] GRUB lsmemregions output
Created attachment 2108370 [details] GRUB stress_big_allocs output
Thanks Leo, I have attached the output of 'lsmemregions' and 'stress_big_allocs' on my desktop. Best regards, Michael Tadault
(In reply to Michael Tadault from comment #66) > Thanks Leo, Thanks to you, this is good info. Based on the stress log, system can allocate at most 108MB and probably the initramfs is greater than the latter space. > > I have attached the output of 'lsmemregions' and 'stress_big_allocs' on my > desktop. Can you please download again the ISO and try reproducing the OOM (=installing Fedora)? This time, it should print a stack back-trace and we should be able to identify the caller which ultimately is calling the memory allocation subroutine. As always, upload the pdf with the result. Regards > > Best regards, > > Michael Tadault
Created attachment 2109337 [details] Booting Fedora rawhide
Hi, I booted the Fedora rawhide iso. Pressing "Install Fedora Rawhide" in GRUB shows a black screen for a few seconds and returns to the GRUB menu. Pressing "Test this media & install Fedora Rawhide" in GRUB shows the screenshot that I just uploaded as a PDF "Booting Fedora rawhide". I am not sure it contains much more information. Then the GRUB menu returns. Pressing again this option just shows a black screen for a few seconds and returns to the GRUB menu. Best regards, Michael Tadault
Team, we have a possible fix [1], not yet tested so please try the iso [2] with checksum [3] and let me know if you still seeing the OOM. This change only impacts UEFI x64 machines, which I believe this is the case for all reported systems. [1] https://github.com/lsandov1/grub2/commit/6948df84eedd5283fa4f6221a688b815a38b83ef [2] https://people.redhat.com/lsandova/oom/f44-efi-mem-fix.iso [3] https://people.redhat.com/lsandova/oom/f44-efi-mem-fix.sha1sum
(In reply to Michael Tadault from comment #69) > Hi, > > I booted the Fedora rawhide iso. > > Pressing "Install Fedora Rawhide" in GRUB shows a black screen for a few > seconds and returns to the GRUB menu. > > Pressing "Test this media & install Fedora Rawhide" in GRUB shows the > screenshot that I just uploaded as a PDF "Booting Fedora rawhide". I am not > sure it contains much more information. Then the GRUB menu returns. Pressing > again this option just shows a black screen for a few seconds and returns to > the GRUB menu It does contain useful info. Although it is not completely obvious from the backtrace, we detected that the problem was when 'opening' the kernel images and not the initrd. Opening a file in grub implies a verification phase and on this area the OOM was raising. The proposed fix [1] uses another memory pool (efi) which is much bigger that the grub one. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2263643#c70 > > Best regards, > > Michael Tadault
Hi Leo, Thanks for trying to find a fix. I tried f44-efi-mem-fix.iso. Most of the time I just get a black screen before returning to the GRUB menu. From time to time, when I select "Test this media & install Fedora Rawhide", I get the following error message: "error: ../../grub-core/kern/verifiers.c:efi_buff_malloc:203:can't allocate kernel." After a couple of seconds, the GRUB menu reappears. Best regards, Michael Tadault
(In reply to Michael Tadault from comment #72) > Hi Leo, > > Thanks for trying to find a fix. I tried f44-efi-mem-fix.iso. > > Most of the time I just get a black screen before returning to the GRUB menu. > Once you select an entry, it goes blank and then back to the menu and it loops this way forever so the installation is actually not possible? > From time to time, when I select "Test this media & install Fedora Rawhide", > I get the following error message: "error: > ../../grub-core/kern/verifiers.c:efi_buff_malloc:203:can't allocate kernel." something minor: it is pretty strange that it prints 203, it should be 283 where that line is inside the efi_buff_malloc function. > After a couple of seconds, the GRUB menu reappears. > > Best regards, > > Michael Tadault
Yes, the installation cannot proceed. I get stuck at the GRUB boot menu. The same USB key works well on an older PC where I can proceed with the installation. Yes, the line number is 283 and not 203. Zero and eight look almost the same on the screenshot I took. Best regards, Michael Tadault
(In reply to Michael Tadault from comment #74) > Yes, the installation cannot proceed. I get stuck at the GRUB boot menu. The > same USB key works well on an older PC where I can proceed with the > installation. on the older PC, did it use to work fine even with a fedora release version? or the version I shared actually fixes the issue for this PC? > > Yes, the line number is 283 and not 203. Zero and eight look almost the same > on the screenshot I took. thanks for looking into it. I though I shared another wrong iso, but it is not the case. > > Best regards, > > Michael Tadault
Fedora has always booted well on the older PC. I use it to validate that the USB keys written with the iso images here work well. I hope you can find a solution. Thanks,
*** Bug 2413315 has been marked as a duplicate of this bug. ***
Hi all, I am experiencing the same issue with the F43 live CD (F42 still works) on a Lenovo Yoga 720-13IKB (81C3) laptop with the following specs: CPU: Intel i7-8550U GPU: Intel UHD 620 Memory: 16GB Screen: 3840x2160 (read somewhere that this might be important) This also happens with Silverblue and Bluefin. Will attach outputs of debug=regions and lsefimmap below. Wanted to run some of the debugging tools posted in this thread but the links don't seem to be working for me (anymore). Happy to do more debugging and/or provide more info. Best, Jacob
Created attachment 2115823 [details] Boot output with debug=regions On Lenovo Yoga 720-13IKB
Created attachment 2115826 [details] Output of lsefimmap On Lenovo Yoga 720-13IKB
Hi Jacob, If you can, can you please try to disable TPM in the bios and try again ? Thanks, Nicolas
Hi, I tried to boot Fedora Workstation 43. I still get the same error. Therefore I updated the title of the bug report to include release 43 of Fedora. Best regards, Michael Tadault
(In reply to Nicolas Frayer from comment #81) > Hi Jacob, > > If you can, can you please try to disable TPM in the bios and try again ? > > Thanks, > > Nicolas Hi Nicholas, Thanks so much for the quick response. This indeed worked! I'm able to boot current versions of Fedora again. Still happy to help with debugging/testing future fixes for the root cause of this if needed. :) Best, Jacob
(In reply to Nicolas Frayer from comment #81) > Hi Jacob, > > If you can, can you please try to disable TPM in the bios and try again ? > > Thanks, > > Nicolas I commented back in September [https://bugzilla.redhat.com/show_bug.cgi?id=2263643#c55] that disabling TPM allowed booting of 42 (the latest released installer at that time). Unfortunately, for me this is not a solution as I must have TPM enabled.
Hi Jacob, Thanks for trying this. Please read below. William, I did see your comment and I agree that this is not a solution but more a way for us to confirm where to look. We don't recommend disabling it and this is just for testing. Thanks, Nicolas
team, can you please test this iso [1], this time we are proposing a larger allocation area [2]. Internally we tried lower values (4G and 8G) but ultimately this patch sets the max value. [1] https://people.redhat.com/lsandova/oom/boot-max.iso [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198
(In reply to Leo Sandoval from comment #86) > team, > > can you please test this iso [1], this time we are proposing a larger > allocation area [2]. > > Internally we tried lower values (4G and 8G) but ultimately this patch sets > the max value. > > [1] https://people.redhat.com/lsandova/oom/boot-max.iso > [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198 Hi Leo, I can happily report that this iso boots on my machine also with TPM enabled. Let me know if you need logs. Jacob
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
(In reply to Jacob Scharmberg from comment #87) > (In reply to Leo Sandoval from comment #86) > > team, > > > > can you please test this iso [1], this time we are proposing a larger > > allocation area [2]. > > > > Internally we tried lower values (4G and 8G) but ultimately this patch sets > > the max value. > > > > [1] https://people.redhat.com/lsandova/oom/boot-max.iso > > [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198 > > Hi Leo, > > I can happily report that this iso boots on my machine also with TPM > enabled. Let me know if you need logs. Great Jacob! No need for logs this time. Let's wait for others to test it. > > Jacob
*** Bug 2313804 has been marked as a duplicate of this bug. ***
(In reply to Leo Sandoval from comment #86) > team, > > can you please test this iso [1], this time we are proposing a larger > allocation area [2]. > > Internally we tried lower values (4G and 8G) but ultimately this patch sets > the max value. > > [1] https://people.redhat.com/lsandova/oom/boot-max.iso > [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198 Installing the RPMs from [2] has fixed the problem for me in Fedora 43. Prior I had the `mm.c with out of memory error` and the workaround was to disable TPM from Asus BIOS. Disabling discrete Thunderbolt didn't help and I don't have integrated GPU AFAIK.
(In reply to Niklas from comment #91) > (In reply to Leo Sandoval from comment #86) > > team, > > > > can you please test this iso [1], this time we are proposing a larger > > allocation area [2]. > > > > Internally we tried lower values (4G and 8G) but ultimately this patch sets > > the max value. > > > > [1] https://people.redhat.com/lsandova/oom/boot-max.iso > > [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198 > > Installing the RPMs from [2] has fixed the problem for me in Fedora 43. > > Prior I had the `mm.c with out of memory error` and the workaround was to > disable TPM from Asus BIOS. Disabling discrete Thunderbolt didn't help and I > don't have integrated GPU AFAIK. When TPM is on, there is a second initrd memory allocation on behalf of the 'verifier', so at some point this was not enough to keep in in memory within the address range we had before. The patch simply increases the memory range (from 2^31-1 to 2^64-1) so memory pool is (much) greater. This change may impact systems where IOMMU is off, thus testing is critical before merging PR into rawhide (and back port it as some point).
team, please check https://fedoraproject.org/wiki/Test_Day:2025-12-15_GRUB_out_of_memory_verification, this is a new ISO (indicated in the wiki, this time a LIVE system ISO but same fix) to test; once tested, do not forget to post your results as indicated in the wiki. tks
I am able to boot normally with the linked to Live ISO but once at the desktop I'm running into display issues so I'm currently unable to complete the Test Day. I'll work on the display problems and post there as soon as I am able. This is GREAT progress though!
Hi Leo, I tried the ISO in https://fedoraproject.org/wiki/Test_Day:2025-12-15_GRUB_out_of_memory_verification and successfully booted Fedora 44 rawhide. I reported the result as described in the wiki. Thank you so much for finding a solution! It's the first time the desktop PC I built in February 2024 boots Fedora Workstation. I hope this patch can make it into the final Fedora Workstation 44 release. I will try the other desktop PCs I have access to and always booted Fedora. Best regards, Michael Tadault
Thanks team! All looks fine! for sure this commit will be part of the 44 release. Last stats: almost 2 years of investigation & testing and about 100 comments. What an issue! BTW, This patch will not be ported unless required, so for the moment just targeting 44.
I'm adding this comment just to thank everyone for finding a solution. As Micheal this has been the first time Fedora booted on my new laptop and I was going to miss it on my laptop. So let's wait for the 44 Release now! Thanks again
team, We have two regression [1,2] with the proposed (and merged) fix [3] so unfortunately this is not yet over: During the test day [TestDay], most testers booted fine the iso so we merged [3]. During the previous weekend (10-11 Jan 2026), people found boot issues [1] so [3] was untagged [4]. We are suspecting that this is something related to the filesystem (btrfs?) and this is why during the test day using a Live OS did not catch it. Test Day was indeed useful, fix worked but not for all systems so clearly the fix needs to be revisited. I ask you the following: From a stable system/grub, can you (RE)INSTALL these instructions: $ sudo dnf install -y koji $ mkdir tmp & cd tmp $ koji download-task 140906146 # aka [5], this is just a scratch build just for x86_64, disable SB $ sudo dnf install *.rpm $ sudo reboot The fix [5] contains [3] plus some instrumentation enabling debugging ('debug=all,-lexer,-scripting'). In case of FAILURE (you boot but ended up in the grub prompt instead of the grub menu) please attach a video recording all the boot process and also in the comment indicate your block/partition/fs scheme with 'lsblk -f'. In case of SUCCESS, just provide the output of the latter cmd. I am also preparing another test-day which will basically do the above steps but I will wait hoping that we will get enough results here first. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2427945 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2422881 [3] https://src.fedoraproject.org/rpms/grub2/pull-request/198 [4] https://forge.fedoraproject.org/releng/tickets/issues/13157 [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=141063848 [TestDay] https://fedoraproject.org/wiki/Test_Day:2025-12-15_GRUB_out_of_memory_verification
(In reply to Leo Sandoval from comment #98) > team, > > We have two regression [1,2] with the proposed (and merged) fix [3] so > unfortunately > this is not yet over: During the test day [TestDay], most testers booted > fine the iso > so we merged [3]. During the previous weekend (10-11 Jan 2026), people > found boot issues [1] so [3] was untagged [4]. We are suspecting that this > is something > related to the filesystem (btrfs?) and this is why during the test day using > a Live OS did not catch it. Test Day was indeed useful, fix worked but not > for all > systems so clearly the fix needs to be revisited. > > I ask you the following: From a stable system/grub, can you (RE)INSTALL > these instructions: > > $ sudo dnf install -y koji > $ mkdir tmp & cd tmp > $ koji download-task 140906146 # aka [5], this is just a scratch build just > for x86_64, disable SB Sorry for the noise, I meant $ koji download-task 141063848 which corresponds to [5] and NOT 140906146 > $ sudo dnf install *.rpm > $ sudo reboot > > The fix [5] contains [3] plus some instrumentation enabling debugging > ('debug=all,-lexer,-scripting'). > In case of FAILURE (you boot but ended up in the grub prompt instead of the > grub menu) please > attach a video recording all the boot process and also in the comment > indicate your block/partition/fs > scheme with 'lsblk -f'. In case of SUCCESS, just provide the output of the > latter cmd. > > I am also preparing another test-day which will basically do the above steps > but I will wait hoping > that we will get enough results here first. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2427945 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2422881 > [3] https://src.fedoraproject.org/rpms/grub2/pull-request/198 > [4] https://forge.fedoraproject.org/releng/tickets/issues/13157 > [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=141063848 > [TestDay] > https://fedoraproject.org/wiki/Test_Day:2025-12- > 15_GRUB_out_of_memory_verification
Hi Leo, I installed Fedora Rawhide one of the NVMe SSDs of my desktop using the iso boot image of https://fedoraproject.org/wiki/Test_Day:2025-12-15_GRUB_out_of_memory_verification I chose to use ext4 for the root filesystem and /boot (no btrfs). It seems to work well and I rebooted Fedora Rawhide successfully several times. I followed your instructions upgrading grub2 from 2.12-49 to 2.12-50. After the reboot I end up at the empty grub prompt (Fedora not booting). I am attaching the video of the failed boot. Below the disk map (output of lsblk -f) before the boot. NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 └─sda2 ntfs WinHome D6609632609618F7 sr0 zram0 swap 1 zram0 116bdabf-e938-4d2c-a172-c0df754cced3 [SWAP] nvme1n1 ├─nvme1n1p1 vfat FAT32 78CE-481D 933.4M 2% /boot/efi ├─nvme1n1p2 ext4 1.0 980b0134-2bd1-4dbb-8976-295af51f2d2e 1.3G 21% /boot ├─nvme1n1p3 ext4 1.0 0e3db95a-a472-4807-a700-f07d6fb21e7e 858.8G 1% / ├─nvme1n1p4 vfat FAT32 70A4-5760 ├─nvme1n1p5 vfat FAT32 70EE-9375 └─nvme1n1p6 ext4 1.0 2d191cc2-b7a4-4c75-b12d-48168aa838e8 nvme2n1 ├─nvme2n1p1 └─nvme2n1p2 ntfs Jeux 5A38918A389165B3 nvme0n1 ├─nvme0n1p1 vfat FAT32 726A-E30A ├─nvme0n1p2 ├─nvme0n1p3 ntfs 9E346C08346BE22F └─nvme0n1p4 ntfs 0CD286F2D286DF78 Best regards, Michael Tadault
The video file is too large to be attached. Please find below a link to the video. https://drive.google.com/file/d/1bVqaQGm_zcIJ2gTg7Rfy_XuxmuJ6oaOJ/view?usp=sharing
(In reply to Michael Tadault from comment #100) > Hi Leo, > > I installed Fedora Rawhide one of the NVMe SSDs of my desktop using the iso > boot image of > https://fedoraproject.org/wiki/Test_Day:2025-12- > 15_GRUB_out_of_memory_verification > > I chose to use ext4 for the root filesystem and /boot (no btrfs). It seems > to work well and I rebooted Fedora Rawhide successfully several times. > > I followed your instructions upgrading grub2 from 2.12-49 to 2.12-50. After > the reboot I end up at the empty grub prompt (Fedora not booting). This results conflicts with the result from the ticket/comment https://bugzilla.redhat.com/show_bug.cgi?id=2427945#c7 where 2.12-49 fails booting but in your case it is working! The -49 change has the corresponding OOM fix and -50 is something completely unrelated so I do not understand yet how -50 is impacting. Can you do the same experiment, boot from the the test-day iso, install fedora but this time download the following official build (which unfortunately it has been untagged) koji download-build --arch=x86_64 --arch=noarch grub2-2.12-50.fc44 and install the corresponding rpms? basically we are doing the same as before but this time using a non-instrumented grub, so in theory you will see the same result. > > I am attaching the video of the failed boot. Below the disk map (output of > lsblk -f) before the boot. Thanks. I am attaching the last frame that contains log, for reference. > > NAME FSTYPE FSVER LABEL UUID > FSAVAIL FSUSE% MOUNTPOINTS > sda > > ├─sda1 > > └─sda2 ntfs WinHome D6609632609618F7 > > sr0 > > zram0 swap 1 zram0 116bdabf-e938-4d2c-a172-c0df754cced3 > [SWAP] > nvme1n1 > > ├─nvme1n1p1 vfat FAT32 78CE-481D > 933.4M 2% /boot/efi > ├─nvme1n1p2 ext4 1.0 980b0134-2bd1-4dbb-8976-295af51f2d2e > 1.3G 21% /boot > ├─nvme1n1p3 ext4 1.0 0e3db95a-a472-4807-a700-f07d6fb21e7e > 858.8G 1% / > ├─nvme1n1p4 vfat FAT32 70A4-5760 > > ├─nvme1n1p5 vfat FAT32 70EE-9375 > > └─nvme1n1p6 ext4 1.0 2d191cc2-b7a4-4c75-b12d-48168aa838e8 > > nvme2n1 > > ├─nvme2n1p1 > > └─nvme2n1p2 ntfs Jeux 5A38918A389165B3 > > nvme0n1 > > ├─nvme0n1p1 vfat FAT32 726A-E30A > > ├─nvme0n1p2 > > ├─nvme0n1p3 ntfs 9E346C08346BE22F > > └─nvme0n1p4 ntfs 0CD286F2D286DF78 > This is a different partition scheme than https://bugzilla.redhat.com/show_bug.cgi?id=2427945#c15, the latter is btrfs on / & /home and no /boot partition so this issue is FS-agnostic I would say. > > Best regards, > > Michael Tadault
Created attachment 2122766 [details] last debug frame from https://bugzilla.redhat.com/show_bug.cgi?id=2263643#c101
Hi Leo, I followed the instructions above: - booted from Test Day iso image, - manually created 3 partitions: EFI FAT32, boot ext4, root ext4 (the idea is to leave Manjaro Linux untouched on 3 other existing partitions) - installed Fedora Rawhide on these 3 partitions - rebooted successfully several times; for some reason the Fedora installation program makes the Manjaro EFI partition disappear from the BIOS menu; I must always restore the content of the Manjaro Linux EFI partition after I delete the 3 Fedora partitions - installed grub2 2.50 from the official build - rebooted successfully several times Below the output of lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 └─sda2 ntfs WinHome D6609632609618F7 sr0 zram0 swap 1 zram0 73a09305-c856-4490-afc2-c31982f7c75f [SWAP] nvme2n1 ├─nvme2n1p1 └─nvme2n1p2 ntfs Jeux 5A38918A389165B3 nvme1n1 ├─nvme1n1p1 vfat FAT32 AB83-465C 933.4M 2% /boot/efi ├─nvme1n1p2 ext4 1.0 c8bb86e1-f74e-4548-8eee-d16756a0ae46 1.3G 21% /boot ├─nvme1n1p3 ext4 1.0 40c62d81-cc86-46cd-bc53-e67fee0fd973 78.8G 8% / ├─nvme1n1p4 vfat FAT32 70A4-5760 ├─nvme1n1p5 vfat FAT32 70EE-9375 └─nvme1n1p6 ext4 1.0 2d191cc2-b7a4-4c75-b12d-48168aa838e8 nvme0n1 ├─nvme0n1p1 vfat FAT32 726A-E30A ├─nvme0n1p2 ├─nvme0n1p3 ntfs 9E346C08346BE22F └─nvme0n1p4 ntfs 0CD286F2D286DF78 FYI - nvme1n1p5 = Manjaro Linux EFI, nvme1n1p4 = Manjaro Linux boot, nvme1n1p6 = Manjaro Linux root Best regards, Michael Tadault
(In reply to Michael Tadault from comment #104) > Hi Leo, > > I followed the instructions above: > - booted from Test Day iso image, > - manually created 3 partitions: EFI FAT32, boot ext4, root ext4 (the idea > is to leave Manjaro Linux untouched on 3 other existing partitions) > - installed Fedora Rawhide on these 3 partitions > - rebooted successfully several times; for some reason the Fedora > installation program makes the Manjaro EFI partition disappear from the BIOS > menu; I must always restore the content of the Manjaro Linux EFI partition > after I delete the 3 Fedora partitions > - installed grub2 2.50 from the official build > - rebooted successfully several times Hi Michael, this confirms that the OK/NOK booting result depends on the motherboard/firmware so unfortunately we need more testing before proposing another patch. In resume, in your case 2.12-50 works but other systems are being impacted with it but in the mean time we have reverted 2.12-50. I strongly believe we are being impacted by some storage controllers not DMAing correctly above 0x7ffffff (2GB) so GRUB cannot find the correct partition layout and it cannot proceed. While I keep investigating other solutions, I am planning another test-day, details will be share shortly.
Hi team, we have a new fix [1] and hopefully this time would be the final one. A bit of resume of this peculiar issue: the OOM issue is seen on those system with limited memory pool so we try to increase the memory pool for grub_malloc [2] but hit other (unexpected) issues [3] so [2] was reverted. Before going into a second test-day for this OOM issue (if needed), I have proposed two testing scenarios below. For both, please use a tesing HW (NEVER on your working desktop/lap) and DISABLE Secure boot (unsigned GRUB binaries for the moment) temporaly. - Option 1: ISO install (for those that cannot install Fedora due to OOM issues) 0. Disable Secure boot 1. Download the ISO [5] which contains the fix, flash it on a USB stick 3. boot with it your HW. In theory the OOM would be seen here on those particular machines where OOM has been observed before 4. If possible and your time allows, please install Fedora (use 'On the Network' in the Installation Source menu, this is just in case the auto-detect installation media fails). The reason we are asking for full installation is that last time we did not testers this step and we ended up with [3]. 5. Reboot your new Fedora System 6. Follow instructions below (Option 2). 7. Share your results. - Option 2: RPM install (for those already running a Fedora rawhide system) 0. Disable Secure boot 1. Boot your system 2. Download the rpms[4], e.g. koji download-task --arch=x86_64 --arch=noarch 141497105 3. install the rpms, e.g. sudo dnf install *.rpm 4. Reboot 5. Share results [1] https://src.fedoraproject.org/rpms/grub2/pull-request/207 [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2427945 [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=141497105 [5] https://people.redhat.com/lsandova/oom/boot-efi-alloc-on-verifiers.iso
Hi Leo, I booted from [5] and installed Fedora Rawhide Workstation on free space in ones of my SSDs (manual partitioning, ext4). I installed from the network and chose not to update to the latest versions of the packages. I could successfully reboot the resulting Fedora Rawhide Workstation. The grub2 version is 2.12-53. I installed the rpms from [4]. These rpms are still versioned 2.12.-54. I could successfully reboot the updated Fedora Rawhide Workstation. Find below the output of 'lsblk -f' NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 └─sda2 ntfs WinHome D6609632609618F7 sr0 zram0 swap 1 zram0 7918c9cd-73ee-4e49-bae4-79b5d564053c [SWAP] nvme1n1 ├─nvme1n1p1 vfat FAT32 726A-E30A ├─nvme1n1p2 ├─nvme1n1p3 ntfs 9E346C08346BE22F └─nvme1n1p4 ntfs 0CD286F2D286DF78 nvme2n1 ├─nvme2n1p1 └─nvme2n1p2 ntfs Jeux 5A38918A389165B3 nvme0n1 ├─nvme0n1p1 vfat FAT32 4FD3-ECD5 943.3M 1% /boot/efi ├─nvme0n1p2 ext4 1.0 c8f9c31d-373d-47d0-a26c-71fe78d17a52 1.3G 19% /boot ├─nvme0n1p3 ext4 1.0 4e915743-349a-4d26-89b0-23d31e407774 859.5G 1% / ├─nvme0n1p4 vfat FAT32 70A4-5760 ├─nvme0n1p5 vfat FAT32 70EE-9375 └─nvme0n1p6 ext4 1.0 2d191cc2-b7a4-4c75-b12d-48168aa838e8 Best regards, Michael Tadault
Sorry. The koji rpms are version 2.12-53 (not 2.12-54 as written uin the previous comment).
(In reply to Michael Tadault from comment #107) > Hi Leo, > > I booted from [5] and installed Fedora Rawhide Workstation on free space in > ones of my SSDs (manual partitioning, ext4). I installed from the network > and chose not to update to the latest versions of the packages. I could > successfully reboot the resulting Fedora Rawhide Workstation. The grub2 > version is 2.12-53. > > I installed the rpms from [4]. These rpms are still versioned 2.12.-54. I > could successfully reboot the updated Fedora Rawhide Workstation. Great news, thanks Michael. I will work with Fedora QA people to organize a test-day so hopefully we get more audience and extend the testing to other platforms.
(In reply to Michael Tadault from comment #108) > Sorry. The koji rpms are version 2.12-53 (not 2.12-54 as written uin the > previous comment). right, makes sense. 2.12-53 is the version to test
(In reply to Leo Sandoval from comment #106) > Hi team, > > we have a new fix [1] and hopefully this time would be the final one. A bit > of resume > of this peculiar issue: the OOM issue is seen on those system with limited > memory pool > so we try to increase the memory pool for grub_malloc [2] but hit other > (unexpected) issues [3] so > [2] was reverted. > > Before going into a second test-day for this OOM issue (if needed), I have > proposed two testing scenarios below. > For both, please use a tesing HW (NEVER on your working desktop/lap) and > DISABLE Secure boot (unsigned GRUB binaries > for the moment) temporaly. > > - Option 1: ISO install (for those that cannot install Fedora due to OOM > issues) > 0. Disable Secure boot > 1. Download the ISO [5] which contains the fix, flash it on a USB stick > 3. boot with it your HW. In theory the OOM would be seen here on those > particular machines where OOM has been observed before > 4. If possible and your time allows, please install Fedora (use 'On the > Network' in the Installation Source menu, this is just > in case the auto-detect installation media fails). The reason we are > asking for full installation is that last time we did not > testers this step and we ended up with [3]. > 5. Reboot your new Fedora System > 6. Follow instructions below (Option 2). > 7. Share your results. > > - Option 2: RPM install (for those already running a Fedora rawhide system) > 0. Disable Secure boot > 1. Boot your system > 2. Download the rpms[4], e.g. koji download-task --arch=x86_64 > --arch=noarch 141497105 > 3. install the rpms, e.g. sudo dnf install *.rpm > 4. Reboot > 5. Share results > > [1] https://src.fedoraproject.org/rpms/grub2/pull-request/207 > [2] https://src.fedoraproject.org/rpms/grub2/pull-request/198 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=2427945 > [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=141497105 > [5] https://people.redhat.com/lsandova/oom/boot-efi-alloc-on-verifiers.iso Hi Leo, Sorry for the radio silence, had a busy couple of weeks. I wanted to test this today but it seems like the koji task cannot be downloaded anymore? Happy to do more testing if needed.
> Hi Leo, > > Sorry for the radio silence, had a busy couple of weeks. > > I wanted to test this today but it seems like the koji task cannot be > downloaded anymore? Happy to do more testing if needed. Hi Jacob & team, This week (Feb 9th-13th) is the [test day] for this particular fix, so please follow the instructions there and provide feedback. Instructions for the test day are different as the one I posted before but ultimately the same [oom fix] is being tested. [test day] https://fedoraproject.org/wiki/Test_Day:2026-02-09_GRUB_out_of_memory_fix_verification_part_2 [oom fix] https://src.fedoraproject.org/rpms/grub2/pull-request/207
Hi Leo, I submitted successful test results for two systems: - the one that has the Grub2 out-of-memory issue - an older one that never had this issue I hope the fix will make it into the next Fedora release. Best regards, Michael Tadault
Hi Leo, I have completed the test day on my machine that originally had the OOM error (test completed successfully). I will test on two other systems early next week. Best, Jacob
Hi Leo, I just tested Fedora Workstation 44 Beta. Grub crashes with the out of memory error... Did the fix make it into release 44? Best regards, Michael Tadault
(In reply to Michael Tadault from comment #115) > Hi Leo, Hi Michael, > > I just tested Fedora Workstation 44 Beta. Grub crashes with the out of > memory error... > > Did the fix make it into release 44? I did not, we miss the merge window :( but it is now merged on rawhide now (https://src.fedoraproject.org/rpms/grub2/c/9fc30f762e2ff12d38b68cd02943b612389a5d8e?branch=rawhide) https://src.fedoraproject.org/rpms/grub2/commits/rawhide I was tempted to merge it but I decided to wait until fully tested through the 'test day', so this also delay a bit but it was a safer approach. No OOM reports since the merge so everything should be fine on this area starting at fedora 45 BTW, We will backport the corresponding patch to 44 (and 43). Regards, > > Best regards, > > Michael Tadault
(In reply to Leo Sandoval from comment #116) > (In reply to Michael Tadault from comment #115) > > Hi Leo, > > Hi Michael, > > > > > I just tested Fedora Workstation 44 Beta. Grub crashes with the out of > > memory error... > > > > Did the fix make it into release 44? > > I did not, we miss the merge window :( but it is now merged on rawhide now > (https://src.fedoraproject.org/rpms/grub2/c/ > 9fc30f762e2ff12d38b68cd02943b612389a5d8e?branch=rawhide) > > https://src.fedoraproject.org/rpms/grub2/commits/rawhide > > I was tempted to merge it but I decided to wait until fully tested through > the 'test day', so this also delay a bit but it was a safer approach. No OOM > reports since the merge so everything should be fine on this area starting > at fedora 45 > > BTW, We will backport the corresponding patch to 44 (and 43). > > Regards, > > > > > Best regards, > > > > Michael Tadault Hi Leo. Sorry if I'm misunderstanding your comment, but does that mean the fix will not make it into the final release ISO of 44? If so, this is a bit disappointing. If the fix is not in the official ISO, most people with this issue will remain unable of installing Fedora until 45. I'd appreciate any clarification. Thank you for your work on this. Regards,
> Hi Leo. > > Sorry if I'm misunderstanding your comment, but does that mean the fix will > not make it into the final release ISO of 44? Correct, it will not make it into 44, we missed the merge window basically. > > If so, this is a bit disappointing. If the fix is not in the official ISO, > most people with this issue will remain unable of installing Fedora until 45. Right, it will be ready starting at 45. > > I'd appreciate any clarification. Thank you for your work on this. > > Regards,
i participated (late) in the test day and posted my results. the fix works great for me so thanks! i did just read that it missed the merge window so will now only be available with fedora 45. for those of us that are impatient, is there any other alternative install method that bypass this bug? and what does it mean that the patch will be backported to 44 and 43 - will there be updated isos for those some time after the official release date that will contain the backported fix?
(In reply to Paul Pianta from comment #119) > i participated (late) in the test day and posted my results. the fix works > great for me so thanks! Thanks for participating, never too late for test day. > > i did just read that it missed the merge window so will now only be > available with fedora 45. for those of us that are impatient, is there any > other alternative install method that bypass this bug? not really unless you use temporally the image shared for test day but this is rawhide... > > and what does it mean that the patch will be backported to 44 and 43 yes and it has been backported to 44|43. - will > there be updated isos for those some time after the official release date > that will contain the backported fix? quoting my college pjones: Fedora generally does not re-spin install media; unless there's a major problem affecting a lot of machines, but we'd likely delay a release instead of that happening.
sorry for the question but how can we download a fedora 44 (or 43) iso that has the backported fix?
People, update the installation media if you have the fix. God knows how many people, incl. me, can't install Fedora right now...
(In reply to Paul Pianta from comment #121) > sorry for the question but how can we download a fedora 44 (or 43) iso that > has the backported fix? Unfortunately there are NO ISOs with the backported fix and there won't be: once a ISO is out, no re-spins are done. In case you are able to boot with current ISO (you are NOT impacted by this OOM issue), you can just update your GRUB the standard way.
(In reply to George from comment #122) > People, update the installation media if you have the fix. God knows how > many people, incl. me, can't install Fedora right now... Many people affected I believe, specially some particular motherboards (e.g. ASUS and others) as you can identify in the ~100 comments.
(In reply to Leo Sandoval from comment #124) > Many people affected I believe, specially some particular motherboards (e.g. > ASUS and others) as you can identify in the ~100 comments. So you're telling those people: - We know you can't install Fedora. - We know what causes the issue. - We've developed a fix. - You can't have the fix. - Tough luck. Get another distro...
As I've commented earlier, not having the fix on the yet to be released Fedora 44 is indeed quite disappointing and a big miss, as it means people will continue to have this issue until Fedora 45. Has a freeze exception been considered for this? If not, would it be possible to submit this as such? In any case, one alternative for those facing this problem is to use a live respin ISO, which I believe should already contain the fix. These are essentially updated ISOs built in the same way as the official ones. These ISOs can be download here: https://dl.fedoraproject.org/pub/alt/live-respins/
(In reply to Bruno from comment #126) > As I've commented earlier, not having the fix on the yet to be released > Fedora 44 is indeed quite disappointing and a big miss, as it means people > will continue to have this issue until Fedora 45. > > Has a freeze exception been considered for this? If not, would it be > possible to submit this as such? I am not quite familiar with exceptions, but let me query internally. > > In any case, one alternative for those facing this problem is to use a live > respin ISO, which I believe should already contain the fix. > These are > essentially updated ISOs built in the same way as the official ones. These > ISOs can be download here: https://dl.fedoraproject.org/pub/alt/live-respins/ I can confirm that at least F43-WORK-x86_64-LIVE-20260401.iso respin has the OOM fix so this is definitely a good approach. Thanks Bruno for pointing to these.
Just to confirm that i've been able to install fedora with F43-WORK-x86_64-LIVE-20260401.iso on the hardware that was not working before without any issue.
(In reply to matteo.combi from comment #128) > Just to confirm that i've been able to install fedora with > F43-WORK-x86_64-LIVE-20260401.iso on the hardware that was not working > before without any issue. Thanks Matteo. (Ready) Unfortunately, at the same time we are getting reports that the OOM fix regresses two apparently separate setups on f44 and f43 1 latest grub + grub theme + SB on is not booting https://bugzilla.redhat.com/show_bug.cgi?id=2451630 https://bugzilla.redhat.com/show_bug.cgi?id=2450672 2 unsigned kernel msg are now showing https://bugzilla.redhat.com/show_bug.cgi?id=2453022 I believe you are not being affected by 1 because you have no grub themes enabled, can you confirm? If you enable a theme, do you see any issue? Unfortunately I have not been able to reproduce the theme issue, so asking testers (you) to help with this.
I confirm, no grub themes enabled, secure boot enabled. I will try to check issues with themes Matteo