Description of problem: After the last roll of upgrade to F24 Alpha, right after booting kernel 4.5.0, grub is showing "error: out of memory\npress any key to continue" Additionally, it cannot boot Windows 10 anymore. It shows the following error and returns to the Grub menu: error: out of memory /EndEntire file path: /ACPI(a0341d0,0)/PCI(2,1f)/Sata(0,0,0)/HD(1,800,64000,5a7fdbc874374d43,2,2)/File(\EFI\Microsoft) Press any key to continue... Version-Release number of selected component (if applicable): kernel 4.5.0-0.rc7.git0.2.fc24.x86_64 grub2.x86_64 1:2.02-0.26.fc24 grub2-efi.x86_64 1:2.02-0.26.fc24 grub2-tools.x86_64 1:2.02-0.26.fc24 How reproducible: It happens every time I reboot the machine now. Cannot boot into Windows anymore. Steps to Reproduce: 1. Update to F24 Alpha as of 2016-03-22 2. Reboot Actual results: Shows out of memory error, fails to boot Windows. Shows out of memory error, boots Linux after pressing any key. Expected results: No error. Additional info:
While trying to reinstall GRUB, this error shows up: # grub2-install /dev/sda grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory. # rpm -ql grub2 | grep modinfo /usr/lib/grub/i386-pc/modinfo.sh # rpm -qa |grep grub grubby-8.40-3.fc24.x86_64 grub2-tools-2.02-0.26.fc24.x86_64 grub2-2.02-0.26.fc24.x86_64 grub2-efi-2.02-0.26.fc24.x86_64
installing grub2-efi-modules and reinstall grub did not help.
*** Bug 1321923 has been marked as a duplicate of this bug. ***
Are there any workarounds for this? This is really a critical bug for people with dual-boot systems.
(In reply to Nirbheek Chauhan from comment #4) > Are there any workarounds for this? This is really a critical bug for people > with dual-boot systems. Downgrading grub2-efi and gub2-tools to version 2.02-0.25.fc23 from rawhide should do the trick.
I am affected by this bug too on a Surface Pro 3. Downgrading with: dnf downgrade grub2-efi grub2-tools --releasever 23 --allowerase effectively allows you to boot Windows 10.
Issue was fixed by last update (grub2-2.02-0.28.fc24.x86_64).
(In reply to Giovanni Tirloni from comment #7) > Issue was fixed by last update (grub2-2.02-0.28.fc24.x86_64). Nope. The patch didn't change anything on my machine...
Sorry, you are correct. My test was incomplete. I'm getting a different behavior while booting Linux: right after turning the laptop on, it will show the out of memory error. In a subsequent reboot, the error is gone. Unfortunately, it still shows the same out of memory error while trying to boot Win10.
Proposed as a Blocker for 24-final by Fedora user astero using the blocker tracking app because: The current fedora 24 version of grub2-efi fails to pass the 'Windows dual boot' test case (installer requirement). Selecting the windows 10 boot entry results in a 'out of memory' error.
Please try grub2-2.02-0.30.fc24 in updates-testing. On UEFI computers, don't use grub2-install. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8aec1d3a5
(In reply to Chris Murphy from comment #11) > Please try grub2-2.02-0.30.fc24 in updates-testing. On UEFI computers, don't > use grub2-install. > https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8aec1d3a5 Still got the same problem.
Same here, it doesn't work. Here's my Grub2 menu entry for Win10 and the loader it's trying to use: ccf63a9c02e8ee8835c65c73315883fc /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi ### BEGIN /etc/grub.d/30_os-prober ### menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-2E05-A3F5' { insmod part_gpt insmod fat set root='hd0,gpt1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 2E05-A3F5 else search --no-floppy --fs-uuid --set=root 2E05-A3F5 fi chainloader /EFI/Microsoft/Boot/bootmgfw.efi } ### END /etc/grub.d/30_os-prober ###
Who would like to try to rebuild ommitting this? http://pkgs.fedoraproject.org/cgit/rpms/grub2.git/diff/0072-Add-secureboot-support-on-efi-chainloader.patch?id=d9747d852b37dcf22f3161669b27878ebc1485a7 If this is the cause, Secure Boot users will get some other error message about being unable to load the image.
Discussed at today's blocker review meeting [1]. Voted as AcceptedBlocker (Final) - this seems like a clear violation of "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." in the case of a UEFI windows install [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-04-11/
(In reply to Chris Murphy from comment #14) > Who would like to try to rebuild ommitting this? > http://pkgs.fedoraproject.org/cgit/rpms/grub2.git/diff/0072-Add-secureboot- > support-on-efi-chainloader.patch?id=d9747d852b37dcf22f3161669b27878ebc1485a7 > > If this is the cause, Secure Boot users will get some other error message > about being unable to load the image. I'd like to try it out without the secureboot patch. But I don't know how I can do that. Removing the entry from the grub.patches file leads to build errors...
Ok. Here's what I did: After removing all patches from 0070-Add-secureboot-support-on-efi-chainloader.patch on (expect 0083-Make-grub-editenv-build-again.patch, because its required for a successfull build) I was able to boot windows. Next I applied 0070-Add-secureboot-support-on-efi-chainloader.patch again and got the 'out of memory' error. So your assumption that the secureboot patch is the problem seems to be correct. Also I changed the two lines grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory")); to if (efi_status != GRUB_EFI_SUCCESS) { grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory1")); goto error_exit; } and if (!buffer_aligned) { grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory2")); goto error_exit; } What I got was 'out of memory2'. Hope you can do something with that information...
Created attachment 1146949 [details] photo of out of memory, debug=all I can reproduce the out of memory message with grub2-2.02-0.30.fc24 chainloader pointed to bootmgr.efi found on a Windows 10 install media that boots OK directly from the firmware boot manager. Attaching photo of output from grub boot command with debug=all.
NUC5PPYB, BIOS PYBSWCEL.86A.0050.2016.0223.1234 02/23/2016 This happens whether or not Secure Boot is enabled.
Still happens with latest grub 02-0.30.fc24 package
Happens to me also.
Happened to me, but not on my initial upgrade to F24 Alpha. Immediately after the upgrade, I could boot to Windows 10 by turning Secure Boot off (previously not required). I attempted to fix the Secure Boot problem by resetting grub, and then this problem appeared.
(In reply to Nirbheek Chauhan from comment #4) > Are there any workarounds for this? This is really a critical bug for people > with dual-boot systems. I found one very simple workaround that works(around) for me (until this gets fixed): 1) Hit 'c' at the grub prompt to enter command line. 2) Enter 'exit'. My system then boots to windows. This probably doesn't work for everyone, but if you're in a pinch, try it.
(In reply to K from comment #23) > > I found one very simple workaround that works(around) for me (until this > gets fixed): > > 1) Hit 'c' at the grub prompt to enter command line. > 2) Enter 'exit'. > > My system then boots to windows. > > This probably doesn't work for everyone, but if you're in a pinch, try it. What that effectively do is tell the UEFI boot manager from the frimware of your MOBO to boot the next entry in the boot list; you can use the boot manager to begin with to select the other OS from the get-go.
[root@f23s 0]# dd if=bootmgr.efi count=2 2>/dev/null | hexdump -C https://paste.fedoraproject.org/364375/
I am affected by this bug, too. Upgraded from Fedora 23 to 24 Beta. Now I cannot use grub to boot into windows, I get the "out of memory" error. My system does not use secureboot.
Is there any progress on this bug? The problem is now known for nearly 2 months and the Status is still 'NEW'. Wouldn't a potential patch need some weeks for testing before it can be released together with Fedora 24? Ofc you could take the easy way and just revert the secure boot patch. I guess this would mean that bug 1170245 will be in Fedora for another year though.
I am also using F24 Beta. I just discovered this today since I rarely boot Windows. $ rpm -q grub2 grub2-2.02-0.30.fc24.x86_64
<pjones> it's on [my radar] in that I'm aware of its existence <pjones> and, you know, time to debug it someday would be really nice
The workaround in Comment #23 works for me, but I'm a big confused by one aspect. Prior to installing Fedora 24 Beta, I had installed Centos 7 on my laptop. When I exit from the Fedora grub menu, it takes me into the previous grub menu installed by CentOS. Is that normal and expected? Why doesn't Fedora overwrite the CentOS grub config instead of chaining to it?
There's no 'chaining' happening there, exactly, they're just two different UEFI boot loader entries, one for Fedora, one for CentOS. They don't overwrite each other's. This is expected.
(In reply to Adam Williamson from comment #31) > There's no 'chaining' happening there, exactly, they're just two different > UEFI boot loader entries, one for Fedora, one for CentOS. They don't > overwrite each other's. This is expected. Whether it's chainloading or not is irrelevant from a user's perspective. With Fedora 23, it worked correctly. You install Fedora onto an existing Windows installation and get a menu entry to boot windows in Grub, which succeeds. With F24, you get a "out of memory" error. The normal user is stuck there. Even though this might be expected from a develepors point of view, it is certainly not expected from a users point of view (and is a change in behaviour btw). It would certainly do no good for Fedoras reputation if Dual Boot installation would render the inexperienced user unable to boot his Windows OS.
(In reply to Adam Williamson from comment #31) > There's no 'chaining' happening there, exactly, they're just two different > UEFI boot loader entries, one for Fedora, one for CentOS. They don't > overwrite each other's. This is expected. I don't know much about UEFI, so this may be a stupid question, but why does Fedora need a separate boot loader entry? They're both using grub and capable of booting each other. When Fedora creates it's boot loader entry, it provides menu items for CentOS. So why can't it just overwrite the CentOS boot loader entry? Perhaps my question makes no sense in the UEFI context; I apologize if so. Given the way it works now, does this mean that a new boot loader entry will be created every time I install a new version of Fedora or CentOS? If so, is there any limit on the number of boot loader entries? Is there a danger of hitting a limit? Thanks, Andy
thomas: I was replying to Andrew Schorr's comment, not commenting on the bug itself. As this is off-topic I'm not going to reply to it any further than this: "Given the way it works now, does this mean that a new boot loader entry will be created every time I install a new version of Fedora or CentOS?" No. There is one entry called 'Fedora'. Each time you install Fedora it overwrites this entry. I believe CentOS and RHEL do the same, though I don't know in as much detail.
Under BIOS there is at most one boot loader per disk. You either have Fedora or Ubuntu or CentOS or Windows. If you want to have two, enter the realm of hacks where two Linux distros need to know about each other and neither has full control over grub's config (or they would effectively wipe each other's entries out with each kernel upgrade). Under UEFI there are many boot loaders per machine. Each operating system provides its own boot loader and UEFI can either show you a menu of all possible options in order of preference (configured in UEFI's setup utility): 1. Fedora Workstation 24 2. CentOS 6 3. Windows 10 ...or they are run in sequence starting from the preferred one. This is why when you install multiple operating systems you end up with multiple entries as Fedora only controls `\EFI\fedora` and CentOS controls `\EFI\centos`. Operating systems don't know about each other and they are not supposed to. The fact that both Fedora and CentOS use grub is an implementation detail as they have two separate versions of grub and they control them in their entirety. None of this is in any way related to this bug.
"Operating systems don't know about each other and they are not supposed to...None of this is in any way related to this bug." Sadly, it's not quite that simple in practice, and thus it *is* related to this bug. In an 'ideal UEFI world', indeed, each OS's bootloader could just care about booting that OS, and trust that the firmware made it easy for the user to pick their OS. Unfortunately, in the real world, no-one understands this system and firmwares are terrible at surfacing it, so we *can't* have Fedora's bootloader only boot Fedora, we have to try and make it capable of booting Windows too. Only that's broken, which is what this bug is about. If firmwares made the EFI boot manager-level choice between "Fedora's bootloader" and "Windows' bootloader" easy, we wouldn't have to bother with this stuff at all. To summarize, life sucks. But yes, you're broadly correct.
(In reply to Adam Williamson from comment #34) > thomas: I was replying to Andrew Schorr's comment, not commenting on the bug > itself. Oh, didn't catch that. Please accept my applogies then for the misunderstanding.
for me is: -1 blocker
gil: this bug is already accepted as a blocker, it does not require votes. thanks!
I will note I am getting a grub2 error but it is not 'Out of memory'. It is 'no shim lock protocol' it still boots Linux however. For Windows 10 booting it fails outright: error: no shim lock protocol /EndEntire file path: /ACPI/(hexvalue)/HardwareVendor/ .. Microsoft/Boot/efi </EndEntre> I have to rollback to an older grub2 to fix. The Dell BIOS I have allows me to skip grub bootloader and boot via its boot list from UEFI.
grub2-2.02-0.33.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc
The above posting I created is now a different bug #1344512 it is unrelated to this it appears.
Can anyone please test the update and check whether it fixes the problem reported in this bug? Thanks!
@ Shawn, I have seen same on my inspiron will test to confirm its good with patch @Adam, testing both with and without SB as requested in -qa (IRC) results likely via feodar-easy-karma later tonight
Corey: the update listed in #c41 - 0.33.fc24 - is not intended/expected to fix Shawn's error. It's intended/expected to fix the "out of memory" error reported in this bug. Please don't -1 it for not fixing Shawn's bug. Shawn's bug is a different bug, which is why he's reported it separately. Peter thinks he knows the cause and is working on it, a subsequent update to fix it will hopefully be available soon.
Works as expected on a secureboot enabled Dual boot with Win 10 / Fedora 24, While UEFI+CSM also booted Windows 10 I could not get Fedora 24 (while in secureboot disabled mode) to boot however in UEFI+CSM, however no errors so I think this is due to no fallback setup in Fedora install.
Maybe I am a bit dumb, but how do I get the updated version? I tried to update using dnf with updates-testing repo enable, but the latest version of grub I see is 2.02.0.30.fc24.
The update works with and without secure boot. Thank you!
(In reply to thomas.michel from comment #47) > Maybe I am a bit dumb, but how do I get the updated version? I tried to > update using dnf with updates-testing repo enable, but the latest version of > grub I see is 2.02.0.30.fc24. Follow the direct link (http://koji.fedoraproject.org/koji/buildinfo?buildID=771757) and use something like 'sudo dnf upgrade https://kojipkgs.fedoraproject.org//packages/grub2/2.02/0.33.fc24/x86_64/grub2-2.02-0.33.fc24.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/grub2/2.02/0.33.fc24/x86_64/grub2-efi-2.02-0.33.fc24.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/grub2/2.02/0.33.fc24/x86_64/grub2-efi-modules-2.02-0.33.fc24.x86_64.rpm'
grub2-2.02-0.33.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc
grub2-2.02-0.34.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc
Hi, can confirm all the bug is fixed with grub2-2.02-0.33.fc24.
Can folks please test and make sure 0.34 is good also? It should be, but it'd be good to have confirmation. I'd like to include that in Final as it has several other fixes pjones found.
Hi, can confirm version 0.34 works as well.
Hi! Also i can confirm version 0.34 fixes my issues on booting Win10. Thanks for your works!
Hello, Updated packages works for me too. (Lenovo yoga 900 is my laptop.)
grub2-2.02-0.33.fc24, grub2-2.02-0.34.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc
This has been verified with 0.34 by several reporters.
grub2-2.02-0.34.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Hey folks - if possible, can you try re-installing Fedora with a Final RC-1.2 image - see https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Installation for download links - and see if it works OK? We hit issues with a couple of systems, so it'd be good to have a few more tests. Thanks!
With grub2-2.02-0.34.fc24 i get a 'relocation failed' error upon trying to boot Win 10.
What did you get before? What's the underlying storage? Thanks!
I used to get the 'out of memory' errors with .30. With .34, Fedora boots but Windows fails with above error. If i try Windows, then go to Fedora, the error still appears once, but on second try, Fedora boots. Windows is installed on a separate Samsung 850 EVO 500Gb SSD. The last version that works reliably for me is grub2-1:2.02-0.25.fc23.x86_64.
(In reply to Sebastian Grill from comment #67) > I used to get the 'out of memory' errors with .30. Same here. I was getting "out of memory" errors with .30, now I get "relocation failed" with grub2-2.02-0.34.fc24.x86_64 I can't boot Windows 10 from grub, I can boot it however selecting it from the EFI. Fedora boots just fine.
I can't reproduce the problem with or without Secure Boot enabled, both Fedora and Windows 10 boot from GRUB. This is on an Intel NUC5PPYB BIOS 86A 02/23/2016. Fedora-Workstation-Live-x86_64-24-1.2.iso grub2-efi-2.02-0.34.fc24.x86_64
Booting Win10 from GRUB started to work for me after the update. Secure Boot off. When I get back to my machine I can try with Secure boot on if that makes any difference.
For people with 'relocation failed' error: the problem is now tracked in bug 1347291.
I don't think the problem is entirely fixed. I previously encountered this problem in alpha and beta stages (you can see one or two comments of mine above), but ultimately I fell back to Fedora 23 and stopped testing as Fedora 24 had too many issues for me to play with. Today I decided to update to the final release, and even though I get no "out of memory" error, Windows 10's bootloader refuses to unlock the bitlocker protected partition onto which the OS is installed, and prompts me to insert the bitlocker recovery key. Normally, the unlocking process is automatic since my machine (Surface pro 3) makes use of an integrated TPM 2.0 chip onto which the bitlocker password is stored, in combo with Secure Boot (both enabled at the time of upgrade, Fedora 23 had no problems whatsoever). Even if insert the correct recovery key when prompted and the bitlocker protection is apparently restored, it is not. The system reboots (as it should), but still prompts me for the recovery key whenever I attempt to boot Windows 10. Disabling secure boot from UEFI settings did not help, however falling back on Fedora 23's GRUB2 did the trick and I can now boot Windows 10 normally. I guess there are still a few issues with it in Fedora 24. Let me know if I can help in any way.
I can confirm the issue with Microsoft BitLocker with the current version running on a Thinkpad T440s. I tried to fix it by disabling and reactivating BitLocker. Reactivation failed. The error message said something about the device not beeing ready. I dunno if this is a problem with Grub or BitLocker, but with Grub 2.02-0.25.fc23 (without SB) it worked.