Bug 986731

In addition to the desktop described above, I have a laptop that also runs a dual boot, Windows 7 and Fedora 19.  It does not use UEFI.  Windows can be selected and started from its grub2 menu.  Also on the laptop, the grub2 splash screen does not work.

By searching the internet, looking at grub files on the desktop and on the laptop, and modifying grub files on the desktop, I have been able to get a grub boot menu that will actually allow me to boot either Fedora or Windows 7, both efi installations.  However, when I select Windows, I get the following before it boots into Windows:
/EndEntire
file path: /ACPI(a0341d0,0)/PCI(2,1f)/)UnknownMessaging(12)
/HD(1,800,32000,950e88571f64e74a,b5,8f)/File(\EFI\Microsoft\Boot)
/File(bootmgfw.efi)/EndEntire

Here's what I did, as root:
1.  cat GRUB_DISABLE_OS_PROBER="true" >> /etc/default/grub
2.  mount -t vfat /dev/sda1 /mnt/winboot
    grub2-probe \
      --target=hints_string /mnt/winboot/EFI/Microsoft/Boot/bootmgfw.efi
(output is:  --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1)
3.  create an entry in /etc/grub.d/40_custom, where EA39-C50F is the UUID of /dev/sda1:
	menuentry 'Microsoft Windows 7' {
	    insmod part_gpt
	    insmod fat
	    insmod search_fs_uuid
	    insmod chain
	    search --fs-uuid --no-floppy --set=root <output from #2> EA39-C50F
	    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
	}
4. grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Most of what's in #3 came from a webpage on dual booting Ubuntu and Windows 8.  I don't know if the insmod lines are appropriate for fedora 19.

What is the output of "os-prober"?

What do the entries created without GRUB_DISABLE_OS_PROBER look like?

If the GRUB_DISABLE_OS_PROBER line is removed from /etc/default/grub, then the non-working entry below is the output of os-prober:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager' {
          chainloader /EFI/Microsoft/Boot/bootmgfw.efi
          boot
}
### END /etc/grub.d/30_os-prober ###

A message is output that the file can't be found, and one ends up back in the boot menu.

What is the output of "os-prober"?

Is every single of the new lines necessary?

Comment 4 provides the output from os-prober as seen in /boot/efi/EFI/Fedora/grub.cfg.  If os-prober is run from the command line, as root, it produces the following output:
Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows

I don't know which lines in 40_custom are actually necessary.  As I said in comment 2, most of what's in the file was taken from the internet, and applies to Ubuntu and Windows 8.  What I know is that it worked for me, but produced an unexpected message.

I'm hoping someone can tell me how to eliminate the message, and what lines are actually necessary in 40_custom for Fedora and Windows 7.

Hedayat, FYI, this seems to be a pretty clear case where os-prober doesn't provide enough information to let grub2-mkconfig do the right thing ... but where there also is no way it could have done it the way grub2-mkconfig is and with the "API" to os-prober.

During the last hour, I've been paring down what I put in the 40_custom file, and then rebooting into Windows.

This is the smallest entry appended to 40_custom, that works.  It still gives the message (/EndEntire ... /EndEntire).

menuentry 'Microsoft Windows 7' {
    search --fs-uuid --no-floppy --set=root EA39-C50F
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

EA39-C50F is the UUID of the hard drive partition containing /EFI/Microsoft/Boot/bootmgfw.efi.

Isn't this bug related to bug #873207 , which I fixed but was reverted since the syntax wasn't supported in grub2? TBH, I forgot about it (and I was upset because of the revert). 

Please check comment #50 and see if it provides the needed information.

Since Fedora 19 release is over, I'll re-apply the patch and push updated os-prober packages to repos.

(In reply to Greta Watson from comment #8)
> This is the smallest entry appended to 40_custom, that works.

Thank you. That makes it clear what the problem is - and that no other problems are interfering.

(In reply to Hedayat Vatankhah from comment #9)
> Isn't this bug related to bug #873207

Related, yes. But not the same.

> Since Fedora 19 release is over, I'll re-apply the patch and push updated
> os-prober packages to repos.

If grub is ready to handle it, fine. But please don't break it - make sure it is ready.

Will this bug be fixed (os-prober side) with the same solution? It seems that the only missing item is the partition, which is provided by the fix in the other bug. 

OK, I'll wait. But if the current UEFI entries for grub2 are not bootable, applying the fix should not make things worse anyway?! 

I hope grub will support the new syntax very soon.

This bug still happens in Fedora 20 when using two different EFS.

Just a note: the os-prober bug was a Fedora bug, so os-prober in other distros already print the output which I fixed in the pending patch. So, while grub2 is not "READY", all distros are broken. The current os-prober output is unique to Fedora. I wonder how upstream grub2 is ignoring this bug completely.

Confirming that this still happens in Fedora 20 (in my case, on a fresh Lenovo T440s, UEFI secure boot, Windows 8, all on sda drive). Tagging as a CommonBug as I believe newer hardware is going to make this more common.

Comment 14: Are you using one EFS / EFI partition?

I still have this bug but I have two EFS / EFI partitions.

(In reply to Pedro Francisco from comment #15)
> Comment 14: Are you using one EFS / EFI partition?

Looks like a single EFS / EFI partition:

From 'fdisk -l':

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1E5A1267-A9B1-481C-B92B-79A94FC34F4A

Device           Start          End   Size Type
/dev/sda1         2048      2050047  1000M Windows recovery environment
/dev/sda2      2050048      2582527   260M EFI System
/dev/sda3      2582528      2844671   128M Microsoft reserved
/dev/sda4      2844672    198850559  93.5G Microsoft basic data
/dev/sda5    950480896    951197695   350M Windows recovery environment
/dev/sda6    951197696    976773119  12.2G Windows recovery environment
/dev/sda7    198850560    199874559   500M Microsoft basic data
/dev/sda8    199874560    950480895 357.9G Microsoft basic data

From "df -h":

Filesystem                          Size  Used Avail Use% Mounted on
/dev/mapper/fedora_feddenials-root   50G  4.2G   43G   9% /
devtmpfs                            5.9G     0  5.9G   0% /dev
tmpfs                               5.9G  376K  5.9G   1% /dev/shm
tmpfs                               5.9G  1.3M  5.9G   1% /run
tmpfs                               5.9G     0  5.9G   0% /sys/fs/cgroup
tmpfs                               5.9G  156K  5.9G   1% /tmp
/dev/sda7                           477M   73M  376M  17% /boot
/dev/sda2                           256M   61M  196M  24% /boot/efi
/dev/mapper/fedora_feddenials-home  300G  127G  158G  45% /home

And from "ls /boot/efi/EFI":

Boot  fedora  Lenovo  Microsoft

Let me know if there's anything else you want / need :)

Here's a stab at supplying the CommonBugs info for the wiki page:

CommonBugs title: Dual-booting from native UEFI mode to a previously existing OS such as Windows 8 from the GRUB menu may fail.

CommonBugs summary: While the Anaconda installer can successfully shrink an existing partition and install Fedora 20 in native UEFI mode, and the GRUB boot menu lists both the new Fedora 20 installation and the previously existing OS, attempting to boot the previously existing OS may fail consistently. The reason for this failure is because os-prober currently fails to set the correct boot options for the previously existing OS in the GRUB menu.

Known workarounds: You may be able to use your system's native UEFI boot menu to boot the previously existing OS directly. The native UEFI boot menu is often accessible at reboot time by interrupting the boot process and choosing to boot from a different device.

You may be able to manually edit the GRUB configuration to supply the parameters required to boot the previously existing OS.

Assessment of impact on Fedora users: As more Fedora users adopt UEFI-capable systems and install in UEFI mode, this is likely to become a more common install error.

(In reply to Greta Watson from comment #2)
> [...] I have been able to get a grub boot menu that will actually
> allow me to boot either Fedora or Windows 7, both efi installations.
> However, when I select Windows, I get the following before it boots
> into Windows:
But it does boot eventually?  Is SecureBoot enabled, disabled or unavailable?

> /EndEntire
> file path: /ACPI(a0341d0,0)/PCI(2,1f)/)UnknownMessaging(12)
> /HD(1,800,32000,950e88571f64e74a,b5,8f)/File(\EFI\Microsoft\Boot)
> /File(bootmgfw.efi)/EndEntire
I get the same (only HD parameters differ) *but* with one more line:

error: cannot load image

with ALT Linux 7.0.2 releases when SecureBoot is enabled; disabling it allows to chainload bootmgfw.efi just fine (os-prober-1.61-alt1 and grub2-2.00-alt20 result in a snippet that is virtually identical to your 40_custom one).

This error is fatal as in "any keypress or timeout returns to boot menu (or entry editor)".

> Most of what's in #3 came from a webpage on dual booting Ubuntu and Windows
Not sure if these two are related directly or being a next (SB chainload) problem but just in case...

Here's the corresponding Ubuntu bug regarding grub2:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1091464

Here's the ALT Linux one just in case (in Russian; SB-only problem):
https://bugzilla.altlinux.org/show_bug.cgi?id=29705

I haven't seen anything regarding openSUSE, hope to test myself.

(In reply to Hedayat Vatankhah from comment #13)
> I wonder how upstream grub2 is ignoring this bug completely.
Erm, http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=fba31b5f69f955dc6e7041a80de52979403a1042 is all I see so far.

The advanced boot section of the UEFI menu states that secure boot is enabled, platform key (PK) state is unloaded, and OS type is Other OS.  There does not seem to be a way to alter secure boot status.

Windows boots fine after the 4-line message has been on the screen a couple of seconds.

I am confirming this happens to me as well, just as Greta described it. Machine began with Windows 8.1 on a SSD drive. Fedora was installed to the machine's HDD with the EFI bootloader on the SSD.

Using grub, Fedora boots fine, but booting Windows first shows the 4 line message for 3-4 seconds then continues to boot successfully into Windows. Secure Boot is enabled.

This is on a Gigabyte P34G.

I have the same problem on a Lenovo Yoga 2 11 with Windows 8

Adding:

set root='(hd0, 2)'

... to /boot/grub2/grub.cfg solves the issue.

My drive is Partitioned as follows:

[root@fireball grub.d]# fdisk -l /dev/sda

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 498EE8A2-F8FE-4D64-B035-1A8ED2D4C1CE

Device           Start          End   Size Type
/dev/sda1         2048      2050047  1000M Windows recovery environment
/dev/sda2      2050048      2582527   260M EFI System
/dev/sda3      2582528      4630527  1000M unknown
/dev/sda4      4630528      4892671   128M Microsoft reserved
/dev/sda5      4892672    236165119 110.3G Microsoft basic data
/dev/sda6    901834752    954263551    25G Microsoft basic data
/dev/sda7    954263552    976773119  10.8G Windows recovery environment
/dev/sda8    236165120    237189119   500M Microsoft basic data
/dev/sda9    237189120    901834751   317G Linux LVM

Note:

I also added insmods which may not be needed, but it works now and I don't have time to investigate further :-(

menuentry 'Windows Boot Manager' {
          insmod part_gpt
          insmod chain
          insmod ntfs
          set root='(hd0, 2)'
          chainloader /EFI/Microsoft/Boot/bootmgfw.efi
          boot
}

I'm not sure if this warrants a separate bug report or not, but I'm having a similar problem. Like Greta, both my Windows 7 and Fedora installations go smoothly. When I turn on my computer \grub gives me the option of using Fedora or the Windows Boot Manager. I can boot into Fedora no problem UNTIL I choose to boot into Windows once. If I select Windows just once, it seems as though Grub is overwritten and I can never go back into Fedora, I can only go straight into Windows.

I should probably note that my computer was originally a Windows 8 machine which I downgraded to Windows 7, so it does have UEFI. However, I turned that off in the BIOS and so it should be able to boot.

This seems to be completely unrelated to this bug. And actually, it doesn't seem to be a Fedora bug at all. You should probably disable something in your Windows OS.

(In reply to Hedayat Vatankhah from comment #23)
> This seems to be completely unrelated to this bug. And actually, it doesn't
> seem to be a Fedora bug at all. You should probably disable something in
> your Windows OS.

I'm pretty sure everything in Windows is ok. Could you tell me what settings in Windows might be causing this?

Nothing in Windows itself, but usually there are some 'protector' applications installed which would overwrite boot loader if it is changed! Specially if you've installed vendor provided software suit, it is very likely that they've provided such software to make sure that your machine always boot Windows successfully!

Anyway, you got problems when you boot Windows; so there is nothing wrong with Fedora/grub!

Frank: it's also something that OEMs sometimes customize at the Windows or firmware level, though entirely *deleting* alternative boot entries is very rude.

If you have an option to just do a UEFI boot from the hard disk in question, that might work to make Fedora boot, as what it'll really do is hit the fallback boot path, which Fedora takes over when you install it. Recent Fedora will even re-generate its efibootmgr entry when booted via the fallback path.

added to F20 and F21 commonbugs.

I have similar issue, but oly with secureboot enabled. See bug 1144657

(In reply to Dan Scott from comment #14)
> Confirming that this still happens in Fedora 20 (in my case, on a fresh
> Lenovo T440s, UEFI secure boot, Windows 8, all on sda drive). Tagging as a
> CommonBug as I believe newer hardware is going to make this more common.

When I diasbling secureboot all booting as expected. Try it.

(In reply to lonelywoolf from comment #29)
> (In reply to Dan Scott from comment #14)
> > Confirming that this still happens in Fedora 20 (in my case, on a fresh
> > Lenovo T440s, UEFI secure boot, Windows 8, all on sda drive). Tagging as a
> > CommonBug as I believe newer hardware is going to make this more common.
> 
> When I diasbling secureboot all booting as expected. Try it.

Err, no. I expect to be able to keep secure boot enabled. If that's a limitation, it should be clearly documented as such.

But yor system botting properly with seccureboot disabled? If so, May be problem with signing keys?

I have the same problem on my Lenove S540 Touch laptop. Also the installer (ananconda?) does not detect Windows as an OS while trying to partition. It would be better if it showed up the Windows OS and data partitions too. These issues are present in CentOS as well.

solomon: not detecting your Windows install for the custom partitioning screen sounds like a different bug to this one, if you could report it separately that might be useful - thanks! file it against anaconda, and include the log files from /tmp while the installer is running, especially /tmp/storage.log and /tmp/program.log .

I believe this is appropriate to nominate as an F21 final release blocker under https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#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."

Discussed at 2014-11-05 blocker review meeting [1]. We decided the punt the decision. This requires some more testing to confirm. Will rediscuss at next meeting.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-05/

Those of you who tested this, can you please state clearly who of you used F21 installer (and which compose)? Do you have a single EFI system partition, or two? And your result is? Thanks.

I have tested with a clean installation of Windows 8 and Fedora 21 TC1. Everything installed over UEFI with SecureBoot enabled. I also tested a single shared ESP (default anaconda behavior), or a second separate ESP (using manual partitioning). In all cases, everything works absolutely flawlessly. I can boot both systems from grub and from UEFI one-time boot menu. I can toggle SecureBoot on and off and both systems still boot properly.

If you have any problems, please try with a clean Fedora 21 installation. If that doesn't work for some reason, please attach all appropriate log files.

Discussed at today's blocker review meeting [1]. Rejected as a blocker. This doesn't seem to be reproducible on F21. If it is, please update the bug and reproduce.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-12/

pjones: do you think we should close this?

As shown in bug 1170245, on a different machine I could not boot Windows with SecureBoot enabled (even though on a different machine I could). Maybe this bug is also just about SecureBoot issues?

Given the OP was about Win7 I rather doubt it - Win7 doesn't usually have SB enabled. But I think regardless it's best to just go with 1170245 in that case, I don't think this bug adds any useful data.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 '20'.

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