Bug 1320273 - chainloading bootmgr.efi on UEFI results in error: out of memory
Summary: chainloading bootmgr.efi on UEFI results in error: out of memory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 24
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker https://fedoraproject...
: 1321923 (view as bug list)
Depends On:
Blocks: F24FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2016-03-22 17:29 UTC by Giovanni Tirloni
Modified: 2016-07-17 20:41 UTC (History)
44 users (show)

Fixed In Version: grub2-2.02-0.34.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-14 08:40:37 UTC


Attachments (Terms of Use)
photo of out of memory, debug=all (69.90 KB, image/jpeg)
2016-04-13 20:26 UTC, Chris Murphy
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1347291 None CLOSED Booting from Windows 10 entry ends with 'relocation failed' error 2019-09-20 18:25:28 UTC

Internal Links: 1347291

Description Giovanni Tirloni 2016-03-22 17:29:51 UTC
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:

Comment 1 Giovanni Tirloni 2016-03-22 22:57:25 UTC
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

Comment 2 Giovanni Tirloni 2016-03-23 00:06:56 UTC
installing grub2-efi-modules and reinstall grub did not help.

Comment 3 Brian Lane 2016-03-29 16:42:07 UTC
*** Bug 1321923 has been marked as a duplicate of this bug. ***

Comment 4 Nirbheek Chauhan 2016-03-30 07:33:45 UTC
Are there any workarounds for this? This is really a critical bug for people with dual-boot systems.

Comment 5 Dominik Kleiser 2016-03-30 10:27:05 UTC
(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.

Comment 6 Michele 2016-04-04 14:27:55 UTC
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.

Comment 7 Giovanni Tirloni 2016-04-07 02:37:29 UTC
Issue was fixed by last update (grub2-2.02-0.28.fc24.x86_64).

Comment 8 Dominik Kleiser 2016-04-07 10:37:06 UTC
(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...

Comment 9 Giovanni Tirloni 2016-04-07 11:07:55 UTC
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.

Comment 10 Fedora Blocker Bugs Application 2016-04-08 12:42:12 UTC
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.

Comment 11 Chris Murphy 2016-04-09 17:51:15 UTC
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

Comment 12 Dominik Kleiser 2016-04-09 19:02:23 UTC
(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.

Comment 13 Giovanni Tirloni 2016-04-10 23:05:55 UTC
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 ###

Comment 14 Chris Murphy 2016-04-10 23:22:49 UTC
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.

Comment 15 Kamil Páral 2016-04-11 16:47:44 UTC
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/

Comment 16 Dominik Kleiser 2016-04-12 15:06:34 UTC
(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...

Comment 17 Dominik Kleiser 2016-04-12 16:39:43 UTC
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...

Comment 18 Chris Murphy 2016-04-13 20:26:03 UTC
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.

Comment 19 Chris Murphy 2016-04-13 20:43:39 UTC
NUC5PPYB, BIOS PYBSWCEL.86A.0050.2016.0223.1234 02/23/2016

This happens whether or not Secure Boot is enabled.

Comment 20 Michele 2016-04-17 21:31:07 UTC
Still happens with latest grub 02-0.30.fc24 package

Comment 21 Nick Bebout 2016-04-29 18:52:16 UTC
Happens to me also.

Comment 22 K 2016-05-01 20:51:18 UTC
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.

Comment 23 K 2016-05-03 08:08:09 UTC
(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.

Comment 24 Ahmad Samir 2016-05-08 09:22:13 UTC
(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.

Comment 25 Chris Murphy 2016-05-09 18:29:41 UTC
[root@f23s 0]# dd if=bootmgr.efi count=2 2>/dev/null | hexdump -C

https://paste.fedoraproject.org/364375/

Comment 26 thomas.michel 2016-05-12 10:39:05 UTC
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.

Comment 27 Dominik Kleiser 2016-05-17 15:14:48 UTC
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.

Comment 28 Jonathan Briggs 2016-05-21 22:01:22 UTC
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

Comment 29 Adam Williamson 2016-05-24 19:11:55 UTC
<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

Comment 30 Andrew J. Schorr 2016-05-25 15:09:12 UTC
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?

Comment 31 Adam Williamson 2016-05-25 15:19:22 UTC
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.

Comment 32 thomas.michel 2016-05-25 15:45:44 UTC
(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.

Comment 33 Andrew J. Schorr 2016-05-25 15:51:54 UTC
(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

Comment 34 Adam Williamson 2016-05-25 15:56:22 UTC
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.

Comment 35 Patryk Zawadzki 2016-05-25 16:05:42 UTC
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.

Comment 36 Adam Williamson 2016-05-25 18:33:09 UTC
"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.

Comment 37 thomas.michel 2016-05-30 08:40:15 UTC
(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.

Comment 38 gil cattaneo 2016-06-03 21:21:14 UTC
for me is: -1 blocker

Comment 39 Adam Williamson 2016-06-03 21:22:42 UTC
gil: this bug is already accepted as a blocker, it does not require votes. thanks!

Comment 40 Shawn Starr 2016-06-09 18:15:11 UTC
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.

Comment 41 Fedora Update System 2016-06-09 20:18:42 UTC
grub2-2.02-0.33.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc

Comment 42 Shawn Starr 2016-06-09 20:43:52 UTC
The above posting I created is now a different bug #1344512 it is unrelated to this it appears.

Comment 43 Adam Williamson 2016-06-09 20:56:05 UTC
Can anyone please test the update and check whether it fixes the problem reported in this bug? Thanks!

Comment 44 Corey Sheldon 2016-06-09 21:37:04 UTC
@ 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

Comment 45 Adam Williamson 2016-06-09 21:44:45 UTC
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.

Comment 46 Corey Sheldon 2016-06-10 00:13:31 UTC
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.

Comment 47 thomas.michel 2016-06-10 07:35:11 UTC
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.

Comment 48 Dominik Kleiser 2016-06-10 08:25:33 UTC
The update works with and without secure boot. Thank you!

Comment 49 Zbigniew Jędrzejewski-Szmek 2016-06-10 13:55:54 UTC
(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'

Comment 50 Fedora Update System 2016-06-10 18:00:22 UTC
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

Comment 51 Fedora Update System 2016-06-10 19:24:37 UTC
grub2-2.02-0.33.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc

Comment 52 Fedora Update System 2016-06-11 11:51:21 UTC
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

Comment 53 thomas.michel 2016-06-11 13:07:47 UTC
Hi,

can confirm all the bug is fixed with grub2-2.02-0.33.fc24.

Comment 54 Adam Williamson 2016-06-11 14:19:49 UTC
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.

Comment 55 thomas.michel 2016-06-11 21:06:22 UTC
Hi,

can confirm version 0.34 works as well.

Comment 56 Henning Rohde 2016-06-12 16:45:35 UTC
Hi!

Also i can confirm version 0.34 fixes my issues on booting Win10.

Thanks for your works!

Comment 57 Akın Ömeroğlu 2016-06-12 16:53:30 UTC
Hello,

Updated packages works for me too. 

(Lenovo yoga 900 is my laptop.)

Comment 58 Fedora Update System 2016-06-13 14:38:16 UTC
grub2-2.02-0.33.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc

Comment 59 Fedora Update System 2016-06-13 14:41:19 UTC
grub2-2.02-0.33.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc

Comment 60 Fedora Update System 2016-06-13 14:44:38 UTC
grub2-2.02-0.33.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c4d43baacc

Comment 61 Fedora Update System 2016-06-13 15:58:26 UTC
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

Comment 62 Adam Williamson 2016-06-13 22:07:45 UTC
This has been verified with 0.34 by several reporters.

Comment 63 Fedora Update System 2016-06-14 08:40:02 UTC
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.

Comment 64 Adam Williamson 2016-06-16 15:26:10 UTC
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!

Comment 65 Sebastian Grill 2016-06-16 15:35:52 UTC
With grub2-2.02-0.34.fc24 i get a 'relocation failed' error upon trying to boot Win 10.

Comment 66 Adam Williamson 2016-06-16 15:37:46 UTC
What did you get before? What's the underlying storage?

Thanks!

Comment 67 Sebastian Grill 2016-06-16 15:44:27 UTC
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.

Comment 68 Juan Orti Alcaine 2016-06-16 16:32:55 UTC
(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.

Comment 69 Chris Murphy 2016-06-16 17:49:48 UTC
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

Comment 70 Zdeněk Zikán 2016-06-17 10:25:06 UTC
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.

Comment 71 Kamil Páral 2016-06-21 08:51:18 UTC
For people with 'relocation failed' error: the problem is now tracked in bug 1347291.

Comment 72 Michele 2016-07-17 19:52:06 UTC
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.

Comment 73 Dominik Kleiser 2016-07-17 20:41:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.