English

# Windows 7 and Fedora 24 dual boot on (U)EFI system - what are the issues here, where is it documented?

Hi,

I know that similar questions have been asked and answered several times here but I couldn't find an answer that both explains what's going on/going wrong and how to fix it.

I managed to install Win7 (x86-64) and Fedora 24 Workstation (x86-64) in UEFI firmware mode (Secure Boot disabled) on a disk (first SATA port) with GPT partition table - easy. Grub2 detected the Win7 installation but is not able to boot it. Both firmwares share the same EFI partition (/dev/sda1).

I ran os-prober to generate a Grubf menu entry for Win7 (see 30_os-prober config below) and I manually added one entry (see 40_custom config below). If I select any of the two from Grub menu, I end up with a black screen, no message, no clue how to debug.

Now, only way to boot Win 7 is to interrupt boot process, select different boot device and select Win7 boot manager from UEFI menu. That solution works but is not very elegant.

I would like to understand what the problem of Grub2 is here and how to fix it.

Can someone please point me into the right direction? Thanks!

I have the following existing grub.cfg (cut out everything before 30_os-prober because irrelevant). (Whatever the meaning of section 41_custom is, I don't get it.) Here is the 30_os-prober that was generated by os-prober:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-92FE-527B' { insmod part_gpt insmod fat set root='hd0,gpt1' if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  92FE-527B
else
search --no-floppy --fs-uuid --set=root 92FE-527B
fi


What the meaning of the if, then, else section? What are all the extra flags (--class windows -- class os...)?

Here is the 40_custom that I manually created:

menuentry "Windows 7" {
insmod part_gpt
insmod chain
set root=(hd0,gpt1)
}


I ran sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg after creating this manual entry. No sucess: black screen on booting that entry from Grub. (Machine freezes, nothing else possible than hardware power button). Where can I find log file of Grub?

Here is the relevant output of parted -l. Why does MS WIN create an EFI partition with FAT32, while anaconda would create an EFI with FAT16, (if I am not wrong)?

Not sure it matters: My hardware is a Lenovo Thinkstation E31 (intel i5) with up-to-date firmware (May 2016)

edit retag close merge delete

Did you manage to solve your problem? I have exactly the same problem and same GRUB config as you; and a black screen when I select the Windows boot manager. It was working before so I wonder whether a recent update to Grub2 broke something? I know my Windows EFI partition works correctly because if I boot it from the BIOS, it works.

( 2016-07-30 20:30:19 +0000 )edit

This question/issue may actually be related to the bug that is mentioned here - user with same experience: Grub boot Windows ends up with a black screen: https://ask.fedoraproject.org/en/ques...

( 2016-08-01 14:54:45 +0000 )edit

Thanks @florian. Seems to be the same issue. @Matthieu, unfortunately no, didn't manage to resolve the issue. I wasn't aware of the grub bug, and what I currently do is using the boot manager of the UEFI firmware to fire up my Windows 7. The solution sucks but until grub is fixed, it will be what I am going to do...

( 2016-08-01 16:19:42 +0000 )edit

Sort by » oldest newest most voted

I had the same issue until about 5 minutes ago. Installed with a dual-boot EFI F23 and Windows 7 and worked fine. Upgraded to F24 and got a blank screen after selecting Windows from the grub menu. Turns out the explaination is simple: The version of grub2-efi in F24 has a regression.

Then do

dnf downgrade grub2*.rpm
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg


I'm not sure if the grub2-mkconfig is required; just did it for good measure. Works as before after that.

Probably want to add grub2-efi and grub2-tools to the excluded package list in /etc/dnf/dnf.conf

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=grub2-efi grub2-tools

more

1

I had reinstalled Win and chose Win 8.1 this time, which is much better in handling EFI stuff. Still, problem persisted until I followed your advice and downgraded grub2. Butgrub2-efi and grub2-tool wasn't enough, I also had to download and downgrade grub2 Thanks for the hint. According to the bugzilla, there you be a patched version of grub2 (for fc25) out there... Let's see if that fixes the problem, and if it will make its way to F24.

( 2016-12-05 18:04:02 +0000 )edit

There is some ambiguity in the UEFI spec on FAT32 vs FAT16 for EFI System partitions on non-removable media, because the spec requires the firmware to understand both. It should probably be FAT32, but Anaconda uses fairly default mkdosfs options, which due to the size of the EFI system partition, ends up making it FAT16.

As for your black screen problem, you can selectively insert into the grub.cfg directly, a debug=all, for example you could insert this right after the chainloader line. It's extremely verbose so the higher up in the config file you put it, the more debug info you get about things that probably aren't related (pages of debug info are typical for every module insertion because it'll show every sector it's reading from off the file system). To narrow it down you can use a selective debug= option, but there's no listing of these in the GRUB manual, you'd have to go read the code. I don't know that the debug output is going to help you though, it's at a much more basic level than even kernel messages. But it might be helpful to capture each page of debug info (cell phone photo) and attach in sequence to a bug report.

The menu entry for Windows that you have doesn't appear to be malformed to me, I think you're seeing a different problem. I recommend making certain the firmware version is up to date though, there are an unlimited supply of bugs in UEFI implementations, and I see prolific firmware updates (my Intel NUC has had about 8 firmware updates since its release middle of last year).

more

The problem with the FAT32 vs. FAT16 driver choice is that the EFI specification requires that the partition be formatted with a file system derived-but-distinct from FAT. So, the Linux Kernel's FAT32 or FAT16 drivers are both probably ok for accessing and handling such a file system specification (though I don't know if one is a superior choice to the other for any particular reason). That's why you see both implementations for handling EFI partitions. My suspicion is that either should work.

( 2016-07-30 14:25:11 +0000 )edit

I've the same problem as the OP. I've used your "debug=all" suggestion, everything seems to work until I get a "booting via entry point" message. It's the last message I see, after this my PC hangs and the only option I have is to do a hard reset. Any ideas?

( 2016-07-30 20:26:06 +0000 )edit

@cmurf: Thanks for you suggestion - I will try the debug=all option and report back.Where will the log file of grub be stored? /var/log/grub or so?

I'll checked again on Lenovo's website and the firmware I am running is up-to-date (May 2016).

( 2016-08-01 16:22:17 +0000 )edit

The basic answer is that the issue is somewhat outside of standard Fedora system administration, being related exclusively to GRUB. Bootloaders are not commonly well understood and that's why it's a common and difficult question.

GRUB, the GRand Unified Bootloader, is fantastic for Linux-based systems since it works directly in its role, providing the bootloading service almost exclusively for Linux-based distributions. Windows, however, ships with its own proprietary bootloader and it is not specifically supported by GRUB.

To solve this issue, GRUB offers what's called "chainloading" where the GRUB bootloader can be used to call up another bootloader (e.g. the Windows bootloader). This is what you have to put in place in order to have a more seamless experience with GRUB.

The Basics (for an MBR/BIOS Arrangement)

This page shows you the kind of entry you will have to create so that GRUB has a menu entry which understands the location of the Windows bootloader and how to access it:

menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
}


Your entry may differ depending upon the hard disk and partition on which Windows is installed (the above entry is tailored for a Windows installation on the first partition of the first hard disk recognized by GRUB). The lines work as so:

• The curly-brace-enclosed phrase establishes a menu entry called "Windows" (you could call it something more explicit like "Windows 10" or whatever).
• The second line loads the NTFS module so that GRUB can read the contents of the Windows partition.
• The third line sets the root partition from which GRUB will read the NTFS-based information (hd0 = first hard disk recognized by GRUB, 1 = first partition on that hard disk)

You should be able to configure your GRUB menu effectively by adding the stanza to a file in /etc/grub.d, as directed by this documentation.

If you are using an EFI/GPT Arrangement

In this case, you'll need to modify the same file described above (some file in /etc/grub.d), but you'll use some different GRUB menu entry syntax; your stanza will direct GRUB to chainload the bootloader software located in the EFI partition on your system, not the disk partition on which Windows, itself, is installed.

To identify your EFI partition's file system UUID (which can be directly addressed by GRUB), you may execute grub2-probe from within Fedora like so:

grub-probe --target=hints_string /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

You can take the output generated by that command (referred to as "<uuid>" below) and create a menu entry like so:

menuentry "Windows" {
insmod part_gpt
insmod chain
search --fs-uuid --no-floppy --set=root <UUID>
}


Note that GRUB uses forward-slashes in a UNIX style to specify file locations and paths, regardless of operating system conventions (such as backslashes ...

more

Later today, I will post the current entry Grub generated to chainload the MS bootloader. I don't have it in front of me now, but off my head I can say it looks totally different (insmod fat, if...). I'll post output here. I assume in my case I point the root (set root) to the efi partition, and load a fat16/32 module since that's the FS on my efi partition, correct? I see, I will have to study the documentation and create a /etc/grub.d/40_custom accordingly. I'll let you all know how it works. Why is this not automated by grub2-mkconfig ? Looks straight forward?

( 2016-07-19 19:52:31 +0000 )edit

Make sure to include the version of Windows and the disk and partition number on which you have it installed. We'll figure it out.

( 2016-07-19 19:56:55 +0000 )edit

See if this is any helpful

( 2016-07-19 20:26:28 +0000 )edit

Ok, I overlooked that you specified you are using a UEFI system, so I added instructions for a GPT-based UEFI partition. Your GRUB entry specifying the FAT module should be ok, I think, but I don't believe you need to specify to GRUB that it needs to load the FAT module, as I believe it's loaded automatically if needed (which may be the case with NTFS, too). You can try explicitly adding it; don't believe it will cause any problems, but I'd try to keep the entry as minimal as possible.

( 2016-07-19 20:36:37 +0000 )edit

Did you confirm that you have a GPT-partitioned disk? Is the path to your bootmgfw.eli file /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi? If so, I have updated my answer to provide perhaps an easier solution to make sure you're directing GRUB to the correct disk partition (using the search feature rather than explicitly setting the root partition based on hard disk enumeration values which could change across boots).

( 2016-07-20 13:50:08 +0000 )edit

[hide preview]