I have a PC with 3 SATA drives on it. SATA ports 0 and 1 are Windows XP, and SATA port 2 is Fedora Core 6. By changing the boot order in the BIOS, I can boot either Windows XP or Fedora successfully.

I'm using GRUB 0.97 as the Linux boot loader, and I want to set it up so I can boot either OS from the GRUB menu. I entered in the configuration file /root/boot/grub/grub.conf the lines

rootnoverify (hd1,0)
makeactive
chainloader +1
boot

which gives "Error 13: Invalid of unsupported executable format".

When I enter these same lines from the command line interface, Windows boots fine. The "makeactive" does not seem to be necessary.

I also tried adding the lines "map (hd1) hd0)" and "map (hd0) (hd1)", but the same error.

Any suggestions for what is wrong? I do not want to change the Windows boot loader, just use GRUB.

So, you can boot windows from the command line with
That tells me that windows is on the second drive (call it slave, sdb, hdb, or any other name that means the same thing).

I assume you have Fedora installed on the first drive, with grub already installed to the MBR of that drive.

Windows is picky, and will refuse to boot from any partition other that the first partition of the first drive. You just need to edit your *map* lines a bit; they are incomplete and need the partition number to finish them, like so:
root (hd1,0)
map (hd1,0) (hd0,0)
map (hd0,0) hd1,0)
makeactive
chainloader +1

Since you don't have both windows installations in the same partition, you will have to edit the config above to show the actual drive and partition numbers for each (two entries in grub.conf, one for each windows installation).

What's on each of "port0" and "port1"? (Only one of these will be the actual XP boot partition.)

This is not right:
grub.conf (aka menu.lst) should be in /boot/grub. /root is the home folder for the root user. Maybe there was a config file there for some reason, but you have to edit the one in /boot/grub

Best way to seek help in this case is to provide the screen output of command
. For all we know you could be using Raid for your Windows.

No, Windows is connected to the physical port SATA 0. Both Windows drives are NTFS file systems. There is no RAID connection.

Fedora is installed on the third drive, the one connected to physical SATA port 2. I am booting it by telling the BIOS to use it as the 2nd priority boot device, after CD-ROM.

The way booting (either Windows or Fedora) works, as I understand, is that the BIOS causes the initial sector of the first-preference boot device to be read, then control transferred to it--this program is the primary boot. If the first-preference boot device read fails (for example, because there is no CD-ROM in the drive), then the second-preference device is tried. In my case, the second-preference device is the Fedora drive. Up to this point, the only remapping of drives is done by the BIOS preference order, and neither disk partitions nor file system matters.

The Windows secondary boot, the program read in by the primary boot, works the same way as for Fedora: it reads a secondary boot program, which completes the boot process by reading the O/S. Since Windows boots fine when the second-preference device is physical SATA port 0, I know there is no problem with the partitions or mapping. It is just a matter of getting the GRUB chainloader command to read the initial sector of the correct drive, then transfer control to it, which is what the chainloader command does, according to the GRUB docs.

I changed /boot/grub/grub.conf (my mistake in the filename in my original post; I had logged on as root) to read (part):

title Windows XP
rootnoverify (hd1,0)
map (hd1,0) (hd0,0)
map (hd0,0) (hd1,0)
makeactive
chainloader +1
boot

but same error 13 from GRUB.

Here is the output from fdisk -l (transcribed-may contain typos):

Disk /dev/sda: 300.0 GB, 300890728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 36482 293041633+ 7 HPFS/NTFS

Disk /dev/sdb: 300.0 GB, 300890728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 13 104391 83 Linux
/dev/sdb2 14 36483 292945275 8e Linux LVM

Disk /dev/sdc: 300.0 GB, 300890728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 36482 293049666 7 HPFS/NTFS

OK this is my explanation and suggestion to fire up the two systems.

You confirmed both systems boot when placing each at the front of the booting queue. This means in both systems a record has been embedded to indicate the system had been installed in the No.1 disk. In other word Fedora will boot if it is in the (hd0) position and so is Windows.

You now have one more use of the hand that was responsible for changing the Bios. Use it again to specify

Fedora disk sdb as the 1st disk or (hd0) to boot
Windows bootable disk sda as the 2nd disk or (hd1) and
The other Windowsunbootable disk as the 3rd or (hd2).

According to your Post #5 all your disks are 300Gb and by their sizes in bytes they look from one manufacturer to me but sdc's partition is "NOT" marked bootable and hence sda must be the Windows boot disk.

You can now cut off the hand that you used to fiddle the Bios, as Grub will take over that job and make it redundant.

You can now add the recommended commands to Fedora's menu.lst as posted by bigrigdriver, except not specifying the partition number as follow
The two "map" statements instruct Grub saying "All because of you the user loses a hand so from now on when you executing thsi booting choice you must hand the disk (hd0) to the Bios when it demands for (hd1). If the Bios asks for (hd0) give it the (hd1)"

I did not use the "makeactive" because there is no change to its bootable status in the booting process and there is no possibility that the bootable status would be altered in the normal operation.

I opted out the "boot" statement because it is optional and only needed if you boot the system up manually.

If you want a bit of fun, as it is Christmas/New Year time, you can verify my proposal manually with the following steps before implementing it to the menu.lst.

(1) Arrange the way you know how to boot Fedora
(2) Boot up Fedora's Grub but press "c" quickly before any selection so as to drop into a Grub prompt.
(3) Check the geometry of the three disks (hd0), (hd1), (hd2_by Grub commands

Code:

geometry (hd0)
geometry (hd1)
geometry (hd2)

. You should find (hd0) has two partitions but (hd1) and (hd2) look the same with only one partition in Type 7.

(4) Type this lines in Grub prompt to fire up Windows

Code:

root (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
chainloader +1

(5) If the above doesn't work you boot into Fedora and report its "fdisk -l" output again. From now on do NOT touch the Bios, unless you don't want to keep the remaining hand. The commands in Grub prompt to fire up the arsX of Fedora are

Code:

root (hd0,0)
configfile /boot/grub/menu.lst

This worked for me just today after some wrestling previously overcoming the reluctance of Fedora Install and Win XP to agree to modify the Master Boot Record on the existing master disk.

Desktop PC with Win XP on the "first" "master" disk on the cable and a second empty disk on which I installed Fedora core 5. First I formed a 150MB boot partition with /boot as a primary partition and then partitioned up another 50GB as a LVM also as a primary.

When I got to GRUB I accepted the boot to Linux on hdb as the default with the offered second boot to "Other" on hda renamed Windows XP. I also took the option in grub to swap the precendence profile to put hdb first before hda.

When I rebooted I also set the BIOS boot list to put the Linux drive ( was a spare slave drive ) second after CDROM but before the "master" Windows disk.

Boot up to Linux now no problem but selecting Win XP it hung at "chainloader+1" of course.

I applied Bigrigdrivers grub modification ( posted in a previous thread ) as below into the file /boot/grub/grub.conf (NOT the file menu.lst):-

title Windows XP
rootnoverify (hd1,0)
map (hd0) (hd1)
map (hd1) (hd0)
chainloader +1
boot

Reboot and now I have Linux and Windows XP at the press of a button. Hope this adds to ooman noledge.
JP

In some distros grub.conf could be just a symbolic link to menu.lst which is the file Grub actually uses according to the Grub Manual. I only edit menu.lst in every distro (and nothing else) and that includes the Red Hat family up to FC6.

The result of the geometry confirmed what saikee suspected:

hd0 has 2 partitions, exc2fs (0x83) and unknown (0x8e)
hd1 and hd2 each have a single partition, unknown (0x7)

This is the same result as from fdisk -l that I reported previously.

The drives are all 300 GB Maxtor, with identical geometry (Grub reports C/H/S=1023/255/63; fdisk reports cyl=16383, which is correct).

In my initial post, I said that I *can* boot Windows by entering at the Grub command prompt

rootnoverify (hd1,0)
makeactive
chainloader +1
boot

If they are in the grub.conf file, I get "Error 13: Invalid of unsupported executable format".

When I enter these same lines from the command line interface, Windows boots fine. The "makeactive" does not seem to be necessary.

The same is true of the suggested

rootnoverify (hd1,0)
makeactive
map (hd1) hd0)
map (hd0) (hd1)
chainloader +1
boot

It also fails with error 13, when these lines are in grub.conf.

In my distro (Fedora 6) the grup.conf is the file, and menu.lst is a link to it.

The reason I asked the geometries of (hd0), (hd1) and (hd2) to be checked is to ensure they match those reported in Fedora Linux.

There are a few of confusions that needed to be clarified first

(1) Has the Bios switching been stopped? We could chase our own tail to the end of the world by doing the bios switching and then re-map simultaneously the drives in Grub. One of them must go. So please confirm as we need a permanent setting for (hd0), (hd1) and (hd2) disks to work with. Let us know what is the output of fdisk-l again if it differs.

(2) The post #9 is the first concrete evidence that Windows boots as being the second disk. Can you confirmed this was how Windows was installed, i.e. with Fedora already being the first bootable disk? Can you post here the full print out of your /boot/grub/menu.lst?

(3) Apparently the root cause of the problem isn't disk ordering. It is the same set of Grub booting commands that works in command prompt but fails if implemented in grub.conf. Can we have an agreement on this?

(4) Is there anyway you can make the two Windows disks look different in Grub? How do you know that you are trying all the time to boot to the second Windows disk and not the first one? Do you need the 2nd Windows disk to boot or operate? Can you use fdisk in Fedora to change the partition Type ID to 17 so that it is tempoaray hidden and you can tell from Grub prompt by its ID number 17 using the geometry command. At the moment both Windows disks are indistinguishable to Grub and so to you and all of us here.

I think most of us have been misled by the Bios switching. According to the Post #9 if Fedora occupies (hd0) and boot happily from there, Windows was installed in (hd1) and can boot from it then why do Bios switching to change the disk order.

The BIOS offers a choice of boot orders. When I want to boot Fedora, I make the disk with Fedora on it the 2nd priority drive (after CD-ROM). When I want to boot Windows, I make the bootable Windows disk the 2nd priority drive. As I mentioned, I can also boot Windows from the Grub command line

No, Windows was installed first, on physical disk 0. Physical disk 1 was added, and formatted for Windows, both being NTFS file system. Only disk 0 is Windows-bootable.

Fedora was installed second, with disks 0 and 1 disconnected.

/boot/grub/menu.lst is a symbolic link, pointing to /boot/grub/grub.conf. Here are all the non-comment lines from /boot/grub/grub.conf:

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.18-1.2868.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2868.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-1.2868.fc6.img
title Windows XP
rootnoverify (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
chainloader +1

Now this is working as expected. Namely, if I issue the commands at the Grub command line, starting with "rootnoverify", and also "boot", Windows is started. And, this is new today, using the Grub menu with the config file as above, selecting Windows XP also boots Windows. So there is no longer a problem.

Yes, that is what was happening before. I can't explain what is different today.

This is not relevant. I am saying to Grub, "Load the initial physical sector (cyl 0, head 0, sector 0) of the drive which is attached to physical port 1 into memory, and transfer control to it". Grub should not be looking at any aspect of the disk--not the partition table, not the system, not any directories. Grub is now doing this.

No. But everything would still work even if I did. Once the Windows boot loader gets control, it does everything necessary, including seeing that there are two other disks attached to the SATA controller.

As I explained above, this is not relevant; we are distinguishing the disks by their physical port (i e, where they are connected to the controller on the motherboard). We aren't looking at the file system, partition type, or data on disk 1.

I don't think the BIOS switching has anything to do with the situation. The drive numbers hdN are being assigned by Fedora and/or Grub. I am only using the BIOS switching to tell the BIOS initial sector read which physical disk is to be read.

In any case, things seem to be working now, though I can't explain why they didn't before. Perhaps Grub has some useful troubleshooting commands which I don't know about, such as telling us which physical drive it considers to be hd0, etc., which sectors it is reading, etc.

Thanks, everyone for your suggestions, and let's hope we all learned something.

Peter6000,

I think you has a misconception of the disk ordering.

Grub gets the disk ordering from the Bios directly. Without you interfering with it (remember I use the joke to chop off the hand that did it?) first disk is always (hd0) to Grub.

I believe you don't have to touch the bios setting from this point onward once you allow the Linux disk to take the (hd0) position permanently and the bootable Windows disk is in the (hd1) position, so that the Bios always gives the right disk to Grub to boot.

You confirm the bootable Windows disk was installed without the presence of the Linux disk and so it was in (hd0) position and a record would have been stamped stating "Installed in the 1st disk" inside the installed XP, making it unbootable if moved to a different position. You now claim it can boot in (hd1) position. Its root as you showed in the last post is the 1st partition of the 2nd disk and that is (hd1,0) to Grub who counts everything from 0. This is achieved by the use of the two map statements which swap the bootable Windows disk from (hd1) on-the-fly back to the (hd0) position. When you finish Windows the disk reverts back to the (hd1) position. This simple facility is availble also in Lilo the other Linux boot loader.

That is why is works now !

It is the hand that did the bios switching that causes all the trouble in this thread. The solution by adding two map statements put forward first by bigrigdriver is the polite way to say "keep your hand off the Bios".

You can drop the 2 map statements and go back to play around with the Bios disk ordering. I can't go back to that option because there are now 3 Dos and 5 Windows plus a large bunch of Linux inside my box to boot .