Bug 124802 - Can not boot in Windows XP from GRUB
Summary: Can not boot in Windows XP from GRUB
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: grub
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL: http://savannah.gnu.org/bugs/?func=de...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-30 13:00 UTC by Nicolas Mailhot
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-06-02 20:13:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Various command outputs (25.38 KB, text/plain)
2004-05-30 13:01 UTC, Nicolas Mailhot
no flags Details

Description Nicolas Mailhot 2004-05-30 13:00:31 UTC
Description of problem:

This is yet another dual boot problem report.
Unlike the other ones it is *not* anaconda-related. The windows
installation was created after the FC2 one, on a dedicated disk,
scratching all previous partitions.

It should not be a hardware or grub config problem - the same
configuration (same disks/controllers) used to work last year
(obviously all the partitions have been redefined since)

Both the linux and Windows installation are sane - telling the bios to
boot from the windows disk works, booting in rawhide via grub also works

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

grub-0.94-5

How reproducible:

always

Steps to Reproduce:
1. select the Windows entry in grub menu
  
Actual results:
hang (no activity, USB keyboard stuck, etc)

Expected results:

Windows boot

Additional info:

See the attached file for lots of debug info

Comment 1 Nicolas Mailhot 2004-05-30 13:01:21 UTC
Created attachment 100703 [details]
Various command outputs

Comment 2 Jeremy Katz 2004-06-01 20:18:48 UTC
Shouldn't it be
title Ouine
        debug
        map (hd0) (hd2)
        map (hd2) (hd0)
        rootnoverify (hd0,0)
        makeactive
        chainloader +1

instead?

Comment 3 Nicolas Mailhot 2004-06-01 22:02:00 UTC
Well, this one produces an error 13, invalid executable format

The entry I gave is the one I used when the system was FC1 + Windows
2000 (don't remember which software made the partitions back then), so
it might have worked :(

I'm a bit suspicious about your rootnoverify (hd0,0), I think grub
mapping is for external use only (ie grub will always use original
disk names regardless of maps)

I know the external ATA controler makes some systems mad - half the
OSs/disk utilities enumerate in bio order (on-mobo VIA then SII680),
and the other half in PCI id order (SII680 then VIA). 

I'm half of a mind to try all the possible map & root permutations,
but surely smart human beings like us should be able to type the right
one just by looking at the debug info, right ?

(and what if *none* of them work ?)

Comment 4 Nicolas Mailhot 2004-06-02 20:13:08 UTC
Well, I solved it
Not cleanly, I'm afraid, I cheated a bit:

1. replaced all references to (hd0,0) with (hd1,0)
(it just happens hda1 and hdc1 are a raid1, and regardless of the
drive ordering chosen by BIOS/Windows/Linux (hd1,0) *always* hits hda1
or hdc1 (I shudder just thinking what will happen if I have to remove
one of those two drives to get it replaced)

2. created a grub floppy with menu like explained in the gru faq,
removing the device map anaconda created

3. changed the bios boot order to have the windows disk before the
linux ones (floppy,hd0,scsi instead of floppy,scsi,hd0)

4. booted on the floppy and used it to install grub on the windows
disk MBR using the files on (hd1,0) (no idea if it was hitting hda1 or
hdc1)

And it works. But I pity the next SOB that will have to go through
this. I is different from my win2k/fc1 receipe, even though the
partitions are ordered mostly the same logicaly

It seems the core of the problem is the BIOS and Linux disagree on the
drive order, grub chooses either the BIOS or the Linux side depending
if you get into it from the floppy or a linux drive, windows old
legacy parts believe the bios but new ones behave like linux (the
management console do shows drives in the linux order). So it's a big
f* mess. And It's not even some exotic harware:((


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