I have a Dell 3000 with an 40 gig IDE drive (master on the primary
controler) and a DVD drive (master on the secondary controller) running
XP. I added a 2nd drive (300 gig) on the secondary controller and
loaded Fedora Core 4 with Grub on it. If I boot 'normally', GRUB gets
displayed on the screen and then it hangs. If I disconnect the DVD and
connect the 300 gig drive, Grub comes and and I can boot whichever I
want.

If I have everything plugged in as described and boot a Knoppix CD (or
Fedora in rescue mode), I can see that the 300 gig drive is hdd with 3
partitions (boot, / and swap). The grub.conf also sees this as
/dev/hdd but it calls the boot partition (hd1,0). the /boot partition
is the first partition on the drive but I don't think hd1 is right.
I've tried making it hd2 and hd3 and still can't boot with the DVD
connected.

Any ideas what I can do to make this work "right"?

"jerryshenk" <jerryshenk@gmail.com> writes:

>I have a Dell 3000 with an 40 gig IDE drive (master on the primary
>controler) and a DVD drive (master on the secondary controller) running
>XP. I added a 2nd drive (300 gig) on the secondary controller and
>loaded Fedora Core 4 with Grub on it. If I boot 'normally', GRUB gets
>displayed on the screen and then it hangs. If I disconnect the DVD and
>connect the 300 gig drive, Grub comes and and I can boot whichever I
>want.

>If I have everything plugged in as described and boot a Knoppix CD (or
>Fedora in rescue mode), I can see that the 300 gig drive is hdd with 3
>partitions (boot, / and swap). The grub.conf also sees this as
>/dev/hdd but it calls the boot partition (hd1,0). the /boot partition
>is the first partition on the drive but I don't think hd1 is right.
>I've tried making it hd2 and hd3 and still can't boot with the DVD
>connected.

>Any ideas what I can do to make this work "right"?

The bios must be used to boot a disk. Tehre is no disk operating system
which can read disks. Many bioses will only read the first or second disks.
Ie, you must put the /boot partition in hda or hdb, so the kernel, which
contains the disk reading routines, can be loaded from something that the
bios can read.

But it boots fine if I have the 300 gig drive as the primary on the
secondary controller....I think that would make it /dev/hdc wouldn't
it? I'll have to get a cable that I can use to put the 300 gig drive
on the primary controller so that it would be /dev/hdb.....perhaps that
would work. I'll have to mess with this tomorow. Thanks for the
idea....at least it's something to try.

On Mon, 28 Nov 2005 05:05:12 +0100, jerryshenk <jerryshenk@gmail.com> wrote:

> But it boots fine if I have the 300 gig drive as the primary on the
> secondary controller....I think that would make it /dev/hdc wouldn't
> it? I'll have to get a cable that I can use to put the 300 gig drive
> on the primary controller so that it would be /dev/hdb.....perhaps that
> would work. I'll have to mess with this tomorow. Thanks for the
> idea....at least it's something to try.

Before I answer, please do quote some parts of the earlier messages in the
thread. Since you are using Google, don't just click "reply', look near the
top of each message, there is a link "show options". Click it and a header
appears with another "reply" link, that is the good one. It will
automatically quote the message you are replying to. Your job is now
to *delete* any parts of the quote that is irrelevant or excessive.

-----------------

Can we suppose that you are well aware of the need to set a jumper
or switch on the drive to make it "master" or "slave"?

There is also often a selection "cable select", but that requires, if
I recall correctly, a cable that supports it. Are you sure you are
doing this right? I don't know if there is any way that the Linux
kernel (on the knoppix) can access a drive despite incorrrect
cabling/jumpering, (with an error rate different from 100%)
while the Bios may be failing to do the same.

In most computers, the Bios tries to boot off different devices.
There is a setting to determine what devices, and in what order.
My computer only has a setting "hard drive" among "CDROM" and others,
but that says nothing about which drive. In practice, it always
boots off the primary master. I always have a primary master intalled.
Perhaps it would try hdb, hdc, hdd in turn if hda were not present.
Some say that the Bios only will try hda and hdb. I have seen a
friend had a Bios where he could set it to boot off "c:" or "d:",
so there are a few variations here.

I have never seen any good explanation of how the Bios determines
if it was able to boot off a device, or has to go on to the next
item on the list. I suppose that the Bios merely detects if the
device is present, and if the controller circuitry reports an
error transferring a sector's worth of data to memory. If the
transfer went OK, I assume the Bios assumes success. Then the Bios
executes the code in that sector. If that code hangs, the Bios does
not get a second chance.

That leads to my question: How do you make your Bios use the 300G
and not the 40G? Does your Bios have a setting for *what* disk to
use?

My main point here is really that you should try to follow the chain
of events, to see where it goes wrong. For this you may need to
know more than you have, but with all I have said, perhaps you can
provide here some more specifics about your Bios and your procedures,
and others here can add some "theory" or background knowledge.

If you can find out what disk the bios is accessing, and how/if
you can control that, we need to know: What is in the first sector
of that device? If it is a grub "stage1" sector, then it contains
a code to determine where to go next. That code is patched into the
sector when you set up Grub. If, when you do the setup, you point
Grub to (hd2,0), because Grub's "stage2" is in hdc1, it will not
find stage2 after the same drive has been recabled/jumpered to become
hdd (or hd3, in grub parlance). I guess you see the problem now.

Does your machine sport a floppy drive? If yes, prepare a
Grub floppy. Just use the knoppix or the rescue cd, and say

cat stage1 stage2 > /dev/fd0

when you have found these files on the CD. (Grub's info page says
use "dd", do that if I am wrong. I think "dd" is the tool to use if
you need to write at some offset into a device, but if the data
is contiguous from the start, I think the command above is OK.)

Then boot off the floppy. You will get a Grub prompt on the
screen, and you will be able to explore your disks as Grub sees
them when looking through the Bios. This is different from
using grub while running linux, because then grub sees the disks
through the linux kernel device drivers.

To explore the situation, take note of a file that is unique
for each disk. Or prepare for the experiment, by creating a file
on the 300G disk, called "This-is-the-300G". Then at the grub
prompt say

Grub> find This-is-the-300G

You will probably get a response "(hd3,0)/This-is-the-300G", and
then you know Grub sees the disk as (hd3).

The natural thing to look for is of course "/grub/stage2" (if you
have a separate /boot partition), or "/boot/grub/stage2" (if not).

Note that when doing this, there is no Linux running, and therefore no
mounting of devices on directories. If you have a separate /boot
partition, there is one partition containing /boot as an empty directory,
and another partition containing /grub as a nonempty directory.

Once you have determined this, you can do the setup. At the grub prompt,
still no linux running:

Grub> root (hd3,0) # the partition having "stage2"
Grub> setup (hd0) # the disk your Bios will access first.

Presto.

Oh, not quite. Now you probably have the wrong data in grub.conf
(or are you using "menu.lst"? Whichever.) Grub will try to boot
according to the config file in the partition containing the stage2.
When it fails to find the file specified in the "kernel" line,
it will give you the prompt, and you will be able to fix the situation.

(This works because now stage2 is loaded. When you tried earlier,
grub just hung because it could not load stage2.)

At the prompt,

Grub> root (hd3,0) # the partition containing the kernel

Grub> cat /grub/grub.conf # or menu.lst. Just to see the file names.

Grub> kernel /grub/vmlinuz-2.6.12-FC4.1362 root=/dev/hdd2 ro
# Notice the root= kernel option speaks
# linuxese, and names the "/" device.

Grub> initrd /grub/initrd-2.6.12-FC4.1362.img
# Use your actual file name, of course!

Grub> boot

When Linux comes up, you can go and edit your /boot/grub/whichever
config file to reflect the procedure that worked.

If you don't have a floppy drive, do this:

Create a file /boot/grub/device.map, containing lines like

(hd0) /dev/hda
(hd3) /dev/hdc

In this file you tell Grub how the devices will show up when seen through
the Bios *at the time of the next boot*. The fist column is the future
bios device expressed in Grubese, the second column is how to access that
device right now, under linux, expresed in Linuxese.

Then run

# grub-install /dev/hda

The device you specify is the one to receive the grub stage1 in sector
zero. Remember to fix grub.conf too, before you reboot.

-Enrique

Wow, that's gonna take some digesting Thanks a ton. I'll respond
with a more useful response once I go through your recommendations.
This machine doesn't currently have a boot floppy but that can be
resolved pretty easily. It sounds like that's a key to tracking down
exactly how grub is identifying things.

jerryshenk wrote:
> Wow, that's gonna take some digesting Thanks a ton. I'll respond
> with a more useful response once I go through your recommendations.
> This machine doesn't currently have a boot floppy but that can be
> resolved pretty easily. It sounds like that's a key to tracking down
> exactly how grub is identifying things.
>

.... and if it doesn't have a boot floppy, then I presume that you mean
to acquire a usb-floppy which is _not_ the same, your bios (most
probably) will not let you boot from a usb-floppy!!
And thus it goes on and on and on ...

Please read Perez-Theron's answer again - it's one of the best
explanations on how grub works that I've ever seen!!

-pbh-

On Mon, 28 Nov 2005 15:26:23 +0100, Enrique Perez-Terron wrote:


> Grub> root (hd3,0) # the partition having "stage2"
> Grub> setup (hd0) # the disk your Bios will access first.
>

> (hd0) /dev/hda
> (hd3) /dev/hdc
>
>
Enrique,

What you wrote is all based on a wrong assumption that grub numbers drives
based on their position on the IDE cables. It does not. Grub counts
physical hard drives only, counts from (hd0), with (hd0) being the drive
that the BIOS will call to boot an OS.

Here is grubs device map when the BIOS is set to boot from the first hard
drive, and when there is no hda, but drives are present on hdc, hde, and
hdg, all master positions on a system with four IDE controllers. (My hard
drives are in caddies, so this is an easy test)

(fd0) /dev/fd0
(hd0) /dev/hdc
(hd1) /dev/hde
(hd2) /dev/hdg

When hde and hdg are removed, a drive is added to hda, and a usb drive is
also plugged in, with grub in the MBR of hdc, the BIOS is set to boot from
hdc, the device map gets automatically rewritten as below.

(fd0) /dev/fd0
(hd0) /dev/hdc
(hd1) /dev/hda
(hd2) /dev/sda

When (hd0) is moved to /dev/hda and (hd1) is moved to /dev/hdc, and the
other drives are returned to hde, and hdg, the BIOS is again set for
normal booting, the device map is again rewritten.

(fd0) /dev/fd0
(hd0) /dev/hda
(hd1) /dev/hdc
(hd2) /dev/hde
(hd3) /dev/hdg
(hd4) /dev/sda

All of which illustrates that there is no fixed relationshib between cable
position, and grub's (hdX). Grub counts from (hd0), does not count CD-Roms
or DVD-Roms, (My DVD-R/W is hdb, and hdd is my CD-R/W) only hard drives,
and does not skip numbers. You can't have an (hd3) without having (hd0),
(hd1), and (hd2) preceed it.

The OP's drive is indeed (hd1), if it is not (hd0), and there are only two
hard drives in the machine. To know the exact interaction between grub and
Fedora, we need to see the partition table for (hd1), know for sure that
it is jumpered properly for whatever position it occupies in the IDE
cabling, and the contents of /boot/grub/menu.conf.

--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."

On Tue, 29 Nov 2005 05:23:08 +0000, imotgm wrote:


> The OP's drive is indeed (hd1), if it is not (hd0), and there are only two
> hard drives in the machine. To know the exact interaction between grub and
> Fedora, we need to see the partition table for (hd1), know for sure that
> it is jumpered properly for whatever position it occupies in the IDE
> cabling, and the contents of /boot/grub/menu.conf.

Sorry, that last should read /boot/grub/grub.conf

--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."

On Tue, 29 Nov 2005 06:23:08 +0100, imotgm <imotgm_REM@invalid-yahoo.com> wrote:

> On Mon, 28 Nov 2005 15:26:23 +0100, Enrique Perez-Terron wrote:
>
>
>> Grub> root (hd3,0) # the partition having "stage2"
>> Grub> setup (hd0) # the disk your Bios will access first.
>>
>
>> (hd0) /dev/hda
>> (hd3) /dev/hdc
>>
>>
> Enrique,
>
> What you wrote is all based on a wrong assumption that grub numbers drives
> based on their position on the IDE cables. It does not. Grub counts
> physical hard drives only, counts from (hd0), with (hd0) being the drive
> that the BIOS will call to boot an OS.
>
> Here is grubs device map when the BIOS is set to boot from the first hard
> drive, and when there is no hda, but drives are present on hdc, hde, and
> hdg, all master positions on a system with four IDE controllers. (My hard
> drives are in caddies, so this is an easy test)
>
> (fd0) /dev/fd0
> (hd0) /dev/hdc
> (hd1) /dev/hde
> (hd2) /dev/hdg
>
> When hde and hdg are removed, a drive is added to hda, and a usb drive is
> also plugged in, with grub in the MBR of hdc, the BIOS is set to boot from
> hdc, the device map gets automatically rewritten as below.
>
> (fd0) /dev/fd0
> (hd0) /dev/hdc
> (hd1) /dev/hda
> (hd2) /dev/sda
>
> When (hd0) is moved to /dev/hda and (hd1) is moved to /dev/hdc, and the
> other drives are returned to hde, and hdg, the BIOS is again set for
> normal booting, the device map is again rewritten.
>
> (fd0) /dev/fd0
> (hd0) /dev/hda
> (hd1) /dev/hdc
> (hd2) /dev/hde
> (hd3) /dev/hdg
> (hd4) /dev/sda
>
> All of which illustrates that there is no fixed relationshib between cable
> position, and grub's (hdX). Grub counts from (hd0), does not count CD-Roms
> or DVD-Roms, (My DVD-R/W is hdb, and hdd is my CD-R/W) only hard drives,
> and does not skip numbers. You can't have an (hd3) without having (hd0),
> (hd1), and (hd2) preceed it.

Thanks a lot for this info, I have been asking myself about this for some
time, but forgot to consider this a possibility when I wrote my last post.
I will use the opportunity to ask more questions related to this.

I suspect that this behavior of Grub is a reflection of how the Bios behaves,
but I don't have any good source for the Bios behavior in different computers
and circumstances. The Bios calls to read disk require the register DL to
contain a code for the drive to be accessed, and that code is 0x80 for the
boot disk, or is it for the first disk, or is it for the primary master?
The texts I have seen describing the "int 13h" calls just say "first disk"
without any further reference to the enumeration process.

I have observed that the standard Microsoft MBR code uses the value of the
bootable flag in the partition table, as the drive designation when issuing
the Bios call to read the "partition boot sector". This made me think that,
for one, it should be possible to abuse of the partition table, having
an entry that actually describes a partition of the second disk, and use
the value 0x81 in the "bootable" flag byte. (I'll not go into the disastrous
consequences this could have when other software believed this partition
table entry without considering the low-order bits of the the bootable flag.)

Second, it makes me think that in computers where it is possible to boot
off any other disk than the first, the Bios will likely renumber the disks
so that the boot disk always has code 0x80. What you tell, fits neatly
with this theory. I have not been able to test this because my computers
could only boot from an unspecified "hard drive", as stated earlier.
Does anyone have more info on this?

Another possible interpretation would be that a "bootable" flag in a
partition on a disk other than the first, would have to be 0x80 + zero-based
disk number. This would render the bootable flag invalid if disks are
rearranged. It does not seem very attractive.

Prompted by this ng exchange, I have searched the web again, and found a
"BIOS Boot Specification" from Compaq, Phoenix and Intel, 1996, where an
appendix suggests that boot sector programs use the value that the Bios
provides in the DL register, rather than the value in the bootable flag.
That reminds me that I saw some reference to that in the source code for
Grub's stage1. Grub seems to rely on this extension, although it has a code
to modify the register DL by or'ing with 0x00, where the byte 0x00 can be
patched to 0x80 when the stage1 is installed on a hard disk. If I understand
this correctly,

- grub can boot from devices other than the "first" if whoever calls it,
calls it with the device number to use in register DL. It could be called
by the Bios, or by some other boot-loader that chains into grub.
- grub can boot off the "first" device if the caller leaves the DL set to
zero, e.g., an older Bios.
- If your Bios or chaining boot loader leaves garbage in DL when calling
grub's stage1, you are fried. It won't boot.

Here "first" is whatever the bios "int 13h" calls access when DL is 0x80.
Here I am only talking about the stage1 part of the boot. The stages 1.5
and 2 can of course access any device supported by "int 13h".

> The OP's drive is indeed (hd1), if it is not (hd0), and there are only two

Ah, that explains it!

> hard drives in the machine. To know the exact interaction between grub and
> Fedora, we need to see the partition table for (hd1), know for sure that
> it is jumpered properly for whatever position it occupies in the IDE
> cabling, and the contents of /boot/grub/menu.conf.

So, with some luck, the OP can possibly achieve to boot off the second disk
(300G) by referring to it as (hd1) in the device.map file and elsewhere.

But then it is not clear to me what happened when he connected the dvd as
secondary master. If the bios (or is just grub) skips the dvd in the
numbering of disks, the 300G disk in the secondary slave position should
just be the same as before, and equally accessible?

That returns me to the hypothesis that there may be possible to access the
300G (with some error rate != 100%) even in the case that both the dvd
and the 300G disk are jumpered as masters. Does anybody know if this is
physically possible? It sounds improbable to me, what could possibly
prevent the dvd from interferring in the communication, and destroying it?
But in the world of actual engineering there are quite a few surprises.
I don't know the ATA command repertoire, but I cannot exclude a priori
that it be possible to issue a disable command to the master, in the
hope that if one of them responds suficiently faster, the other will
abort or cancel the command and so remain accessible...

But another theory that seems much more likely is that the behavior
you describe (hd0=boot device, hdn=nth existing non-boot *disk* device)
is not carved in stone, but rather subject to bios-standard versions,
producer idiosyncrasies, disagreements about what constitutes a disk,
and right-out bugs. So, it would be interesting to hear from the OP,
if he finds a way to get into a grub prompt independent of the exact
set of ata device attachments, if he can use the "find" grub command
under different circumstances and report what he finds.

Perhaps the fastest way is for the OP to use the knoppix to access the
300G disk, experiment with hd1, hd2 and hd3 in the devices.map and see
if any of these works. He would have to run "grub-install /dev/hda"
with each setting in device.map, then reboot. Updating grub.conf would be
of secondary importance, as that file only affects what happens after
stage2 is loaded.

Oh, yes, it was said that an USB floppy would not act as a bootable device,
but that seems also uncertain. Some computers have Bioses that allow
booting off usb disks, some do not. What I just found in the Bios boot
specification seems to point to mechanisms for plug-and-play devices to
install Bios extensions, and that opens for quite many possibilities.
Whether any particular device or setup exploits the possibilities is
anyone's guess. But of course, the OP should be warned that the USB
floppy may not work as a boot device.

Regards,
Enrique

On Tue, 29 Nov 2005 18:02:16 +0100, Enrique Perez-Terron wrote:

> On Tue, 29 Nov 2005 06:23:08 +0100, imotgm <imotgm_REM@invalid-yahoo.com> wrote:
>
>> On Mon, 28 Nov 2005 15:26:23 +0100, Enrique Perez-Terron wrote:
>>
>>
>>> Grub> root (hd3,0) # the partition having "stage2"
>>> Grub> setup (hd0) # the disk your Bios will access first.
>>>
>>
>>> (hd0) /dev/hda
>>> (hd3) /dev/hdc
>>>
>>>
>> Enrique,
>>
>> What you wrote is all based on a wrong assumption that grub numbers drives
>> based on their position on the IDE cables. It does not. Grub counts
>> physical hard drives only, counts from (hd0), with (hd0) being the drive
>> that the BIOS will call to boot an OS.
>>
>> Here is grubs device map when the BIOS is set to boot from the first hard
>> drive, and when there is no hda, but drives are present on hdc, hde, and
>> hdg, all master positions on a system with four IDE controllers. (My hard
>> drives are in caddies, so this is an easy test)
>>
>> (fd0) /dev/fd0
>> (hd0) /dev/hdc
>> (hd1) /dev/hde
>> (hd2) /dev/hdg
>>
>> When hde and hdg are removed, a drive is added to hda, and a usb drive is
>> also plugged in, with grub in the MBR of hdc, the BIOS is set to boot from
>> hdc, the device map gets automatically rewritten as below.
>>
>> (fd0) /dev/fd0
>> (hd0) /dev/hdc
>> (hd1) /dev/hda
>> (hd2) /dev/sda
>>
>> When (hd0) is moved to /dev/hda and (hd1) is moved to /dev/hdc, and the
>> other drives are returned to hde, and hdg, the BIOS is again set for
>> normal booting, the device map is again rewritten.
>>
>> (fd0) /dev/fd0
>> (hd0) /dev/hda
>> (hd1) /dev/hdc
>> (hd2) /dev/hde
>> (hd3) /dev/hdg
>> (hd4) /dev/sda
>>
>> All of which illustrates that there is no fixed relationshib between cable
>> position, and grub's (hdX). Grub counts from (hd0), does not count CD-Roms
>> or DVD-Roms, (My DVD-R/W is hdb, and hdd is my CD-R/W) only hard drives,
>> and does not skip numbers. You can't have an (hd3) without having (hd0),
>> (hd1), and (hd2) preceed it.
>
> Thanks a lot for this info, I have been asking myself about this for some
> time, but forgot to consider this a possibility when I wrote my last post.
> I will use the opportunity to ask more questions related to this.
>
> I suspect that this behavior of Grub is a reflection of how the Bios behaves,
> but I don't have any good source for the Bios behavior in different computers
> and circumstances. The Bios calls to read disk require the register DL to
> contain a code for the drive to be accessed, and that code is 0x80 for the
> boot disk, or is it for the first disk, or is it for the primary master?
> The texts I have seen describing the "int 13h" calls just say "first disk"
> without any further reference to the enumeration process.

First, let me apologize for not snipping this post, but I'm not sure what,
of my first post, you might want to reference, in regard to any answers
I might now give, and having to jump back and forth between replies seems
to be rather clumsy.

For your above question, when the BIOS is set for normal boot "first disk"
would seem to mean "first disk found". I can remove all drives, then
insert a Windows only drive in any slot, hda, hdc, hde, or hdg, and
Windows will do a normal boot. If I install grub in the MBR of /dev/hdg, a
Linux originally installed on /dev/hdg, will also boot from there. If I
change fstab on a Linux originally installed on /dev/hda to change all
/dev/hda references to /dev/hdg, and change only the root=/dev/hda3 to
root=/dev/hdg3 in its menu.lst stanza, so that it reads:

title Suse9.1 G 2.6.4-54.5 - test-normal boot
kernel (hd0,0)/suse9.1/vmlinuz root=/dev/hdg3 vga=normal splash=verbose resume=/dev/hda2 showopts
initrd (hd0,0)/suse9.1/initrd

and insert it in the hdg slot, it also boots without incident.

For clarity, I have a boot partition that is unmounted on any system,
and I have had up to 12 OSs at a time installed. To keep clutter to a
minimum, and avoid confusion, I copy the /boot directory of each new
install to the boot partition, and rename it to match the OS version,
hence the "suse9.1" where "boot" would normally be in the stanza.

> I have observed that the standard Microsoft MBR code uses the value of the
> bootable flag in the partition table, as the drive designation when issuing
> the Bios call to read the "partition boot sector". This made me think that,
> for one, it should be possible to abuse of the partition table, having
> an entry that actually describes a partition of the second disk, and use
> the value 0x81 in the "bootable" flag byte. (I'll not go into the disastrous
> consequences this could have when other software believed this partition
> table entry without considering the low-order bits of the the bootable flag.)
>
> Second, it makes me think that in computers where it is possible to boot
> off any other disk than the first, the Bios will likely renumber the disks
> so that the boot disk always has code 0x80. What you tell, fits neatly
> with this theory.

That would seem to be the method used. You can also do the same thing
through grub, or lilo, with the map command.

> I have not been able to test this because my computers
> could only boot from an unspecified "hard drive", as stated earlier.
> Does anyone have more info on this?

Do you have an empty drive that you can install a minimum copy of any
Windows version on? If so, mount it as hda, and do so, for testing
purposes. If you already have a Windows only machine, use that, if you
prefer. Then if you have a "Linux only" drive, with grub installed in the
MBR, add the following stanza to menu.lst, or grub.conf in the /boot/grub
directory;

title Windows -new
root (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
makeactive
chainloader +1

Install the Linux drive as hda, and the Windows drive as hdb. Boot, and
choose Windows which should be 0x81, but with the remapping will now be
0x80 as the Bios sees it and will boot as if it were hda. For fun, shut
down, and move the Windows drive to hdc, (remember to change the jumper)
and reboot, again choosing Windows. Repeat again installing the windows
disk at hdd. Now, leaving the Windows disk at hdd, install another hard
drive as hdb, reboot to Linux and add the additional Windows stanza to
menu.lst;

title Windows hdd
root (hd2,0)
map (hd2) (hd0)
map (hd0) (hd2)
makeactive
chainloader +1

Reboot, and choose the "Windows hdd" entry, from grubs menu. You can then
shut down once more, move the Windows disk back to hdc, (remember the
jumper) and boot again using the "Windows hdd" entry.

This little bit of play should help answer the questions below. Booting
the Windows install from the various places is used as the test of the
remapping, because it, (Windows) is the only one that thinks theres
something magical about 0x80.

The problem of Windows overwriting the MBR on multiboot systems is
eliminated if Windows is on it's own drive, and anywhere except hda, on
systems where BIOS only offers "boot from hard drive". Windows, on the
assumption that it is always on 0x80, will only overwrite the MBR of the
disk on which it resides. It does not stalk, or hunt down, the mighty
grub, to kill it where it resides, unless it just happens reside in the
MBR of the drive on which Windows is installed. Grub, and lilo, with there
remapping ability make that unnecessary.

> Another possible interpretation would be that a "bootable" flag in a
> partition on a disk other than the first, would have to be 0x80 +
> zero-based disk number. This would render the bootable flag invalid if
> disks are rearranged. It does not seem very attractive.
>
> Prompted by this ng exchange, I have searched the web again, and found a
> "BIOS Boot Specification" from Compaq, Phoenix and Intel, 1996, where an
> appendix suggests that boot sector programs use the value that the Bios
> provides in the DL register, rather than the value in the bootable flag.
> That reminds me that I saw some reference to that in the source code for
> Grub's stage1. Grub seems to rely on this extension, although it has a
> code to modify the register DL by or'ing with 0x00, where the byte 0x00
> can be patched to 0x80 when the stage1 is installed on a hard disk. If I
> understand this correctly,
>
> - grub can boot from devices other than the "first" if whoever calls
> it,
> calls it with the device number to use in register DL. It could be
> called by the Bios, or by some other boot-loader that chains into
> grub.
> - grub can boot off the "first" device if the caller leaves the DL
> set to
> zero, e.g., an older Bios.
> - If your Bios or chaining boot loader leaves garbage in DL when
> calling
> grub's stage1, you are fried. It won't boot.
>
> Here "first" is whatever the bios "int 13h" calls access when DL is
> 0x80. Here I am only talking about the stage1 part of the boot. The
> stages 1.5 and 2 can of course access any device supported by "int 13h".
>
>> The OP's drive is indeed (hd1), if it is not (hd0), and there are only
>> two
>
> Ah, that explains it!
>
>> hard drives in the machine. To know the exact interaction between grub
>> and Fedora, we need to see the partition table for (hd1), know for sure
>> that it is jumpered properly for whatever position it occupies in the
>> IDE cabling, and the contents of /boot/grub/menu.conf.
>
> So, with some luck, the OP can possibly achieve to boot off the second
> disk (300G) by referring to it as (hd1) in the device.map file and
> elsewhere.

Yes.

> But then it is not clear to me what happened when he connected the dvd
> as secondary master. If the bios (or is just grub)

Just grub. BIOS, and Linux kernel, need to know where everything is. Grub
only cares where hard drives are, and if they contain OSs.

> skips the dvd in the
> numbering of disks, the 300G disk in the secondary slave position should
> just be the same as before, and equally accessible?

I would guess improper jumper, on either the DVD, or hdd, as a first
choice. An improperly written stanza in grub.conf as second place to look.
OP didn't mention the brand of the hard drive, which can make a difference
as to the jumpering.

My own preference is to make the DVD-R/W the slave on the first IDE
controller, and if I have a second CD-ROM, CD-R/W, DVD-ROM, or DVD-R/W,
make it the slave on the second IDE controller. All my hard disks are then
set as masters, and pretty much interchangeable, within limits of the
fstab and menu.lst entries. Pure data storage disks, with no OS, can be
inserted anywhere after hda.

> That returns me to the hypothesis that there may be possible to access
> the 300G (with some error rate != 100%) even in the case that both the
> dvd and the 300G disk are jumpered as masters. Does anybody know if this
> is physically possible?

Sure, its physically possible, and neither will work properly, if at all.
My guess is not at all.

> It sounds improbable to me, what could possibly
> prevent the dvd from interferring in the communication, and destroying
> it?

Nothing would prevent it, that's the reason for proper jumpering.


> But in the world of actual engineering there are quite a few
> surprises. I don't know the ATA command repertoire, but I cannot exclude
> a priori that it be possible to issue a disable command to the master,
> in the hope that if one of them responds suficiently faster, the other
> will abort or cancel the command and so remain accessible...
>
> But another theory that seems much more likely is that the behavior you
> describe (hd0=boot device, hdn=nth existing non-boot *disk* device) is
> not carved in stone, but rather subject to bios-standard versions,
> producer idiosyncrasies, disagreements about what constitutes a disk,
> and right-out bugs. So, it would be interesting to hear from the OP, if
> he finds a way to get into a grub prompt independent of the exact set of
> ata device attachments, if he can use the "find" grub command under
> different circumstances and report what he finds.

Actually, the idea is to carve the behavior in stone, through standards
and such. If the behavior of a computer is not predictable, it is no
longer a computer, just a random signal generator. Any behavior that is
not as predicted, is a bug that needs fixing.

> Perhaps the fastest way is for the OP to use the knoppix to access the
> 300G disk, experiment with hd1, hd2 and hd3 in the devices.map and see
> if any of these works. He would have to run "grub-install /dev/hda" with
> each setting in device.map, then reboot. Updating grub.conf would be of
> secondary importance, as that file only affects what happens after
> stage2 is loaded.

You're getting way to involved. The device map is interesting to see how
grub sees it's place in it's world, but tinkering with it will not solve
the OP's problem.

First item in troubleshooting is check to see that the master/slave
jumpers are installed properly, for both items on the IDE controller.

If one has a Linux live CD, or DVD, any flavor, or can boot from the
hard drive using an installation disk and the "boot from hard drive"
option, the first thing to do is check the contents of grub.conf, or
menu.lst, whichever the distro in question is using, to see what is being
looked for, and where it is being looked at.

# fdisk -l

will show what the partitions are on all drives, and where they are in the
device chain.

The contents of /etc/fstab will tell you where the OS thinks it should be.

> Oh, yes, it was said that an USB floppy would not act as a bootable
> device, but that seems also uncertain. Some computers have Bioses that
> allow booting off usb disks, some do not. What I just found in the Bios
> boot specification seems to point to mechanisms for plug-and-play
> devices to install Bios extensions, and that opens for quite many
> possibilities. Whether any particular device or setup exploits the
> possibilities is anyone's guess. But of course, the OP should be warned
> that the USB floppy may not work as a boot device.
>
> Regards,
> Enrique

--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."