Description of problem: Unable to boot into windows on UEFI dual boot installation. Version-Release number of selected component (if applicable): grub2-mkconfig (GRUB) 2.00 Fedora 19 (3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) How reproducible: Everytime Steps to Reproduce: 1. Create hidden diagnostics partition in sda1 2. Create EFI partition in sda2 3. Install dual boot system with Windows 8 and Fedora 19 both in EFI mode Actual results: When booting Windows from grub menu I recieve an error message that it cannot find /EFI/Microsoft/Boot/bootmgfw.efi Expected results: System to boot into Windows Additional info: By adding "set root" to the grub.cfg file, as seen in the example below, the system is able to boot Windows as expected. menuentry 'Windows Boot Manager' { set root='hd0,gpt2' chainloader /EFI/Microsoft/Boot/bootmgfw.efi boot }
What is the output of "os-prober"? And please attach the output of "grub2-mkconfig".
Created attachment 801578 [details] Output from grub2-mkconfig
(In reply to Mads Kiilerich from comment #1) > What is the output of "os-prober"? And please attach the output of > "grub2-mkconfig". [zedgama3@localhost ~]$ sudo os-prober Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows /dev/sda6:Debian GNU/Linux (Kali Linux 1.0):Debian:linux [zedgama3@localhost ~]$ sudo parted /dev/sda print Model: ATA TOSHIBA MQ01ABD0 (scsi) Disk /dev/sda: 750GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 472MB 471MB ntfs hidden, diag 2 472MB 746MB 274MB fat32 boot 3 746MB 880MB 134MB ntfs msftres 4 880MB 291GB 290GB ntfs Windows 8 5 291GB 375GB 83.9GB ext4 Fedora 6 375GB 411GB 36.7GB ext4 Kali 7 411GB 750GB 339GB ntfs Storage
It looks like this may be the same as bug 986731. I see this problem in F20 Beta TC5. Addition of a "set root=" line to grub.cfg as described in the original report was effective, though in my case I had three EFI partitions (two from the OEM image, one added by Fedora installation) and spent some time to learn which of the three had to be tweaked.
This bug violates F20 Final criterion "2.2.9 Windows dual boot": 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.
That criteria applies to BIOS computers, where only one bootloader can live in the MBR so if we replace the Windows bootloader in order to boot Fedora then we're obligated to provide a means to still boot Windows. On UEFI, the default boot manager UI/UX is up to the firmware OEM. So while it would be nice to have a single unified boot manager UI/UX (with GRUB, gummiboot or rEFInd) I don't see the situation as reliable enough to make this blocking on UEFI computers just yet. If the GRUB entries aren't going to work, we should suppress their creation, however. (The OS X entries created for Macs also don't work, cause kernel panic, bug 904668.)
(In reply to Chris Murphy from comment #6) You make a good argument, but if the criterion does not apply to UEFI systems, it should _say_ it does not apply to UEFI. >If the GRUB entries aren't going to work, we should suppress their creation, Better to fix them. Jared described what could be added to the GRUB entry to make it work for him, and I followed his instruction to make mine work. Nevertheless, I am still concerned that I started with a machine that booted Windows 8 installed by the OEM, I installed F20TC5, and subsequently I could not boot Windows. Well, after the fix to the GRUB entry, I could boot Windows, but using the native firmware to boot Windows actually started my machine's "Recovery" system. Somehow, the combination of Fedora installation, an attempt to restore the original Windows state using the OEM "Recovery" tools and re-installation of Fedora with "automatic partitioning" led to three EFI System Partitions that apparently confused the OEM firmware. I believe I have sorted this out - the boot firmware now displays two identical Windows options (I believe it originally displayed only one) and it maters which of the two one selects to boot. Looking back, it would have been better to capture a full disk image of the original system before I started Fedora installation. Once I discovered I could boot a Fedora Live image, I skimped on caution and thought I could depend on the OEM recovery procedure to fix any mess. It is significantly more convenient to select Fedora or Windows from a GRUB menu than by my UEFI firmware, but I agree that firmware selection is a sufficient option. What I do not know is if my attempts to install Fedora broke my UEFI firmware's Windows boot selection capability, or whether a combination of Fedora and OEM Recovery activity is necessary to do this damage. I have a Samsung Book 9 plus (model NP940X3G-K01US) which now seems quite stable with the F20 3.11.6 kernel.
I agree the behavior needs to improve, but it hasn't worked to date so at least it's not a regression. Also gummiboot handles this better than grub at the moment, as it automatically finds Windows and OS X without needing configuration scripts like grub does. In that sense I think it makes a more robust boot manager. The thing is, it presently doesn't have ext file system support, so it depends on the firmware's ability to read FAT32, meaning the kernel and initramfs need to be on the ESP which isn't a layout supported by the installer. Also complicating matters is some boot managers use NVRAM entries to determine what the boot options are, and others use what's on the ESPs, and still others use a combination of the two. So there's likely more than just one bug or RFE here.
Richard: "You make a good argument, but if the criterion does not apply to UEFI systems, it should _say_ it does not apply to UEFI." It was written quite a while ago, without UEFI really being taken into consideration. I haven't proposed a revision for it yet because I'm still not sure what the intended behaviour for UEFI installs actually is: I don't know if we're intending that anaconda should create working grub entries for other OSes on UEFI systems, or if we're intending to rely on the EFI boot manager.
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . We agreed to amend the criterion to specify it covers the BIOS case only, and consequently this bug is rejected as a blocker.
I also had a non-fuctional Windows 8 entry in my grub menu after installing Fedora 20. My case is described in detail here: http://forums.fedoraforum.org/showthread.php?p=1684023 In summary, it seems to me like it would be a good solution if grub2 would install itself to Windows 8 EFI System Partition (ESP) if it detects that such a partition is already present on one of the disks? So that it doesn't create a new ESP for Fedora and installs itself there?
Proposing as a F21 final blocker, again under 2.2.9: "The installer must be able to install into free space alongside an existing clean Windows installation and, when performing a BIOS (not UEFI) installation, install a bootloader which can boot into both Windows and Fedora." Though this bug is not currently covered by this criterion, we need to discuss amending the criterion yet again in order to cover UEFI in addition to BIOS, since it is very difficult to access the UEFI boot menu on many new Windows computers. See also https://lists.fedoraproject.org/pipermail/desktop/2014-July/009984.html
We need someone with UEFI hardware and an existing Windows 7 or 8 installation do to a Rawhide install and see if this is working now. It's supposed to be working in GRUB 2.02 beta 2, which is what Rawhide's GRUB is based on.
note that virtualized UEFI works well enough to test this, i believe, at least it did last time I checked. I have a UEFI VM, I'll see if I can do a Windows install and check this out.
FWIW, I got stuck on https://bugzilla.redhat.com/show_bug.cgi?id=1118923 trying to verify the current state of this.
Installed on my laptop yesterday. With secureboot enabled I have this bug. With secureboot disabled I haven't this bug. Fedora is booting fine anyway.
(In reply to lonelywoolf from comment #16) With SecureBoot enabled you get a message that grub can't find /EFI/Microsoft/Boot/bootmgfw.efi ? Can you boot with Secure Boot enabled and disabled, and in each environment run 'os-prober' and post the results? And also post the /boot/efi/EFI/fedora/grub.cfg file. Thanks.
Actually, please *attach* the grub.cfg rather than posting it. Thanks.
Created attachment 938162 [details] grub.cfg
with secureboot: [root@localhost fedora]# os-prober /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi with secureboot disabled: [root@localhost fedora]# os-prober /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi (the same).
Created attachment 938163 [details] bug Screenshot
Created attachment 938164 [details] screenshot additional may be related With secureboot I have some message when pressing enter on fedora kernel in grub menu. I think, it may be related.
(In reply to lonelywoolf from comment #22) I think this is sufficiently different from this bug, in title or description, that it deserves its own bug. File it against grub2. Suggest subject: UEFI Secure Boot failure to boot Windows, cannot load image. Include WP_20140917_005.jpg. And add me to cc.
It's done. Bug 1144657.
Afraid this never got re-considered as a blocker because the RejectedBlocker field wasn't cleared from the whiteboard - sorry about that. 21 is now signed off, so dropping it.
I thought this was fixed upstream in GRUB 2.02 so as reported it shouldn't be happening; at least the test case for this passed so I'm expecting the bug probably can be closed.
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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.