Created attachment 939481 [details]
Description of problem:
UEFI Secure Boot failure to boot Windows, cannot load image
Just enable secure boot in UEFI BIOS settings. Always.
Error message (in attachment)
Boot windows normally.
Please specify the filename for the media you're using, e.g. Fedora-Live-Workstation-x86_64-21_Alpha-1.iso, and how it was created, e.g. dd to USB, and what the dd command was.
Does the error happen when booting installer media? Or only when booting the installed system?
What make/model/firmware version for the system?
This is Samsung NP535U3C-A0HRU ultrabook with 500 GB HDD and firmware is P12ABH
Released in early 2014 or end 2013 as I remember.
See also bug 986731
(In reply to Chris Murphy from comment #1)
> Please specify the filename for the media you're using, e.g.
> Fedora-Live-Workstation-x86_64-21_Alpha-1.iso, and how it was created, e.g.
> dd to USB, and what the dd command was.
> Does the error happen when booting installer media? Or only when booting the
> installed system?
I was not tested installer media. I was just upgraded to F21 with yum. And F20 have this bug too. Fedora installation booting as normal in any case, but with secure boot enabled this reports an error loading in-kernel certificate.
Sorry for my bad English.
I had this problem with F20 several months ago. But any recent installs of F20 (I include updates in the install) have been able to boot Windows from the Fedora grub menu. I suspect there was a change in the grub config generation somewhere along the way. Try regenerating your grub config and see if that fixes it.
Was tried and no hope. Which device/firmware are you use?
You have the latest grub-efi package and you regenerated the grub efi config file?
I have this working on many Windows 8 laptops. I don't have physical access to any of them right now, but I know it wasn't working when I first tried dual-booting with W8 last year and it is now. I will note that these were all clean installs. Next time I am there I will try to track down one of the older installs that couldn't chain load W8 (without disabling secure boot) and see if it will work now.
Btw, I have always seen that error about loading in-kernel certificate, but as far as I can tell, it has no actual effect on anything.
(In reply to Samuel Sieb from comment #7)
> You have the latest grub-efi package and you regenerated the grub efi config
Yes, it is. Seems as firmware incompatibility. with secureboot disabled it load's windows loader and windows 8.1 and windows10 preview runs correctly, but I see thesame error message. Trying to modify it, but without success now. Seems as thus bug affected samsung np530 series, some np900 and may be np535 series.
lonelywoolf: Please clarify. The problem booting Windows from GRUB only happens when Secure Boot is enabled, it works when disabled. Correct? And does Fedora boot when Secure Boot is enabled or does it also fail?
Proposed as a Blocker for 21-final by Fedora user chrismurphy using the blocker tracking app because:
"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."
Discussed at 2014-11-05 blocker review meeting . We decided the punt the decision. This requires some more testing to confirm. Will rediscuss at next meeting.
Those of you who tested this, can you please test with a clean Fedora 21 Beta installation? I see just a single report of failure, and that is an upgraded system (with an unsupported method). Thanks.
Seems that it is bug in my Notebook's firmware. It's buggy with UEFI in some other cases (LID status, AC/DC status, some power energy freezes, etc). Now it isn't booting with Secure boot anything, reverted to CSM. I think, we may close thus bug.
Just tested now, and closing this bug as the failure because reporter has is very specific environment (bugged firmware).
Just a note for the purposes of the blocker bug proposal: I have tested this quite extensively, see bug 986731 comment 36. I have found no problems with our test machine.
I'm able to reproduce this bug on a Dell XFS 13. Opened new bug 1180787.
(In reply to Chris Murphy from comment #16)
> I'm able to reproduce this bug on a Dell XFS 13. Opened new bug 1180787.
Since you opened a new bug, does it make sense to keep this one opened as well?
Maybe we can dupe this to bug 1170245 or vice versa? It seems to be the same problem.
Yes it looks like bug 1144657, bug 1170245, and bug 1180787 are dups. Feel free to mark 2 as dups of 1.
Closing as a duplicate of bug 1170245, because it contains logs, so it's more useful. Please feel free to attach logs of your non-working systems to that bug as well. Thanks.
*** This bug has been marked as a duplicate of bug 1170245 ***