Bug 1010704 - Grub2 does not specify root for windows entries where uefi partition
Grub2 does not specify root for windows entries where uefi partition
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
21
x86_64 Windows
high Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-22 12:47 EDT by Jared
Modified: 2015-12-02 11:06 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-01 21:57:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from grub2-mkconfig (6.82 KB, text/plain)
2013-09-23 07:06 EDT, Jared
no flags Details
grub.cfg (6.97 KB, text/plain)
2014-09-16 13:35 EDT, lonelywoolf
no flags Details
bug Screenshot (1.24 MB, application/octet-stream)
2014-09-16 13:40 EDT, lonelywoolf
no flags Details
screenshot additional may be related (1.39 MB, application/octet-stream)
2014-09-16 13:42 EDT, lonelywoolf
no flags Details

  None (edit)
Description Jared 2013-09-22 12:47:43 EDT
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
}
Comment 1 Mads Kiilerich 2013-09-22 15:07:55 EDT
What is the output of "os-prober"? And please attach the output of "grub2-mkconfig".
Comment 2 Jared 2013-09-23 07:06:49 EDT
Created attachment 801578 [details]
Output from grub2-mkconfig
Comment 3 Jared 2013-09-23 07:09:51 EDT
(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
Comment 4 Richard Ryniker 2013-10-23 13:43:06 EDT
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.
Comment 5 Richard Ryniker 2013-10-24 08:14:12 EDT
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.
Comment 6 Chris Murphy 2013-10-28 00:56:24 EDT
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.)
Comment 7 Richard Ryniker 2013-10-28 14:21:56 EDT
(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.
Comment 8 Chris Murphy 2013-10-28 14:49:42 EDT
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.
Comment 9 Adam Williamson 2013-11-12 20:15:01 EST
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.
Comment 10 Adam Williamson 2013-11-13 14:14:10 EST
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.
Comment 11 Alexander van Loon 2014-01-23 18:13:36 EST
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?
Comment 12 Michael Catanzaro 2014-07-06 13:31:18 EDT
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
Comment 13 Chris Murphy 2014-07-06 13:51:15 EDT
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.
Comment 14 Adam Williamson 2014-07-07 16:43:34 EDT
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.
Comment 15 Adam Williamson 2014-07-16 15:03:37 EDT
FWIW, I got stuck on https://bugzilla.redhat.com/show_bug.cgi?id=1118923 trying to verify the current state of this.
Comment 16 lonelywoolf 2014-09-16 12:40:51 EDT
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.
Comment 17 Chris Murphy 2014-09-16 13:05:21 EDT
(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.
Comment 18 Chris Murphy 2014-09-16 13:06:44 EDT
Actually, please *attach* the grub.cfg rather than posting it. Thanks.
Comment 19 lonelywoolf 2014-09-16 13:35:27 EDT
Created attachment 938162 [details]
grub.cfg
Comment 20 lonelywoolf 2014-09-16 13:36:34 EDT
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).
Comment 21 lonelywoolf 2014-09-16 13:40:24 EDT
Created attachment 938163 [details]
bug Screenshot
Comment 22 lonelywoolf 2014-09-16 13:42:07 EDT
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.
Comment 23 Chris Murphy 2014-09-16 14:18:31 EDT
(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.
Comment 24 lonelywoolf 2014-09-20 03:04:59 EDT
It's done. Bug 1144657.
Comment 25 Adam Williamson 2014-12-04 18:49:35 EST
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.
Comment 26 Chris Murphy 2014-12-04 19:04:29 EST
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.
Comment 27 Fedora End Of Life 2015-11-04 09:47:47 EST
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 28 Fedora End Of Life 2015-12-01 21:57:58 EST
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.

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