Bug 873207 - UEFI: No entry in grub2 menu for windows8 in dual boot setup install
UEFI: No entry in grub2 menu for windows8 in dual boot setup install
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
AcceptedFreezeException RejectedBlock...
: CommonBugs, Reopened
: 972355 (view as bug list)
Depends On: 974543
Blocks: F19-accepted/F19FinalFreezeException
  Show dependency treegraph
 
Reported: 2012-11-05 06:01 EST by Alexander Volovics
Modified: 2014-09-23 00:40 EDT (History)
17 users (show)

See Also:
Fixed In Version: os-prober-1.58-10.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-23 00:40:50 EDT
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)
/boot/efi/EFI/fedora/grub.cfg (4.70 KB, text/plain)
2012-11-05 09:42 EST, Alexander Volovics
no flags Details
results of os-prober in 'tail -f /var/log/messages' (13.16 KB, application/octet-stream)
2012-11-05 18:36 EST, Alexander Volovics
no flags Details
grub error (84.16 KB, image/jpeg)
2013-06-13 11:50 EDT, Kamil Páral
no flags Details
grub.cfg with invalid root for Windows files (3.81 KB, text/plain)
2013-06-13 11:51 EDT, Kamil Páral
no flags Details
journal output from os-prober (16.25 KB, text/plain)
2013-06-17 04:47 EDT, Kamil Páral
no flags Details
funny windows message that doesn't prevent boot, just displays for a second (80.28 KB, image/png)
2013-06-25 05:33 EDT, Kamil Páral
no flags Details

  None (edit)
Description Alexander Volovics 2012-11-05 06:01:06 EST
Description of problem:

On a laptop with UEFI+LegacyBIOS and 2 disks I installed Windows8 on the whole
second disk using UEFI (no secure boot) and F18 TC7 on the whole first disk
using UEFI (no LVM, default ext4 partioning).

F18 TC7 boots without problems but there is no entry for Windows8 in the
grub2 menu!

(Windows 8 boots correctly when selecting second disk from UEFI menu after
 pressing F12 key at boot).

Version-Release number of selected component (if applicable):

grub2-efi-2.00-12
grubby-8.20-1
anaconda-18.24-1

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:

A Windows8 entry in the grub2 menu

Additional info:
Comment 1 Mads Kiilerich 2012-11-05 08:34:12 EST
Please attach your grub.cfg. (And feel free to file a bug for README.Fedora not being uptodate or for grub2 efi not using /boot/grub2.)

Please provide the output of the commands
  rpm -q os-prober
  os-prober


Note also the upstream describes the current grub2 os-prober approach as having 'several shortcomings'. Fedora should not rely on it. http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config
Comment 2 Alexander Volovics 2012-11-05 09:42:51 EST
Created attachment 638673 [details]
/boot/efi/EFI/fedora/grub.cfg
Comment 3 Alexander Volovics 2012-11-05 09:45:54 EST
Output regarding os-prober:

# rpm -q os-prober
os-prober-1.55-1.fc18.x86_64

]# os-prober
  No volume groups found
Comment 4 Mads Kiilerich 2012-11-05 10:31:13 EST
Reassigning to os-prober.

os-prober should detect the OS somehow ... and it shouldn't report any warnings.

You can help by figuring out why /usr/libexec/os-probes/mounted/20microsoft doesn't detect your system and what it should do differently.
Comment 5 Hedayat Vatankhah 2012-11-05 12:31:42 EST
Please run os-prober and sent its output in /var/log/messages. (You can run tail -f /var/log/messages and then run os-prober in a separate terminal and sent the output of tail command).
Comment 6 Alexander Volovics 2012-11-05 18:36:01 EST
Created attachment 638961 [details]
results of os-prober in 'tail -f /var/log/messages'
Comment 7 Alexander Volovics 2012-11-05 18:38:03 EST
Layout of the 2 disks:

F18 TC7 on /dev/sda:
/dev/sda1 = /boot/efi             FAT32
/dev/sda2 = /boot                 Ext4
/dev/sda3 = /home                 Ext4
/dev/sda4 = /                     Ext4
/dev/sda5 = /swap                 Swap

Windows8 on /dev/sdb:
/dev/sdb1 = Windows Recovery      NTFS
/dev/sdb2 = Efi System            FAT32
/dev/sdb3 = Microsoft Reserved    NTFS
/dev/sdb4 = Basic Data            NTFS
Comment 8 Kamil Páral 2012-11-06 07:37:40 EST
The F18 Blocker criterion is:
The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working
https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
Comment 9 Hedayat Vatankhah 2012-11-06 15:13:28 EST
As Mads said, it'd be great if you help why /usr/libexec/os-probes/mounted/20microsoft can't find your Windows 8.
Please see if a "boot" directory exists in /dev/sdb3 or /dev/sdb4. Also see if you can mount /dev/sdb3 in Fedora. 
In the boot directory, there should be a "bcd" file. Provide the output of the following command after finding the bcd file. (also please give the path of the BCD file if you find it in any other place).

grep "W.i.n.d.o.w.s. .8" /THE/PATH/OF/THE/BCD/FILE
Comment 10 Alexander Volovics 2012-11-06 18:56:46 EST
1) disk description with 'parted':

Model: ATA ST9750420AS (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name                          Flags
 1      1049kB  316MB  315MB  ntfs         Basic data partition          hidden, diag
 2      316MB   420MB  105MB  fat32        EFI system partition          boot
 3      420MB   555MB  134MB               Microsoft reserved partition  msftres
 4      555MB   750GB  750GB  ntfs         Basic data partition

2) exploration of /dev/sdb2:

# mount /dev/sdb2 /mnt

# mount |grep /dev/sdb2
/dev/sdb2 on /mnt type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,
 shortname=mixed,errors=remount-ro)

# ls /mnt
EFI

]# ls /mnt/EFI/
Boot  Microsoft

]# ls /mnt/EFI/Boot/
bootx64.efi

# ls /mnt/EFI/Microsoft/
Boot

# ls /mnt/EFI/Microsoft/Boot/
BCD           BOOTSTAT.DAT  en-US  hu-HU        nb-NO      ro-RO       uk-UA
BCD.LOG       boot.stl      es-ES  it-IT        nl-NL      ru-RU       zh-CN
BCD.LOG1      cs-CZ         et-EE  ja-JP        pl-PL      sk-SK       zh-HK
BCD.LOG2      da-DK         fi-FI  ko-KR        pt-BR      sl-SI       zh-TW
bg-BG         de-DE         Fonts  lt-LT        pt-PT      sr-Latn-CS
bootmgfw.efi  el-GR         fr-FR  lv-LV        qps-ploc   sv-SE
bootmgr.efi   en-GB         hr-HR  memtest.efi  Resources  tr-TR

# grep "W.i.n.d.o.w.s. .8" /mnt/EFI/Microsoft/Boot/BCD
Binary file /mnt/EFI/Microsoft/Boot/BCD matches

# file /mnt/EFI/Microsoft/Boot/BCD
/mnt/EFI/Microsoft/Boot/BCD: MS Windows registry file, NT/2000 or above

# /usr/libexec/os-probes/mounted/20microsoft /mnt
20microsoft: debug: /mnt is not a MS partition: exiting

# /usr/libexec/os-probes/mounted/20microsoft /dev/sdb2
20microsoft: debug: /dev/sdb2 is not a MS partition: exiting

Is this helpfull? 
I don't quite know how I should use '20microsoft'.
Comment 11 Hedayat Vatankhah 2012-11-07 00:34:22 EST
Yes, thanks for the provided information. os-prober currently doesn't know anything about EFI! I'm going to fix this, but would you please try to mount /dev/sdb3 and /dev/sdb4 to see if there are any Boot directories inside them? (and also a BCD file)? Also please see if there are any "bootmgr" file/directory inside them.
Comment 12 Mads Kiilerich 2012-11-07 05:17:58 EST
EFI systems always have a built-in boot manager. The boot loader installed by Fedora is only one of several boot loaders. It is thus (to put it lightly) questionable whether os-prober/grub2 should list other EFI boot targets in the Fedora boot menu.

I don't consider this a blocker.

(grub2 upstream also supports installing multiple boot loaders for the same OS by specifying alternative bootloader-ids. The 'fedora' id is however hardcoded in f18.)
Comment 13 Kamil Páral 2012-11-07 05:41:49 EST
But we should also mention that on many systems the UEFI boot menu is not displayed by default and you have to know a keyboard shortcut to display it. Our grub, OTOH, is displayed always. So if we don't have UEFI items displayed in grub, it will definitely happen that some users won't be able to boot their UEFI systems. Because they won't see it in grub, and they won't get the idea that they should display a native UEFI boot menu (lots of them will not even know it's present).
Comment 14 Mads Kiilerich 2012-11-07 06:14:02 EST
Yes, that is valid input as well.

But I also assume all users need to use their boot menu to install Fedora in the first place, so it is not completely unknown to them.

Granted, there would still be a usability issue becuase users don't know how to use their system. IMO that would make this issue nice-to-have, but not necessarily a blocker.

It is also not a design decision that the grub2 menu always is shown. It is a known bug / regression. We shouldn't base other decisions on that.

(In the bigger perspective: UEFI and the latest kernels should makes it possible to boot the kernel directly without messing with a separate boot loader and configuration method for each os. Instead we now have shim that replaces the "native" key enrolment and grub that duplicates a lot of kernel functionality ... and apparently now also a real need for grub duplicating the full UEFI boot menu functionality. Not exactly an elegant architecture.)
Comment 15 Alexander Volovics 2012-11-07 06:59:19 EST
First the info that Hedayat asked for.

1) sdb3 is a MSR (Microsoft Reserved Partition) and does not contain
   anything relevant. Microsoft seems to require a MSR on every GPT
   disk to reserve space for future eventualities. It is created
   automatically at install and is not visible by default in Win 8.
   
2) Searching in sdb4:

# mount /dev/sdb4 /mnt

# find /mnt -name 'bootmgr'
/mnt/bootmgr
/mnt/Windows/Boot/PCAT/bootmgr
/mnt/Windows/WinSxS/x86_microsoft-windows-b..re-bootmanager-pcat_31bf3856ad364e35_6.2.9200.16384_none_bfd4be64849747cb/bootmgr

# find /mnt -name 'BCD'
/mnt/Windows/Boot/DVD/EFI/BCD
/mnt/Windows/Boot/DVD/PCAT/BCD
/mnt/Windows/WinSxS/amd64_microsoft-windows-b..environment-dvd-efi_31bf3856ad364e35_6.2.9200.16384_none_2e113eba0e4752fa/BCD
/mnt/Windows/WinSxS/amd64_microsoft-windows-b..nvironment-dvd-pcat_31bf3856ad364e35_6.2.9200.16384_none_f2e178c7ba42dfb8/BCD

# find /mnt -name 'Boot'
/mnt/Windows/Boot
/mnt/Windows/System32/Boot

Secondly I agree completely with the last paragraph of comment 14.
I think the whole situation with regard to UEFI is messy and that
grub complicates the whole issue unnecessarily.
I had some vague idea that UEFI could present the options at
boot automatically and in that case grub would not be necessary.
(But the UEFI boot menu works OK. I just reported that the grub
 menu did not contain a Windows 8 item)
Comment 16 Hedayat Vatankhah 2012-11-07 17:44:48 EST
Thanks for the provided information. Now, the following questions should be answered:
1. Should os-prober detect such OSes?
2. Where should os-prober find Windows 8? /dev/sdb2 or /dev/sdb4?
3. Can gdb chainload Windows 8 in this setup? Which partition it should use (/dev/sdb2 or /dev/sdb4)? (I'm not sure of my understanding of EFI boot method).
Comment 18 Tim Flink 2012-11-30 14:46:02 EST
I'm -1 blocker on this. While there is a release criterion about being able to dual-boot with windows, it doesn't sound like this bug actually prevents dual booting, it just makes dual-booting more difficult.
Comment 19 Adam Williamson 2012-12-03 13:21:28 EST
Discussed at 2012-12-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker-review-1.2.2012-12-03-17.25.log.txt . Though this sort of hits the criterion "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working" , that criterion was really written to BIOS expectations and doesn't necessarily apply to UEFI configurations (see above discussion). It is very questionable whether in a UEFI configuration, an OS's bootloader should offer to boot another OS. At best this is a policy decision not a blocker bug.

Given this, this bug is rejected as a blocker, and we may revise the relevant criterion to make this clearer.
Comment 20 Kamil Páral 2012-12-14 04:57:25 EST
I have tested Windows 8 x32 and Fedora 18 (anaconda 18.37.2) in BIOS mode. I shrunk the ntfs partition prior installation using gparted. Everything went fine and Windows 8 is displayed in GRUB and it boots. That means this bug is really related to just UEFI mode, not BIOS mode.
Comment 21 Adam Williamson 2012-12-14 16:20:55 EST
confirms our -1, then, and this arguably isn't a bug at all. in the UEFI design, bootloaders are really kinda intended to be OS-specific.
Comment 22 Kamil Páral 2013-01-15 06:54:14 EST
Adam: Should we mark as ReleaseNotes instead of CommonBugs?
Comment 23 Adam Williamson 2013-01-15 13:30:46 EST
that would be my call, but it would be best to check with pjones on what he thinks is the skinny here. he has a better understanding than me, I'm just the monkey.
Comment 24 Hedayat Vatankhah 2013-05-05 14:57:27 EDT
This bug is supposed to be fixed in os-prober 1.58. You can find the latest rpm in rawhide and updates for F17+ in a few minutes.
Comment 25 Hedayat Vatankhah 2013-05-21 15:18:00 EDT
Can anybody see if latest os-prober package correctly detects windows 8 in the mentioned setup?
Comment 26 A.J. Werkman 2013-06-06 09:08:49 EDT
My scenario is the other way around (W8 in EFI and F19 in Bios), but the result is the same, Win8 can not be booted after F19 installation.

Reported as bug #971255.

Conclusion: F19-TC1 installation does not detect Win8 with os-prober-1.58-1.fc19.x86_64
Comment 27 Adam Williamson 2013-06-06 13:30:31 EDT
AJ: your situation is not the same as this at all. Please follow up in your bug rather than here. Thanks!
Comment 28 Adam Williamson 2013-06-06 13:31:15 EDT
If anyone else is able to test a *native UEFI* F19 install alongside a *native UEFI* Windows install, that'd be helpful. Thanks.
Comment 29 Kamil Páral 2013-06-07 06:58:03 EDT
(In reply to Adam Williamson from comment #28)
> If anyone else is able to test a *native UEFI* F19 install alongside a
> *native UEFI* Windows install, that'd be helpful. Thanks.

Tested. Both systems are visible in UEFI menu and can be started, but only Fedora is visible in GRUB menu.

It seems that os-prober correctly detects the system, but grub2-mkconfig don't create the relevant menu item:

# os-prober 
Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg 
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.9.4-300.fc19.x86_64
Found initrd image: /boot/initramfs-3.9.4-300.fc19.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-9bd3a783cfb4d21967a70d451294cb7c
Found initrd image: /boot/initramfs-0-rescue-9bd3a783cfb4d21967a70d451294cb7c.img
Found Windows Boot Manager on Microsoft/Boot/bootmgfw.efi
Windows Boot Manager is not yet supported by grub-mkconfig.
done
# rpm -qf `which grub2-mkconfig`
grub2-tools-2.00-18.fc19.x86_64
# rpm -q os-prober
os-prober-1.58-1.fc19.x86_64

Reassigning.
Comment 30 Adam Williamson 2013-06-10 19:17:03 EDT
*** Bug 972355 has been marked as a duplicate of this bug. ***
Comment 31 Adam Williamson 2013-06-10 19:18:37 EDT
mjg59 came across this apparently independently and filed 972355 with a patch; pjones asked him to send it across for a build of grub2 he's planning to do soon. So hopefully we should see this go to MODIFIED soon. If anyone wants to try the patch out, it's attached to 972355.
Comment 32 Fedora Update System 2013-06-13 10:50:01 EDT
grub2-2.00-19.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grub2-2.00-19.fc19
Comment 33 Kamil Páral 2013-06-13 11:50:05 EDT
Created attachment 760795 [details]
grub error

Still doesn't work with grub2-2.00-19.fc19. It seems that the root is not set correctly.

Two issues here:
1. If I look into /boot/efi/EFI, there is no Microsoft/ directory. Anaconda seems to have created a *second* EFI partition during installation.

# parted /dev/sda p
Model: ATA ST500DM002-1BD14 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name                          Flags
 1      1049kB  316MB  315MB   ntfs         Basic data partition          hidden, diag
 2      316MB   420MB  105MB   fat32        EFI system partition          boot
 3      420MB   555MB  134MB                Microsoft reserved partition  msftres
 4      555MB   451GB  450GB   ntfs         Basic data partition
 5      451GB   451GB  210MB   fat16        EFI System Partition          boot
 6      451GB   451GB  524MB   ext4
 7      451GB   500GB  48.8GB                                             lvm

# findmnt
TARGET                           SOURCE     FSTYPE         OPTIONS
/                                /dev/mapper/fedora_dhcp--29--166-root
                                            ext4           rw,relatime,seclabel,data=ordered
├─/proc                          proc       proc           rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc     systemd-1  autofs         rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct
├─/sys                           sysfs      sysfs          rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/kernel/security         securityfs securityfs     rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/selinux              selinuxfs  selinuxfs      rw,relatime
│ ├─/sys/fs/cgroup               tmpfs      tmpfs          rw,nosuid,nodev,noexec,seclabel,mode=755
│ │ ├─/sys/fs/cgroup/systemd     cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgro
│ │ ├─/sys/fs/cgroup/cpuset      cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,cpuset
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,cpuacct,cpu
│ │ ├─/sys/fs/cgroup/memory      cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,memory
│ │ ├─/sys/fs/cgroup/devices     cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/freezer     cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/net_cls     cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,net_cls
│ │ ├─/sys/fs/cgroup/blkio       cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,blkio
│ │ └─/sys/fs/cgroup/perf_event  cgroup     cgroup         rw,nosuid,nodev,noexec,relatime,perf_event
│ ├─/sys/fs/pstore               pstore     pstore         rw,nosuid,nodev,noexec,relatime
│ ├─/sys/firmware/efi/efivars    efivarfs   efivarfs       rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/debug            debugfs    debugfs        rw,relatime
│ ├─/sys/kernel/config           configfs   configfs       rw,relatime
│ └─/sys/fs/fuse/connections     fusectl    fusectl        rw,relatime
├─/dev                           devtmpfs   devtmpfs       rw,nosuid,seclabel,size=1957616k,nr_inodes=489404,mode=755
│ ├─/dev/shm                     tmpfs      tmpfs          rw,nosuid,nodev,seclabel
│ ├─/dev/pts                     devpts     devpts         rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000
│ ├─/dev/mqueue                  mqueue     mqueue         rw,relatime,seclabel
│ └─/dev/hugepages               hugetlbfs  hugetlbfs      rw,relatime,seclabel
├─/run                           tmpfs      tmpfs          rw,nosuid,nodev,seclabel,mode=755
│ └─/run/user/1000/gvfs          gvfsd-fuse fuse.gvfsd-fus rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
├─/tmp                           tmpfs      tmpfs          rw,seclabel
└─/boot                          /dev/sda6  ext4           rw,relatime,seclabel,stripe=4,data=ordered
  └─/boot/efi                    /dev/sda5  vfat           rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,er


2. The root is not set correctly either way. From grub.cfg it defaults to sda6, but it should be set to sda5 (if Windows efi files were on the same partition) or sda2 (where the files are now).

If I put "set root='hd0,gpt2'" into Windows boot menu item in grub, I can boot Windows.
Comment 34 Kamil Páral 2013-06-13 11:51:10 EDT
Created attachment 760798 [details]
grub.cfg with invalid root for Windows files
Comment 35 Matthew Garrett 2013-06-13 11:54:10 EDT
os-prober doesn't provide the information required to determine a root, so this is only going to work if you have a single ESP.
Comment 36 Adam Williamson 2013-06-13 12:07:03 EDT
I thought we'd fixed anaconda always creating a new ESP? Hum.
Comment 37 Kamil Páral 2013-06-13 12:07:43 EDT
Even if I had a single EFI partition, I guess that wouldn't work, because grub root is set to point to boot partition (sda6), not EFI partition (sda5). So we need the root definition anyway.

Can os-prober be modified to include necessary information? Or should I re-test clean Windows install and report bug against anaconda if it really creates a second EFI partition (I might have messed up something in my first attempt)?
Comment 38 Fedora Update System 2013-06-13 14:07:20 EDT
Package grub2-2.00-19.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing grub2-2.00-19.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10773/grub2-2.00-19.fc19
then log in and leave karma (feedback).
Comment 39 Kamil Páral 2013-06-14 08:06:11 EDT
(In reply to Adam Williamson from comment #36)
> I thought we'd fixed anaconda always creating a new ESP? Hum.

No. Reported as bug 974543.

However, I don't think that it will fix this issue (see comment 37). I believe os-prober needs to report partitions as well.
Comment 40 Hedayat Vatankhah 2013-06-14 10:46:41 EDT
There is a problem. os-prober IS expected to provide a more detailed output for EFI (according to the code) (it should generate a line which ends in ":efi"). Would you please provide the complete output of os-prober and also its complete log in syslog when run? (/var/log/messages by default).
Comment 41 Fedora Update System 2013-06-14 15:58:55 EDT
grub2-2.00-20.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grub2-2.00-20.fc19
Comment 42 Kamil Páral 2013-06-17 04:47:17 EDT
Created attachment 761957 [details]
journal output from os-prober

Here we go.

# os-prober 
Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows
# rpm -q os-prober
os-prober-1.58-1.fc19.x86_64
Comment 43 Fedora Update System 2013-06-18 02:12:34 EDT
grub2-2.00-20.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 44 Adam Williamson 2013-06-18 03:40:33 EDT
For the record, this didn't make TC5, but will be in the next build (TC6 most likely). A net install of TC5 should pick it up in a day or so.
Comment 45 Kamil Páral 2013-06-18 06:44:46 EDT
Reopening. We currently depend on bug 974543 (and even then some further patch from os-prober might be needed to solve this problem).

Hedayat, what do you think of the os-prober output?
Comment 46 Hedayat Vatankhah 2013-06-18 17:27:21 EDT
Please check this update and report the results:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5518622

Thanks!
Comment 47 Fedora Update System 2013-06-19 06:35:06 EDT
os-prober-1.58-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/os-prober-1.58-2.fc18
Comment 48 Fedora Update System 2013-06-19 06:35:24 EDT
os-prober-1.58-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/os-prober-1.58-2.fc17
Comment 49 Fedora Update System 2013-06-19 06:35:37 EDT
os-prober-1.58-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/os-prober-1.58-2.fc19
Comment 50 Kamil Páral 2013-06-19 06:40:45 EDT
With os-prober-1.58-2.fc19 it prints the partition correctly:

# os-prober 
/dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

However, grub2-mkconfig seems to not understand that format and it creates this menu item:

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

Which is obviously invalid. This is on a system affect by bug 974543, therefore it has two EFI partitions. But:
1) it could work even with two EFI partitions, just if grub2-mkconfig understood the syntax properly and provided "set root=" command.
2) even with a single EFI partition this might not work. I checked the grub.cfg properly once again, and all Fedora menu items have "set root=" command, but Windows item has none. Maybe grub is intelligent enough to default to the first EFI partition if no root is set? No idea.

Peter, your comments?

Proposing as FreezeException for os-prober and possible grub2 builds.
Comment 51 Adam Williamson 2013-06-19 15:05:10 EDT
Discussed at 2013-06-19 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . Accepted as a freeze exception issue: we really want UEFI dual/multi boot to work if we can, and current behaviour is clearly incorrect. Cannot be fixed post-release.
Comment 52 Fedora Update System 2013-06-20 21:58:03 EDT
os-prober-1.58-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 53 Kamil Páral 2013-06-25 05:32:03 EDT
This is fun. I tried with a clean Win 8 install and F19 RC1. It works! It contains os-prober 1.58-1, and even though grub2-mkconfig doesn't specify "set root=", grub seems to automagically pick the first EFI partition as the root device. It displays a funny Windows message before booting, but everything works great.

But wait! With os-prober 1.58-2, this is broken. grub2-mkconfig doesn't understand the new os-prober syntax, and therefore the boot menu item no longer works.

Hedayat, we need to hold that os-prober update until grub2-mkconfig understands it. Otherwise netinst users would end up with a non-functional windows boot menu, but Live/DVD users would be fine.

Peter Jones, we need to update grub2-mkconfig to understand the new/fixed os-prober syntax. Can you please do that?
Comment 54 Kamil Páral 2013-06-25 05:33:12 EDT
Created attachment 764996 [details]
funny windows message that doesn't prevent boot, just displays for a second
Comment 55 Hedayat Vatankhah 2013-06-25 14:39:26 EDT
The os-prober update won't be pushed to stable repository before F19 release normally. It can be included in Fedora release version if picked as an exception. Therefore, it is enough to pull it as an exception with the expected grub2 update.
Comment 56 Adam Williamson 2013-06-25 15:13:32 EDT
We know that. What Kamil wants to ensure is that the os-prober update is not pushed stable before a matching grub2 build is done. Otherwise network installs will behave worse.
Comment 57 Fedora Update System 2013-06-29 14:09:21 EDT
os-prober-1.58-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 58 Fedora Update System 2013-06-30 21:44:52 EDT
os-prober-1.58-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 59 Kamil Páral 2013-07-02 04:50:47 EDT
As I was afraid. New os-prober has been pushed to F19 stable repository and until we release fixed grub2, all network dual-boot installs will be broken.
Comment 60 Adam Williamson 2013-07-02 12:38:10 EDT
As it's release week and lots of people will be testing and reviewing F19 now, we really need to fix this SNAFU. So I'm fixing it. pjones is on vacation, I believe, so I'm building a -3 with the patch from -2 reverted. Let's get it pushed stable ASAP. We can do a -4 with the -2 patch enabled again *once a matching grub2 is built* and not before.
Comment 61 Fedora Update System 2013-07-02 13:06:38 EDT
os-prober-1.58-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/os-prober-1.58-3.fc19
Comment 62 Fedora Update System 2013-07-02 23:29:42 EDT
os-prober-1.58-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 63 Hedayat Vatankhah 2013-11-23 04:25:39 EST
Another release is over, and grub2 bug is still not fixed and my patch is pending forever...! And, my patch just recovers the "upstream" behavior.
Comment 64 Adam Williamson 2013-11-23 12:51:46 EST
How do you mean 'over'? F20 isn't released or even frozen yet.
Comment 65 Hedayat Vatankhah 2013-12-02 06:03:13 EST
Because considering how it has gone till now, IMHO it is very unlikely that it will happen until F20 freeze. I wonder how much I should keep the patch which fixes a Fedora-only bug because upstream grub doesn't recognize the syntax of upstream os-prober for a long time!
Comment 66 Fedora End Of Life 2013-12-21 10:10:48 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 
'version' of '18'.

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 prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 to Fedora 18's end of life.

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 67 Adam Williamson 2013-12-21 14:49:30 EST
I think this still needs to be open, right? I'm losing track.
Comment 68 Kamil Páral 2014-01-06 10:56:58 EST
I have Win7 UEFI + F20 UEFI and I see Windows in my grub menu. But I configured anaconda to use the same ESP (which was not the default in the time of my install) and it's Win7, not Win8. I could retest this soon, if there is desire (i.e. some developer willing to fix this, if I find a problem). We will definitely test this in the F21 cycle.
Comment 69 Hedayat Vatankhah 2014-04-24 03:51:15 EDT
Still not fixed in grub2?
Comment 70 Fedora Update System 2014-09-09 11:36:57 EDT
os-prober-1.58-10.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/os-prober-1.58-10.fc21
Comment 71 Fedora Update System 2014-09-09 22:14:11 EDT
Package os-prober-1.58-10.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing os-prober-1.58-10.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10526/os-prober-1.58-10.fc21
then log in and leave karma (feedback).
Comment 72 Fedora Update System 2014-09-23 00:40:50 EDT
os-prober-1.58-10.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

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