Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 2115202

Summary: update 2.06-45 breaks windows boot manager
Product: [Fedora] Fedora Reporter: The Source <thesource>
Component: grub2Assignee: Javier Martinez Canillas <fmartine>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 36CC: arthur, awilliam, bcostescu, belegdol, bugzilla, dalt74, dan, davidfox2116, dustymabe, fattony4, fmartine, frigo, gmarr, jlebon, kparal, linkboy321, lkundrak, marco.guazzone, Michael.Riss, musikplayr, naselli45, nicholas.stommel, nichstommel, pasik,, pjones, rharwood, robatino, samuel-rhbugs, scott.beamer, sustmidown, usdanskys, walters, xdevmails
Target Milestone: ---Keywords: Reopened
Target Release: ---Flags: davidfox2116: needinfo-
Hardware: x86_64   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: grub2-2.06-47.fc36 grub2-2.06-53.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-12 16:42:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 2009539    
Description Flags
screenshot of working debug=chain
screenshot of not working debug=chain
memory map when working
memory map when not working none

Description The Source 2022-08-04 06:19:15 UTC
Description of problem:
After an update from 2.06-42 to 2.06-45 I can no longer boot to Windows 11 from grub menu, only the black screen and nothing else. Fedora boots fine. Reverting to 2.06-42 solves the problem. Hardware: Dell G15 5510 laptop, efi.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 1 Peter Jones 2022-08-04 15:53:37 UTC
Sounds like a Windows bug?  What's going wrong?

Comment 2 The Source 2022-08-04 16:27:23 UTC
I have a chainloader in my grub menu: windows boot manager to boot windows 11. Grub.conf is created by grub2-mkconfig. In 2.06-42 selecting windows boot manager boots windows 11 just fine. But in 2.06-45 selecting that entry leads to black screen. The only escape from there is to reset or poweroff. Windows boots normally if selected from bios boot menu or like I said from grub menu with grub2 2.06-42. Only grub2 2.06-45 has trouble with it.

Comment 3 fattony4 2022-08-04 21:02:50 UTC
I experience the same thing: Since grub2-common-1:2.06-45.fc36.noarch, Windows doesn't start anymore.

Workaround: Use UEFI to directly start Windows instead of Linux/GRUB. (On my laptop: press F9 early on during boot to choose start medium.)

The workaround strongly suggests to me that it's a GRUB problem, not a Windows problem.

I tried reconfiguring GRUB with `grub2-mkconfig -o /boot/grub2/grub.cfg`:

[root]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...

Please tell me how I could generate useful information, I have no idea what else to do.

Comment 4 Scott Beamer 2022-08-05 05:31:44 UTC
I'm having the same problem after an update from a few days ago.  I've had to resort to booting my OS of choice from the UEFI boot menu.

Comment 5 Giuseppe Naselli 2022-08-05 06:42:23 UTC
I'm experiencing the same thing on my IdeaPad 330s-15IKB 81F5. I tried reconfiguring GRUB and disabling Secure Boot, but it didn't work. Selecting from UEFI boot menu works. Selecting Windows Boot Manager from GRUB leads to the Lenovo logo without loading anything. Only way to get out is rebooting. Really looks like a bug from the latest GRUB update. Dual booting Windows 11 and Fedora 36 Workstation.

Comment 6 Nicholas Stommel 2022-08-05 06:44:50 UTC
I also have this exact same problem on an HP Elitedesk 800 G3 Desktop Mini dual booting Fedora 36 and Windows 11 since this package was updated. This needs to be addressed ASAP. It is not a Windows problem or an issue with my computer. Booting Windows from GRUB works perfectly fine with the older package version.

Comment 7 Nicholas Stommel 2022-08-05 06:52:19 UTC
I should add that the console command /EndEntire is displayed on the top left corner of a black screen and the boot process is never initiated. Windows cannot boot from GRUB using the newer package.

Comment 8 Marco Guazzone 2022-08-05 08:08:00 UTC
Same problem here on a Lenovo P1 Gen3.
I solved this issue by downgrading GRUB2 to version 2.06-42.

Comment 9 Steven Usdansky 2022-08-05 11:30:19 UTC
Related comment. I'm running GRUB2 version 2.06-46.fc37. When booting Wndows 10 from the GRUB menu, I see the black screen with /EndEntire, but that screen disappears after a few seconds and Windows 10 boots normally. HP EliteDesk 800 G2 Mini

Comment 10 linkboy321 2022-08-05 13:16:09 UTC
I ran into the issue yesterday on my ThinkPad P50.

It totally broke my Windows install. Even if I booted from my UEFI menu instead of GRUB, Windows would just load to its Automatic Repair option and fail to boot.

Ended up having to reinstall both Fedora and Windows to get both OS's to boot again.

Comment 11 The Source 2022-08-05 13:22:11 UTC
Windows goes to automatic repair because of previous failed boot. My system does that too, but just cancel repair, press additional options and select to continue to boot windows. Your system will restart, remember to boot from UEFI menu after that.

Comment 12 Colin Walters 2022-08-05 17:35:42 UTC
Not entirely sure it's related to this BZ specifically, but since this one is about regressions from the new grub;
it's entirely broken Fedora CoreOS:

Comment 13 François Rigault 2022-08-05 20:17:50 UTC
Fedora CoreOS tests runs in VMs with 512MB RAM I recall. I can reproduce that issue with a qemu VM with 512MB RAM. It fails when "Trying to allocate kernel mem" (I can't be certain it's related to this BZ either)

Comment 14 Dusty Mabe 2022-08-06 02:12:25 UTC
The CI for Fedora CoreOS defaults to VMs with 1G of RAM.

Comment 15 François Rigault 2022-08-06 03:01:47 UTC
oh really. I have a rawhide VM that upgraded just fine, however if I reduce the memory of the VM it fails (reducing to 800MiB it still works, reducing to 700MiB or below it fails, reproducing the same error seen in the CoreOS build).

Comment 16 François Rigault 2022-08-06 09:15:36 UTC
out of curiosity, I made a build without the 

and this fixes the issue on my VM (it works fine again with 512MB memory).
Also this could be related

Comment 17 fattony4 2022-08-06 09:32:50 UTC
It fixes the problem on my system!

The command to update to your build was:

sudo dnf update

Is there a better way of applying koji patches?

Comment 18 Scott Beamer 2022-08-06 15:28:47 UTC
We seem to be deviating from the original report here.  The problem has nothing to do with VMs.  The problem that GRUB won't boot Windows anymore.

Comment 19 Miroslav Šustek 2022-08-06 18:47:05 UTC
I can confirm a similar behaviour as comment on my Lenovo Ideapad S740-15IRH (16 GB of RAM).
After updating to GRUB 2.06-45 I can no longer boot Windows 10 through GRUB. I get stuck on Lenovo boot logo without any loading animation.

The only to boot into Windows it to use the UEFI boot menu using F12 key when turning on my laptop.

Downgrading to grub2-2.06-42.fc36 or grub2-2.06-43.fc37 ( ) fixes the problem.

Also, I can confirm that the build without the 0271-efi-make-the-default-arena-most-of-ram.patch ( ) fixes the problem too.

Comment 20 Miroslav Šustek 2022-08-06 18:56:42 UTC
Just in case it helps, the GRUB menu entry looks like this:

menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1234-5678' {
        insmod part_gpt
        insmod fat
        search --no-floppy --fs-uuid --set=root 1234-5678
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi

Comment 21 Daniel Drake 2022-08-08 02:51:03 UTC
I hit this issue too via regular F36 updates, using chainload to another grub EFI binary.

The chainloaded grub instance fails to then boot Linux, with error message:
   error: can't allocate kernel.

Version 2.06-43 is OK
Version 2.06-44 fails

Looking at grub-core/kern/efi/mm.c code affected by 0271-efi-make-the-default-arena-most-of-ram.patch, the 3/4 RAM memory allocation is created with b->allocate_pages, and there is no corresponding call to b->free_pages that I can see. Or is that intentional because we'd be freeing the allocation used for the kernel (or chainloaded binary) that we're going to execute?

Comment 22 Jason Elwell 2022-08-08 03:17:58 UTC
François' koji packages work perfectly.  Thank you!  And, thanks to fattony4 for the copy/paste command.

I had to disable secure boot checking.  I'm assuming the mainstream Fedora stuffs are signed and these may not be.  I'll reenable in the fullness of time.

Our 2 different Dell G5 laptops suffered from the problem, but our Dell G3 3579 did not, for whatever reason.  All firmware should be up to date on them, if that is of any importance.

Comment 23 Kamil Páral 2022-08-08 12:36:57 UTC
Proposing as a Prioritized bug and a CommonBug.

Comment 24 Kamil Páral 2022-08-08 12:39:22 UTC
Also a blocker for F37:

Comment 25 Fedora Update System 2022-08-08 16:49:18 UTC
FEDORA-2022-d0c322d15a has been submitted as an update to Fedora 36.

Comment 26 Robbie Harwood 2022-08-08 20:30:01 UTC
*** Bug 2116032 has been marked as a duplicate of this bug. ***

Comment 27 Fedora Update System 2022-08-09 02:52:38 UTC
FEDORA-2022-d0c322d15a has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-d0c322d15a`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 28 Scott Beamer 2022-08-09 13:55:56 UTC
(In reply to Fedora Update System from comment #27)
> FEDORA-2022-d0c322d15a has been pushed to the Fedora 36 testing repository.
> Soon you'll be able to install the update with the following command:
> `sudo dnf upgrade --enablerepo=updates-testing --refresh
> --advisory=FEDORA-2022-d0c322d15a`
> You can provide feedback for this update here:
> See also for more
> information on how to test updates.

And I just updated.  And it indeed fixed the bug! Yay! Thank you, @rharwood!

Comment 29 The Source 2022-08-09 14:17:45 UTC
Update works. Both Fedora 36 and Windows 11 boot fine.

Comment 30 Fedora Update System 2022-08-10 01:16:44 UTC
FEDORA-2022-d0c322d15a has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 31 Fedora Update System 2022-08-10 09:43:16 UTC
FEDORA-2022-be17145ba6 has been submitted as an update to Fedora 38.

Comment 32 Fedora Update System 2022-08-10 09:45:31 UTC
FEDORA-2022-be17145ba6 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 33 Arthur Bols 2022-08-10 09:48:24 UTC
Sorry, messed up the bug number. Please ignore the above comments.

Comment 34 Johnny Arcitec 2022-08-11 01:41:37 UTC

Comment 35 Johnny Arcitec 2022-08-11 01:43:29 UTC
Patch looks good to me, but the code comment is now out of date and still refers to reserving "3/4ths" of available RAM:

+    /* By default, request three quarters of the available memory.  */
+    total_pages = get_total_pages (filtered_memory_map, desc_size,
+                   filtered_memory_map_end);
+ -  required_pages = (total_pages >> 1) + (total_pages >> 2);
+ +  required_pages = (total_pages >> 1); 

Comment 36 Miroslav Šustek 2022-08-16 08:54:20 UTC
I upgraded to version 2.06-47.fc36 and it did not fix the problem for me.

I wonder what could be the difference with my system. Since this problem is connected with memory allocation, I guess it may be caused by the fact that I have 16 GB of RAM.
Does anyone else have 16 GB (or more) RAM and did this fix solved the problem for you?

Note that the Koji build without the 0271-efi-make-the-default-arena-most-of-ram.patch ( ) worked on my system.

Comment 37 Kamil Páral 2022-08-16 09:17:56 UTC
Reopening per comment 36.

Miroslav, I have 24 GB RAM and grub2-efi-x64-2.06-47.fc36.x86_64 works fine for me, I can boot into Windows when running in UEFI-only mode. (However, I don't know if the previous version was broken on this particular system, I didn't try it at that time).

Comment 38 Chris Murphy 2022-08-16 14:04:32 UTC
>I upgraded to version 2.06-47.fc36 and it did not fix the problem for me.

I have 16G RAM and grub2-efi-x64-2.06-47.fc36.x86_64, and it's booting Windows 10 OK. 

Unless Robbie Harwood has another suggestion - I suggest enabling debugging on the chainloader module, it might help him figure out what's going wrong. Edit /boot/grub2/grub.cfg, find the Windows section, add this line after 'insmod fat' and before the chainloader line.


You'll probably get many pages of verbose debug info, since pager=1 by default you'll get a pause, press space bar to get to the next page, you can either take video or photos with a cell phone, but it's... tedious.

Comment 39 Geoffrey Marr 2022-08-22 21:25:39 UTC
Discussed during the 2022-08-22 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."


Comment 40 Ben Cotton 2022-08-24 15:33:12 UTC
Removing the Prioritized Bugs flag as this is an accepted F37 Final blocker:

Comment 41 David Fox 2022-08-24 23:46:55 UTC
grub2-2.06-47.fc36 didn’t fix the problem for me either.

I’m running Fedora 36 / Win 11 on a
Dell XPS 13 9300
8GB Ram

ran “dnf downgrade grub2”

and I was downgraded to grub2-2.06-29.fc36.   I was able to dual-boot again.

Comment 42 Robbie Harwood 2022-08-25 15:06:06 UTC
So same question for you then.

Comment 43 Chris Murphy 2022-08-25 18:16:54 UTC
Specifically the task in comment 38 (I'm guessing?)

Comment 44 Miroslav Šustek 2022-08-29 22:52:01 UTC
I use Windows mainly for playing games for which I did not have time lately. Sorry for not responding earlier.

I used `debug=chain` (`debug=chainloader` did not work) and captured the output. I do not see much difference except of the addresses.

Comment 45 Miroslav Šustek 2022-08-29 22:52:46 UTC
Created attachment 1908410 [details]
screenshot of working debug=chain

Comment 46 Miroslav Šustek 2022-08-29 22:53:17 UTC
Created attachment 1908411 [details]
screenshot of not working debug=chain

Comment 47 Miroslav Šustek 2022-08-29 23:25:35 UTC
When the chainloader to Windows works the entrypoint address is: 0x24b1bcb0 (ie. ~587 MiB) 
and when it does not work the entrypoint address is: 0x1b8e8cb0 (ie. ~441 MiB).

It's interesting that there is so little difference in the addresses when once it allocates 1/4 of the memory and the other time 3/4.

It's only a wild guess but I wonder whether there can be a problem when the chainloader uses addresses under 512 MiB.

Comment 48 Miroslav Šustek 2022-08-30 01:43:26 UTC
I also tried to enable this memory map printing: if it helps anyhow.

Comment 49 Miroslav Šustek 2022-08-30 01:46:24 UTC
Created attachment 1908426 [details]
memory map when working

Comment 50 Miroslav Šustek 2022-08-30 01:47:08 UTC
Created attachment 1908428 [details]
memory map when not working

Comment 51 Miroslav Šustek 2022-08-30 02:02:25 UTC
To clarify:
- "screenshot of working debug=chain" is done with GRUB v2.06-42 (ie. 1/4 allocation)
- "screenshot of not working debug=chain" is done with GRUB v2.06-47 (ie. 1/2 allocation)
- "memory map when working" is done with v2.06-47 patched to allocate 1/4 of memory
- "memory map when not working" is done with v2.06-47 allocating 1/2 of memory

Comment 52 Bogdan Costescu 2022-09-02 22:43:06 UTC
I still have the same problem with the current version grub2 v2.06-52. Due to holiday, I skipped the previous -45 or -47 packages mentioned above. The solution with 'dnf downgrade grub2-efi' worked for me too, bringing the version to 2.06-29.

The laptop (Dell XPS 13 7390 with 16GB RAM and latest BIOS 1.17) runs Fedora 36 and Windows 10.

Comment 53 Nicholas Stommel 2022-09-07 00:38:50 UTC
This is also still a problem on my Lenovo Ideapad S740 15-IRH with 16GB of RAM and latest BIOS. I cannot boot Windows 10 from the GRUB boot menu after updating Fedora 36 (I haven't used this machine in a while, so only caught this bug now.) Downgrading the package fixes the problem, but this is only a temporary failsafe at this point. I don't really understand why the bug is still happening after the supposed fix. I suggest simply reverting whatever behavior code broke the Windows chainloader in the first place. This problem is serious, urgent, and frankly unacceptable, as it affects a variety of machines from different manufacturers and prevents critical booting functionality.

Comment 54 Fedora Update System 2022-09-08 00:12:31 UTC
FEDORA-2022-c96e000a12 has been submitted as an update to Fedora 36.

Comment 55 Fedora Update System 2022-09-08 12:09:21 UTC
FEDORA-2022-c96e000a12 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-c96e000a12`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 56 Fedora Update System 2022-09-10 20:51:17 UTC
FEDORA-2022-c96e000a12 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 57 Kamil Páral 2022-09-12 07:41:54 UTC
Since this was an accepted blocker, we'll want verification before we close this.

Nicholas, Bogdan, Miroslav, David - Can you please tell us whether grub2-2.06-53.fc36 fixes the windows bootloader issue for you? Thanks!

Comment 58 Bogdan Costescu 2022-09-12 12:41:51 UTC
I can confirm that 2.06-53 fixes the problem on F36 for booting Windows 10 with my setup (as in comment #52). I'm not checking 'clear all needinfo requests' as there seemed to be several differences in the other reports.

Thanks everybody for your work on this!

Comment 59 David Fox 2022-09-12 13:10:42 UTC
I can confirm that 2.06.53 now allows F36 and Windows 11 to boot on my setup (see comment #41). 


Comment 60 Adam Williamson 2022-09-12 16:42:40 UTC
OK, we have confirmation, closing again.

Comment 61 Nicholas Stommel 2022-09-12 17:34:43 UTC
I can also confirm that 2.06-53 fixes the boot problem and allows GRUB to boot Windows 10/11 on my Lenovo laptop with Fedora 36 installed. Thank you for fixing this problem.

Comment 62 Red Hat Bugzilla 2023-09-15 01:57:10 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days