running tests from: https://fedoraproject.org/wiki/Test_Day:2025-12-15_GRUB_out_of_memory_verification Loaded fedora via Media Writer onto USB. Booted to USB on laptop (Lenovo ThinkPad T440), and brought to grub terminal. Tested writing ISO to USB using Media Writer twice and results are the same To note that existing laptop OS (on SSD) is Fedora 43 Workstation Reproducible: Always Steps to Reproduce: 1. write liveimage (https://fedorapeople.org/groups/qa/test_days/05673235-Fedora-Workstation-Live-x86_64-139891207.iso) to USB using Fedora Media Writer 2. boot PC from USB 3. Actual Results: Boots to grub terminal Expected Results: Boot to Fedora
Thanks for reporting it. This is definitely something not expected nor desired. We ask you the following 1. On that machine, on a running system can you do 'lshw -short' place log here 2. Boot with the iso, on the grub terminal, type 'grub2-editenv - set debug=all,-lexer,-scripting' and go to the grub menu again and try booting fedora again. it is hard to copy and paste log but if possible take pics, specially on log's tail and attach these. 3. try this iso instead https://people.redhat.com/lsandova/oom/boot-max.iso which is no longer a LIVE iso image but an anaconda one containing exactly the same fix. We want to make sure both isos behave the same.
Also, for the point 1 above (lshw -short), please update (if not done yet) also this page. https://testdays.fedoraproject.org/testday/11
(In reply to Leo Sandoval from comment #1) > Thanks for reporting it. > > This is definitely something not expected nor desired. We ask you the > following > > 1. On that machine, on a running system can you do 'lshw -short' place log > here > 2. Boot with the iso, on the grub terminal, type 'grub2-editenv - set > debug=all,-lexer,-scripting' and go to the grub menu again and try booting > fedora again. it is hard to copy and paste log but if possible take pics, > specially on log's tail and attach these. the above point is not quite accurate, these are the correct instructions (thanks to Nico F.) - press 'c' at the boot menu - add the line "set debug=all,-lexer,-scripting" then press Ctrl+x to boot then share the logs. > 3. try this iso instead https://people.redhat.com/lsandova/oom/boot-max.iso > which is no longer a LIVE iso image but an anaconda one containing exactly > the same fix. We want to make sure both isos behave the same.
Created attachment 2119066 [details] T440_lshw
Created attachment 2119067 [details] T450_lshw
Thanks for sharing the update. In an effort to be more thorough, I have tested this flow on two machines: the existing Lenovo T440, and a Lenovo T450 (spare machines used for testing). Both have their `lshw -short` outputs attached, from within Fedora 43 Sway Spin. I have used the original `.iso`, https://fedorapeople.org/groups/qa/test_days/05673235-Fedora-Workstation-Live-x86_64-139891207.iso, as well as the one you suggested (`boot-max.iso`), burned onto the USB with Fedora Media Writer. The original `.iso`, after selecting the USB device in BIOS, boots straight into a grub terminal on both machines. The suggested `.iso`, after selecting the USB device in BIOS, boots straight into a grub terminal on both machines. I may have a failed USB drive, so have tried another. On this one, using the original `.iso`, both machines boot straight to the grub terminal. Using the suggested `boot-max.iso`, both machines boot straight to the grub terminal. Could this issue be with Fedora Media Writer? Shall I instead try `dd` for the `.iso` transfer to USB?
(In reply to paolojr from comment #6) > Thanks for sharing the update. > > In an effort to be more thorough, I have tested this flow on two machines: > the existing Lenovo T440, and a Lenovo T450 (spare machines used for > testing). Both have their `lshw -short` outputs attached, from within Fedora > 43 Sway Spin. > > I have used the original `.iso`, > https://fedorapeople.org/groups/qa/test_days/05673235-Fedora-Workstation- > Live-x86_64-139891207.iso, as well as the one you suggested > (`boot-max.iso`), burned onto the USB with Fedora Media Writer. > > The original `.iso`, after selecting the USB device in BIOS, boots straight > into a grub terminal on both machines. > > The suggested `.iso`, after selecting the USB device in BIOS, boots straight > into a grub terminal on both machines. > > I may have a failed USB drive, so have tried another. > > On this one, using the original `.iso`, both machines boot straight to the > grub terminal. > > Using the suggested `boot-max.iso`, both machines boot straight to the grub > terminal. > > Could this issue be with Fedora Media Writer? Shall I instead try `dd` for > the `.iso` transfer to USB? yes, give it a try please. if you get the same results (grub terminal instead of fedora live OS), then we should get the grub logs as indicated before. Also, please provide a checksum (md5sum or shasum) of the original iso.
Created attachment 2119179 [details] original iso shasums
Created attachment 2119180 [details] boot-max shasums
Created attachment 2119181 [details] dd output
Created attachment 2119182 [details] bios screen
Created attachment 2119183 [details] grub available commands
Created attachment 2119184 [details] grub debug commands
(In reply to paolojr from comment #8) > Created attachment 2119179 [details] > original iso shasums these match with the ones I have, so sums are fine.
(In reply to paolojr from comment #13) > Created attachment 2119184 [details] > grub debug commands remove double quotes
okay. got to test both iso's on the T450. For the `shasum`, please see attached files for both `sha1` and `sha256` in their respective `.txt` files. For the grub terminal, I wrote "set debug=all,-lexer,-scripting" and hit `enter`. What should I do afterward? I have attached some photos of the experience from the BIOS screen that goes straight to the grub terminal (not the grub menu) and available commands from there. Also attached an image of the `dd` process for the related USB drive (/dev/sdb) when using the `boot-max.iso` for reference
(In reply to paolojr from comment #16) > okay. got to test both iso's on the T450. > > For the `shasum`, please see attached files for both `sha1` and `sha256` in > their respective `.txt` files. all looks fine, so no iso corrupted from your end. > > For the grub terminal, I wrote "set debug=all,-lexer,-scripting" and hit > `enter`. What should I do afterward? remove the quotes from the command, then hit enter and then Ctrl+x to boot I have attached some photos of the > experience from the BIOS screen that goes straight to the grub terminal (not > the grub menu) and available commands from there. right, this is not good. iso should bring you to the grub menu, where you can 'test & start fedora' or just 'start fedora' > > Also attached an image of the `dd` process for the related USB drive > (/dev/sdb) when using the `boot-max.iso` for reference nice, looks good the sdb partitions after dd.
indeed, the grub menu does not appear. i have removed the double quotes, hit enter. The tricky part is that `Ctrl-x`, and many other variations like: `Ctrl-Shift-x`, `Ctrl-Shift-Fn-x`, `Ctrl-Shift-Fn-F10` etc., does not boot to Fedora. The grub terminal remains
(In reply to paolojr from comment #18) > indeed, the grub menu does not appear. > > i have removed the double quotes, hit enter. > > The tricky part is that `Ctrl-x`, and many other variations like: > `Ctrl-Shift-x`, `Ctrl-Shift-Fn-x`, `Ctrl-Shift-Fn-F10` etc., does not boot > to Fedora. The grub terminal remains I see, so once you set debug="debug,-lexer,-scripting", hit ESC key and then try boot.
Created attachment 2119265 [details] grub terminal outputs
in still using the `boot-max.iso` and from the grub terminal on the Lenovo T450: entered `set debug=all,-lexer,-scripting`, hit ESC to get a new grub prompt attempted to check for the kernel to boot from, but either device (hd0 or hd1) shows "unknown filesystem" the `boot` command requires a kernel file to boot from right? see attached image for reference of these commands being executed
(In reply to paolojr from comment #21) > in still using the `boot-max.iso` and from the grub terminal on the Lenovo > T450: > entered `set debug=all,-lexer,-scripting`, hit ESC to get a new grub prompt just to be clear on this point: once you hit ESC, you do not see the grub menu? > attempted to check for the kernel to boot from, but either device (hd0 or > hd1) shows "unknown filesystem" > the `boot` command requires a kernel file to boot from right? right. It is linux followed by a initrd cmd. I will attach a pic. > see attached image for reference of these commands being executed
Created attachment 2119323 [details] GRUB cmds shown when editing the 'Start Fedora' menu entry
(In reply to Leo Sandoval from comment #23) > (In reply to paolojr from comment #21) > > in still using the `boot-max.iso` and from the grub terminal on the Lenovo > > T450: > > entered `set debug=all,-lexer,-scripting`, hit ESC to get a new grub prompt > > just to be clear on this point: once you hit ESC, you do not see the grub > menu? exactly. After clicking ESC (or ENTER), another grub terminal prompt appears, not the grub menu (to boot to Fedora) > > > attempted to check for the kernel to boot from, but either device (hd0 or > > hd1) shows "unknown filesystem" > > the `boot` command requires a kernel file to boot from right? > > right. It is linux followed by a initrd cmd. I will attach a pic. > > > see attached image for reference of these commands being executed after logging in via FAS, i cannot see the image ("...not authorized to access attachment").
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