Boot.ini question

"Gerhard Fiedler" wrote:
If you can't cite correctly, look it up or leave it... "Ding am Sich"
is just sick.


OK, OK. Ding an Sich. There are so many uses of
"Ding am Sich" that I misspelled the pronoun. Is that
significant to you? If you want to know what it means,
read Kant.

*TimDaniels*

"Gerhard Fiedler" wrote:
Citing your first post regarding this matter in this thread: "You can also
think of "rdisk()" as meaning the "relative disk position", that is,
relative to the head of the BIOS's hard drive boot order."

If I did as you say, how would I get the rdisk number for drives the BIOS
can't boot from? I suppose they don't appear in the BIOS's hard drive
boot order.


Booting from drives you can't boot from is *your* problem. I use
the rdisk() parameter to boot from drives I *can* boot from.

*TimDaniels*

Timothy Daniels wrote:
"Gerhard Fiedler" enscribed:

Aren't there BIOS/controllers that don't boot from all disks
connected to
them, yet these disks may still have rdisk numbers and allow starting
Windows on them?



This ends with a question mark, but it sure ain't a sentence. What
is it?

*TimDaniels*

rdisk(#) is the order of the disks on the specific controller. This
probably means the drives are assigned the numbers during device discovery.

Does changing the boot order in the BIOS renumber/reorder the disks on
the controller, or just change the order in which they are scanned to
look for a bootable system?

I suspect the latter.

"craigm" commented:
rdisk(#) is the order of the disks on the specific controller. This
probably means the drives are assigned the numbers during device
discovery.

Does changing the boot order in the BIOS renumber/reorder the
disks on the controller, or just change the order in which they are
scanned to look for a bootable system?

I suspect the latter.


Yes, the latter.
"rdisk(n)" is given meaning by the BIOS. The IDE controller
doesn't know about hard drive boot order. When the hard drive
boot order is changed in the BIOS, the controller still displays:
Master, ch. 0
Slave, ch. 0
Master, ch. 1
Slave, ch. 1
at boot time because that is all the IDE controll knows.

*TimDaniels*

Timothy Daniels wrote
Gerhard Fiedler wrote

Aren't there BIOS/controllers that don't boot from all disks connected
to them, yet these disks may still have rdisk numbers and allow starting
Windows on them?

This ends with a question mark,

You quite sure you aint one of those
rocket scientist silly little children ?

but it sure ain't a sentence.

Wrong, as always.

What is it?

A sentence that is also a question, ****wit.

Timothy Daniels wrote
craigm wrote

rdisk(#) is the order of the disks on the specific controller. This
probably means the drives are assigned the numbers during device
discovery.

Correct.

Does changing the boot order in the BIOS renumber/reorder the disks on
the controller, or just change the order in which they are scanned to
look for a bootable system?

I suspect the latter.

Yes, the latter.

"rdisk(n)" is given meaning by the BIOS. The IDE controller doesn't know
about hard drive boot order.

Its more complicated than that. The controller does
know about the order of the drives on a particular
ribbon cable, independently of the boot order.

When the hard drive boot order is changed in the BIOS, the controller
still displays:
Master, ch. 0
Slave, ch. 0
Master, ch. 1
Slave, ch. 1
at boot time because that is all the IDE controll knows.

And that is why the rdisk() param on all properly implemented
systems refers to THAT numbering, NOT the numbering in the
boot order list.

For one very very simple reason, with a bios that cannot boot
from some of the IDE drives, and so cannot be included in the
boot order list in that particular bios, the boot.ini STILL NEEDS
TO BE ABLE TO HAVE THOSE DRIVES SPECIFIABLE IN
THE rdisk() entry for that drive.

Congratulations, you have just blown both your
feet completely off and you can fall over now.

Timothy Daniels wrote
Gerhard Fiedler" wrote

Citing your first post regarding this matter in this thread: "You
can also think of "rdisk()" as meaning the "relative disk position",
that is, relative to the head of the BIOS's hard drive boot order."

If I did as you say, how would I get the rdisk number for drives the
BIOS can't boot from? I suppose they don't appear in the BIOS's hard
drive boot order.

Booting from drives you can't boot from is *your* problem.

No it aint. The whole point of the boot.ini is to allow the NT/2K/XP
family to be booted off drives and partitions that the bios cant boot off.

I use the rdisk() parameter to boot from drives I *can* boot from.

Your gross deficiencys are your problem, as always.

Folkert Rienstra wrote
Rod Speed wrote
Gerhard Fiedler wrote
Timothy Daniels wrote
Rod Speed wrote

Its much better to test it in the simple config of a motherboard
with just two IDE ports and no RAID controller etc to simplify
things.

Read the thread "meaning of 'rdisk()' in boot.ini file". I re-ran
the entire experiment with the 3 HDs connected to the motherboard
IDE controller, and exactly the results were found - rdisk(n)
refers to the hard drive having a displacement "n" from the head
of the hard drive boot order.

http://support.microsoft.com/default...en-us;q102873:

"Theoretically, this syntax could be used to start Windows NT on any
drive in the system. However, this would require that all drives are
correctly identified through the standard INT 13 interface; since
support for this varies from disk controller to disk controller and
most system BIOS only identify a single disk controller through INT
13, in practice it is only safe to use this syntax to start Windows
NT from the first two drives connected to the primary disk
controller, or the first four drives in the case of a dual-channel
EIDE controller."

Thinking about it (again , it probably can't be the boot order.

The main reason its unlikely to have been intended to be the
boot order number is that the boot.ini would have to be edited
when the boot order is changed. Even MS aint usually THAT stupid.

AND they dont even mention the boot order, and it wasnt changeable
in the systems around at the time that NT first used a boot.ini anyway.

Aren't there BIOS/controllers that don't
boot from all disks connected to them,

Yes, in fact initially quite a few wouldnt even boot the
slave drive with a single IDE controller, two drives in total.

yet these disks may still have rdisk numbers

Would always have rdisk numbers.

Utter Nonsense.

We'll see, as always.

Bios support can be disabled.

Pity you can still boot off drives that dont get seen by
the bios with an appropriate entry in the boot.ini file.

If you couldnt, it wouldnt be possible to bypass the
bios limitation with a particular drive by not listing it
in the bios drive table and letting Win find it anyway.

and allow starting Windows on them?

Yep, that was one of the reasons for boot.ini in the first place,
to allow NT to be booted from other than the primary master drive.

"Rod Speed" wrote:
And that is why the rdisk() param on all properly implemented
systems refers to THAT numbering, NOT the numbering in the
boot order list.


The Phoenix Technologies BIOS as installed in Dell PCs
is quite "properly implemented". It's just not proper for YOU.

*TimDaniels*

Timothy Daniels wrote
Rod Speed wrote

And that is why the rdisk() param on all properly implemented
systems refers to THAT numbering, NOT the numbering in the
boot order list.

The Phoenix Technologies BIOS as installed in Dell PCs is quite "properly
implemented".

No it isnt. It not only cant handle booting from drives
that cant be included in the boot order list in the bios,
it requires the boot.ini to be edited when you change
the order of the drives which are other than the top
entry in the boot order list. That is completely ****ed.

It's just not proper for YOU.

And for every other system designer that
has managed to implement it properly either.

I find it VERY hard to believe that that is actually Phoenix,
I bet some ****wit clown at Dell is who has actually chosen
to perpetrate that complete ****ing abortion that is nothing
like what MS clearly intended with the rdisk() param.