Bug 1170245

Created attachment 964171 [details]
grub error screenshot

Created attachment 964172 [details]
grub.cfg

Created attachment 964173 [details]
os-prober.out

Created attachment 964174 [details]
boot-efi.filelist

Created attachment 964175 [details]
efibootmgr.out

Created attachment 964176 [details]
lsblk.out

Created attachment 964177 [details]
parted.out

Created attachment 964178 [details]
rpm-qa.out

Created attachment 964179 [details]
anaconda.log

Created attachment 964180 [details]
journal.log

Created attachment 964181 [details]
program.log

Created attachment 964182 [details]
storage.log

Created attachment 964183 [details]
packaging.log

This seems to violate our dual-boot criteria, unless it's a single-machine failure. Raising.

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.

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.

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.

For the record, the machine in question is Lenovo T540p.

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.

FWIW I'm also seeing this on Dell XPS 13 (2014 model), just like bug 1180787.

*** Bug 1180787 has been marked as a duplicate of this bug. ***

*** Bug 1144657 has been marked as a duplicate of this bug. ***

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).

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.

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.

(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.

(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.

(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.

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?

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.

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?

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.

OK I did my best, feel free to make whatever clarity changes are needed.
https://github.com/rhinstaller/shim/issues/42

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.

This still seems to be current, bumping to Rawhide.

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

This has been working fine for me since at least F23, possibly even F22 on new installs.

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?

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.

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...

Looks like there is a patch!
http://pkgs.fedoraproject.org/cgit/rpms/grub2.git/diff/0072-Add-secureboot-support-on-efi-chainloader.patch?id=d9747d852b37dcf22f3161669b27878ebc1485a7

This is in F24's grub2-efi.

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...

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.

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.