Bug 1170245 - SecureBoot enabled causes Win 8 UEFI to not start from grub
Summary: SecureBoot enabled causes Win 8 UEFI to not start from grub
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://fedoraproject...
: 1144657 1180787 (view as bug list)
Depends On:
Blocks: F21FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-12-03 15:09 UTC by Kamil Páral
Modified: 2017-08-08 11:50 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-08 11:50:17 UTC


Attachments (Terms of Use)
grub error screenshot (82.81 KB, image/jpeg)
2014-12-03 15:11 UTC, Kamil Páral
no flags Details
grub.cfg (4.25 KB, text/plain)
2014-12-03 15:12 UTC, Kamil Páral
no flags Details
os-prober.out (76 bytes, text/plain)
2014-12-03 15:12 UTC, Kamil Páral
no flags Details
boot-efi.filelist (7.94 KB, text/plain)
2014-12-03 15:12 UTC, Kamil Páral
no flags Details
efibootmgr.out (2.31 KB, text/plain)
2014-12-03 15:12 UTC, Kamil Páral
no flags Details
lsblk.out (756 bytes, text/plain)
2014-12-03 15:12 UTC, Kamil Páral
no flags Details
parted.out (664 bytes, text/plain)
2014-12-03 15:12 UTC, Kamil Páral
no flags Details
rpm-qa.out (46.19 KB, text/plain)
2014-12-03 15:13 UTC, Kamil Páral
no flags Details
anaconda.log (16.90 KB, text/plain)
2014-12-03 15:14 UTC, Kamil Páral
no flags Details
journal.log (1.05 MB, text/plain)
2014-12-03 15:14 UTC, Kamil Páral
no flags Details
program.log (103.61 KB, text/plain)
2014-12-03 15:14 UTC, Kamil Páral
no flags Details
storage.log (243.37 KB, text/plain)
2014-12-03 15:14 UTC, Kamil Páral
no flags Details
packaging.log (209 bytes, text/plain)
2014-12-03 15:14 UTC, Kamil Páral
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1144657 None None None Never

Internal Links: 1144657

Description Kamil Páral 2014-12-03 15:09:53 UTC
Description of problem:
I installed a default installation of Win 8 x86_64 UEFI. Then I did a default installation of F21 RC4 Workstation x86_64 UEFI. I shrank the windows partition a bit. After reboot, I can boot to windows from UEFI boot menu, but I can't boot to windows from grub. The menu item is there, but after selecting it, it says:

file path: <path>
error: cannot load image.

Please see attached screenshot for the whole error message. I can't find any problem, all the files seem to be there, and I don't see any error in grub configuration. Maybe you can spot it?

Version-Release number of selected component (if applicable):
grub2-2.02-0.11.fc21.x86_64
grub2-efi-2.02-0.11.fc21.x86_64
grub2-tools-2.02-0.11.fc21.x86_64
grubby-8.35-8.fc21.x86_64
os-prober-1.58-11.fc21.x86_64
anaconda-21.48.21-1.fc21.x86_64

How reproducible:
2/2 attempts

Steps to Reproduce:
1. install windows
2. install fedora, guided partitioning, shrink windows partition
3. try to boot windows from grub, doesn't work

Additional info:
This scenario worked for me with TC4, albeit on a different machine. Either something changed between TC4 and RC4, or it is a machine specific problem. Debugging more now.

Comment 1 Kamil Páral 2014-12-03 15:11:23 UTC
Created attachment 964171 [details]
grub error screenshot

Comment 2 Kamil Páral 2014-12-03 15:12:11 UTC
Created attachment 964172 [details]
grub.cfg

Comment 3 Kamil Páral 2014-12-03 15:12:13 UTC
Created attachment 964173 [details]
os-prober.out

Comment 4 Kamil Páral 2014-12-03 15:12:15 UTC
Created attachment 964174 [details]
boot-efi.filelist

Comment 5 Kamil Páral 2014-12-03 15:12:16 UTC
Created attachment 964175 [details]
efibootmgr.out

Comment 6 Kamil Páral 2014-12-03 15:12:18 UTC
Created attachment 964176 [details]
lsblk.out

Comment 7 Kamil Páral 2014-12-03 15:12:20 UTC
Created attachment 964177 [details]
parted.out

Comment 8 Kamil Páral 2014-12-03 15:13:59 UTC
Created attachment 964178 [details]
rpm-qa.out

Comment 9 Kamil Páral 2014-12-03 15:14:01 UTC
Created attachment 964179 [details]
anaconda.log

Comment 10 Kamil Páral 2014-12-03 15:14:08 UTC
Created attachment 964180 [details]
journal.log

Comment 11 Kamil Páral 2014-12-03 15:14:10 UTC
Created attachment 964181 [details]
program.log

Comment 12 Kamil Páral 2014-12-03 15:14:13 UTC
Created attachment 964182 [details]
storage.log

Comment 13 Kamil Páral 2014-12-03 15:14:15 UTC
Created attachment 964183 [details]
packaging.log

Comment 14 Kamil Páral 2014-12-03 15:15:06 UTC
This seems to violate our dual-boot criteria, unless it's a single-machine failure. Raising.

Comment 15 Kamil Páral 2014-12-03 15:54:52 UTC
So, I tried the same approach with TC4, and it doesn't work either. But I tried the same use case with TC4 in the past (using a different machine), and it worked:
https://fedoraproject.org/wiki/Test_Results:Fedora_21_Final_TC4_Installation#Miscellaneous

So this is probably problem of a single machine, or a set of machines, but not generic. Or I'm doing something wrong.

Comment 16 Kamil Páral 2014-12-03 16:00:50 UTC
On a different machine, the same use case (Win 8 + F21 RC4) works perfectly, boot windows even from grub. Therefore this problem affects only some machines.

Comment 17 Kamil Páral 2014-12-03 16:48:31 UTC
So, a revelation here. If I disable Secure Boot, Windows boots. The other machine has just UEFI, no SB, so therefore it booted OK every time. But the original machine had SB on, and that's the reason it didn't work.

Comment 18 Kamil Páral 2014-12-03 17:15:33 UTC
For the record, the machine in question is Lenovo T540p.

Comment 19 Mike Ruckman 2014-12-03 18:44:30 UTC
Discussed in 2014-12-03 blocker review meeting. Rejected as a blocker: This doesn't violate any specific release criterion. Document on common bugs that SB enabled dual boots might not work at this point. Workaround is to turn it off.

Comment 20 Dominik 'Rathann' Mierzejewski 2015-01-15 17:25:37 UTC
FWIW I'm also seeing this on Dell XPS 13 (2014 model), just like bug 1180787.

Comment 21 Kamil Páral 2015-01-16 15:47:10 UTC
*** Bug 1180787 has been marked as a duplicate of this bug. ***

Comment 22 Kamil Páral 2015-01-16 15:47:15 UTC
*** Bug 1144657 has been marked as a duplicate of this bug. ***

Comment 23 Chris Murphy 2015-01-16 18:56:47 UTC
This works on opensuse 13.2. After some digging around, I found this patch that might explain why.
https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch?expand=1

It suggests the problem is widespread, because without secure boot chainloader support, this would always fail on secure boot enabled computers (i.e. this is not a model specific bug).

Comment 24 Adam Williamson 2015-01-26 16:56:06 UTC
let's at least document this in commonbugs. pjones says he's happy to include the patch next time we build shim (assuming he reviews it and thinks it's OK), but we do shim builds infrequently as they have to go through the signing process, and we're not yet sure if there'll be one for f22.

Comment 25 Andrey Borzenkov 2015-03-30 14:52:35 UTC
I was not able to reproduce it in QEMU + OVMF using either upstream or RH grub. I think there are a couple of things we could try in grub code if someone is willing to invest time in enrolling own keys and signing grub builds.

One thing I definitely would ask someone who has this problem to test - are you able to start Windows bootloader from within EFI Shell? I can explain how to do it if needed.

For now it looks like firmware behaves differently when binary is loaded by platform boot manager than by other EFI binary. Testing with EFI shell could confirm it.

Comment 26 Andrey Borzenkov 2015-03-30 14:56:25 UTC
(In reply to Chris Murphy from comment #23)
> This works on opensuse 13.2.

Patch in openSUSE sidesteps this issue by not using LoadImage at all. Before using it I'd still like to understand why standard LoadImage does not work.

Comment 27 Dominik 'Rathann' Mierzejewski 2015-03-30 22:38:27 UTC
(In reply to Andrey Borzenkov from comment #25)
> I was not able to reproduce it in QEMU + OVMF using either upstream or RH
> grub. I think there are a couple of things we could try in grub code if
> someone is willing to invest time in enrolling own keys and signing grub
> builds.

I'd be capable of doing that, but I don't have that much time and also I can't keep the machine where the problem is reproducible for extended periods of time.

> One thing I definitely would ask someone who has this problem to test - are
> you able to start Windows bootloader from within EFI Shell? I can explain
> how to do it if needed.

I can probably do this more easily if you provide (a link to) an explanation how to do it.

Comment 28 Andrey Borzenkov 2015-03-31 07:21:42 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #27)

EFI Shell primer: https://software.intel.com/en-us/articles/uefi-shell

If you firmware boot manager allows booting into EFI Shell directly, do it. You will be in environment, similar to DOS command.com (dir, cd, backslash as separator etc). Known filesystems will get aliases fs0, fs1, ... (you can treat them as drives in DOS). You will probably have single fs0 for EFI System Partition; aliases are listed when shell is started and can be checked using "map" command. Find alias for EFI System Partition and do

fs0:
cd \EFI\Microsoft\Boot
bootmgfw.efi

If your system does not provide EFI Shell (quite likely) you will need to download it, e.g. from https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg, sign with key you generated and enroll the key. For openSUSE procedure is described in https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel; I understand Fedora is using shim as well, so it should be similar.

Comment 29 Lukas Brabec 2015-03-31 13:37:33 UTC
I reproduced this with F22 Beta TC5 on Thinkpad T540p. However, I'm not enough proficient with efi and signing related stuff. Could you please provide more comprehensive guide or steps for Fedora?

Comment 30 Chris Murphy 2015-08-28 16:26:59 UTC
What's the status of either fixing this in standard LoadImage, or bypassing it as openSUSE does in the meantime?

This is a bad experience right now because users are wrongly being told the work around is to disable Secure Boot, rather than being told to use the firmware's built-in boot manager to directly choose the Windows bootloader. And some systems now ship with USB disabled so it requires booting Windows to get to the firmware configuration or one-time boot menu, and in such cases the user can be stuck since we're making GRUB the default bootloader.

Comment 31 Michael Catanzaro 2015-09-02 15:42:49 UTC
Hey Chris, Peter was at the meeting today, and asked us to create an issue at: https://github.com/rhinstaller/shim/issues

Do you want to do that, if you have a GitHub account?

Comment 32 Chris Murphy 2015-09-07 16:42:23 UTC
I have a github account, but I don't understand why shim needs resigning to implement the GRUB patch cited in comment 23, and therefore am probably not the best person to create an issue for shim.

Comment 33 Chris Murphy 2015-09-07 16:46:03 UTC
OK I did my best, feel free to make whatever clarity changes are needed.
https://github.com/rhinstaller/shim/issues/42

Comment 34 Fedora End Of Life 2015-11-04 10:22:54 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 35 Adam Williamson 2015-11-04 18:21:48 UTC
This still seems to be current, bumping to Rawhide.

Comment 36 Jan Kurik 2016-02-24 13:17:41 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 37 Samuel Sieb 2016-03-23 19:34:04 UTC
This has been working fine for me since at least F23, possibly even F22 on new installs.

Comment 38 Chris Murphy 2016-03-23 19:47:55 UTC
I'm not seeing anywhere that this has been fixed in either Fedora's grub2 git, or upstream shim git. Are you sure Secure Boot is enabled and that you're not using the firmware's boot manager to boot Windows instead of GRUB?

Comment 39 Samuel Sieb 2016-03-23 20:07:47 UTC
Definitely not using the firmware's boot manager.  Sometimes I even have to break the normal windows boot because of terrible BIOS implementations not letting me set Fedora as default.  I will verify the secure boot state on the student laptops when school starts again in a couple of weeks.

Comment 40 Dominik Kleiser 2016-03-29 12:57:23 UTC
Same problem here. I'm having the problem since at least Fedora 21. Still having it on a now fresh install of Fedora 24 Alpha 1.7. So grub 2.02 beta 3 does not fix it. I'm running on a Thinkpad T440s machine...

Comment 42 Samuel Sieb 2016-03-30 04:11:59 UTC
I remembered that I installed F23 for someone at work.  I had him check that secure boot was enabled and that he could boot windows from the grub menu.  Unfortunately, windows reconfigured the boot again, so I'll have to fix that now...

Comment 43 Fedora End Of Life 2017-07-25 18:44:49 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. 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 Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 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, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 44 Fedora End Of Life 2017-08-08 11:50:17 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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