Description of problem: Command <grub2-mkconfig -o /boot/grub2/grub.cfg> finds Windows partition, adds to grub menu, but menu entry will not boot. Version-Release number of selected component (if applicable): os-prober 1.48.1.fc16 grub2 1.99.0.2.fc16 How reproducible: Steps to Reproduce: 1. Take Working Windows System and using Windows native partition tools create un-partitioned space for Fedora. 2. Install Fedora selecting free-space option and defaults for Graphical Desktop 3. After Firstboot open a terminal and run "yum install os-prober". 4. Run Command grub2-mkconfig -o /boot/grub2/grub.cfg 5. Reboot and attempt to select and boot windows. - system will revert to bios prompts and grub menu Actual results: Windows Never Boots Expected results: Windows should boot. Additional info:
Created attachment 521157 [details] fdisk -l output
Created attachment 521169 [details] grub.cfg
FWIW, I'm unable to reproduce this particular failure. Here's what I did: Install Windows 7 Ultimate 64-bit in KVM VM (using default Windows 7 OS Type) During installation of Windows, I did custom partitioning and left some unused space for Fedora. Boot F16-Alpha LiveCD, and install to hard drive, choosing "Replace Existing Linux System" in the partitioning dialog (and clicked to review the layout to make sure it wasn't destroying my NTFS partitions, which it wasn't - made no changes here) Reboot, Windows was not in the menu (which is another bug) Following the steps in comment #0 and rebooting, Windows was now in the menu and boots fine.
Good to know. The original problem was with WindowsXPSP3 and F16-Beta.TC1-DVD.
Created attachment 521757 [details] grub.cfg - not just a fpaste url
Created attachment 521758 [details] fdisk -l
Robert, does it work if you remove the drivemap line?
No it does not work any better with the drivemap command removed.
Good to know that you were testing with Windows XP. The bootloader between Winsows XP and Windows 7 is very different. I tried the same test that I tried above, except with a (different) VM that I installed with WinXP Pro and some free space, and it worked fine as well. I'll attach the grub.cfg that it came up with for me.
Created attachment 522036 [details] grub.cfg that works
Jon I am not seeing any differences between your grub.cfg and mine. I am curious as to what VM engine you are using. I am using Fedora default libvirtd/qemu-kvm on an F14_x86_64 host system.
Created attachment 523480 [details] fdisk -l from working fc16 grub1 dual boot system
Created attachment 523481 [details] menu.lst from working fc16 grub1 dual boot system
Created attachment 523482 [details] sector63 from dd command from working fc16 grub1 dual boot system
Created attachment 523483 [details] sector2048 from dd command from working fc16 grub1 dual boot system
Created attachment 523484 [details] fdisk -l from non-working fc16 grub2 dual boot system
Created attachment 523485 [details] brug.cfg from non-working fc16 grub2 dual boot system
Created attachment 523486 [details] sector63 from dd command from non-working fc16 grub2 dual boot system
Created attachment 523487 [details] sector2048 from dd command from non-working fc16 grub2 dual boot system
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I'm having what I think is a similar issue: I've installed Fedora 16 beta RC1 and let anaconda shrink the MS-Windows XP NTFS partition and install Fedora side by side for a dual boot. The boot loader menu then did not contain an option for the windows partition (I opened a separate bug on that) so I ran the grub reconfiguration like mentioned in comment #1. Now I have a Windows XP setting in the boot menu, but when I try to boot it I get a BSOD. XP was working fine before the installation, and I also installed VirtualBox in Fedora and set it up to boot the raw disk - and that boots the XP just fine.
Ok this problem still exists in F16-Beta.RC2 for me when installing fedora into an existing windowsxp vm.
Final Release Criteria Item 6 "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 " Is not met in this test case.
oded: I think yours is a different issue; if you get a BSOD that at least means Windows' bootloader fired and got some distance into Windows startup, as you only get BSODs from Windows' kernel, not from the bootloader. Bob's issue, as I understand it, happens before that: the Windows bootloader simply isn't firing properly.
Discussed at 2011-09-30 blocker review meeting. Agreed we need more detail here, and as things stand, it would be unlikely to be accepted as a blocker, as we more require _some_ dual boot tests to work than absolutely all of them to work. Bob, if you can do a bit more testing - see if you can reproduce with a clean VM and fresh Windows install - that would help. thanks! We will re-visit this next week.
I'll provide some additional test coverage as well, probably tomorrow or Tuesday (depending on Real Life(TM) obligations). As I have a MS subscription that allows me access to pretty much any Windows OS, I need to know EXACTLY what scenario to test. Thus far, I've done Win7 Ultimate and WinXP Pro without issue (but not Vista). Is there some other scenario that I'm missing (note that I'll also refresh my Fedora install media before trying again)
Also, regarding comment #21, that wouldn't be a blocker. NTFS resize is dicey at best, and we don't support it as a release-blocking criteria. So if you haven't, please open a separate bug (and I can test that scenario as well, but I don't hold high hopes for it working) for that.
Jon can you start with an FC14-x86_64 host system and create a qemu/kvm guest using VMM which is 32GB img with WindowsXPSP2 installed and upgraded with all Microsoft Updates. Then using Partition Magic or some other native Windows partitoning tool shrink the 32gb windows plattter to allow for 12gb of free space. Then try using FC16.Beta-RC4 to install Fedora. If the os-prober feature which is now imcluded in RC4 works you'll have a grub2 menu with a WIndows OS option that fails to boot.
I can confirm this bug using the steps described in comment #28 (except that I didn't use some windows thing to resize NTFS since I don't have access to such a thing and instead made the filesystem small to begin with) My other test setup (which works successfully) is installed using an F15 hypervisor and WinXP Pro with SP3. I'll see if installing with the SP3 media to start with makes a difference (perhaps there was a bugfix to the Windows bootloader?)
And it gets more interesting. On a F15 hypervisor performing the same steps in I did on the F14 hypervisor, I can't reproduce this. I'll attach the domain XML from both, but I'm not entirely sure that'll help - the problem may lie somewhere like gPXE or SeaBIOS or such. I'm also not sure how to further debug - pointers?
Created attachment 526609 [details] Domain XML from F15
Created attachment 526610 [details] Domain XML from F14
Reading Jon's latest above I'd say the issue lies in the resize step -- I'll ahve to try with a small windows partition to start and see what happens.
No, it's not the resize step - I can reproduce this on F14, but not F15 as the host system. So the problem lies in F14, not in F16.
Bob: "Reading Jon's latest above I'd say the issue lies in the resize step" note that he said he *could* reproduce the bug, so the difference in how he did resizing is not the issue. The issue seems to be caused by using F14 as the VM host.
Discussed at the 2011-10-07 blocker review meeting. Rejected as a blocker as the trigger circumstances appear to be very specific, and not entirely F16-related: seems to be to do with using F14 as the VM host. The criterion in question is intentionally worded slightly loosely - "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" - it doesn't really require *every* attempt to install alongside Windows to be successful, just for the installer to be capable of doing it. Which it clearly is, as it works in most situations tested so far, this specific one does not work.
My schedule didn;t permit me to make blocker meeting, but I would concur based on work of Jon Stanley. I would ask someone with Centos 5 or Centos 6 as the vm host to test this and make sure it is not a pre Fc15 os issue? But that still while NTH isn;t a blocker.
Has this issue been solved? Or can it be reproduced now - especially when f14 no longer is supported? If so: Is it also an f17 issue?
Response to Mads Kiilerich post 2012-04-16 from Bob Lightfoot. 1. Bad News, I no longer have the F14 Virtual Host on which this bug originally occurred for me. 2. Good news I do now have a Centos 6.2 Virtual Host on which to attempt and recreate the problem with F16 DVD Media and an Initially XP Guest VM. 3. Bad News my $dayjob is on a maintenance shutdown week thru 2012-04-23 which demands much of my time and attention so I won't be testing soon - sorry. 4. Good News -- I've not heard of any XPSP3 / FC17 Dual Boot issues in my skimming of Bugzilla and Test Mailing List. Final Note : I will re-test as soon a schedule permits and post results. If no one else is having issues my vote we be that this is again a non-blocker for F17.
Ok - we will wait for more information.
This may be a case of drivemap problem I've just fixed upstream
(In reply to comment #41) > This may be a case of drivemap problem I've just fixed upstream This fix can be tested with an unofficial scratch build with a snapshot from bzr: grub2-2.0-0.37.beta6.4462.fc17 at http://koji.fedoraproject.org/koji/taskinfo?taskID=4152623
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug was reproduced during the F18 testing cycle and resolved there.