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:
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
Created attachment 638673 [details] /boot/efi/EFI/fedora/grub.cfg
Output regarding os-prober: # rpm -q os-prober os-prober-1.55-1.fc18.x86_64 ]# os-prober No volume groups found
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.
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).
Created attachment 638961 [details] results of os-prober in 'tail -f /var/log/messages'
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
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
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
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'.
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.
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.)
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).
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.)
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)
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).
(In reply to comment #16) 1) is not for me to decide and I can not answer 2) and 3) but the same problem has been noticed at ubuntu, debian, opensuse, arch-linux, etc. and it seems solutions are being worked on: https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1017880 http://lists.debian.org/debian-boot/2012/10/msg00185.html http://forums.opensuse.org/english/other-forums/development/programming-scripting/479451-latest-os-prober-updategrub-development.html http://cli-apps.org/content/show.php/GRUB-EFI+os-prober-efi?content=154813 http://sourceforge.net/projects/os-prober-efi/
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.
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.
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.
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.
Adam: Should we mark as ReleaseNotes instead of CommonBugs?
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.
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.
Can anybody see if latest os-prober package correctly detects windows 8 in the mentioned setup?
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
AJ: your situation is not the same as this at all. Please follow up in your bug rather than here. Thanks!
If anyone else is able to test a *native UEFI* F19 install alongside a *native UEFI* Windows install, that'd be helpful. Thanks.
(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.
*** Bug 972355 has been marked as a duplicate of this bug. ***
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.
grub2-2.00-19.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/grub2-2.00-19.fc19
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.
Created attachment 760798 [details] grub.cfg with invalid root for Windows files
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.
I thought we'd fixed anaconda always creating a new ESP? Hum.
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)?
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).
(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.
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).
grub2-2.00-20.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/grub2-2.00-20.fc19
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
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.
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.
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?
Please check this update and report the results: http://koji.fedoraproject.org/koji/taskinfo?taskID=5518622 Thanks!
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
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
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
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.
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.
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.
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?
Created attachment 764996 [details] funny windows message that doesn't prevent boot, just displays for a second
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.
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.
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.
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.
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.
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.
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
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.
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.
How do you mean 'over'? F20 isn't released or even frozen yet.
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!
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.
I think this still needs to be open, right? I'm losing track.
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.
Still not fixed in grub2?
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
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).
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.