Boot.ini question

[Timothy Daniels]

Timothy Daniels wrote

BUT NOT THE ENTRY IN THE BOOT ORDER LIST
OR EVEN THE HARD DRIVE BOOT ORDER LIST.


Silly terminology.

That's Microsoft's terminology, sock puppet.

*TimDaniels*

 

[Timothy Daniels]

Timothy Daniels wrote

BUT NOT THE ENTRY IN THE BOOT ORDER LIST
OR EVEN THE HARD DRIVE BOOT ORDER LIST.

Go back to square One and re-read my experimental results.
The meaning "rdisk()" means the position of the hard drive in
the hard drive boot order. It is not dependent on the IDE
controller or anything else.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

Go back to square One and re-read my experimental results.

Go and **** yourself. It stays shit no matter how often its read.

The meaning "rdisk()" means the position of the hard drive in the hard
drive boot order.

ONLY WITH THAT COMPLETELY ****ED
BIOS YOU CLAIMED TO RUN THAT TEST ON.

Antoine doesnt even get the result you did on another Dell.

It is not dependent on the IDE controller or anything else.

Irrelevant to what MS intended the rdisk() param to refer to.

Even someone as stupid as you should be able to grasp that
it cant have been intended to refer to the entry in the hard drive
boot order list when it was introduced at a time when NO PCS
ACTUALLY HAD A HARD DRIVE BOOT ORDER LIST.

 

[Rod Speed]

Rod Speed wrote

That's Microsoft's terminology,

Lying, as always. Not for that it aint.

 

[Rod Speed]

Rod Speed wrote

Please post what the "MS documentation says it should mean".

Already posted links to the MS documentation on
the ARC path specification thats used in the boot.ini

You can get medication for your premature
ejaculation problem too apparently.

 

[Rod Speed]

Rod Speed wrote

Read again sock puppet.

Retake Bullshitting 101, ****wit.

And get some medication for the your
pathetic delusions about sock puppets too.

*I* said it -

*HE* said it in another post of his.

that an operating system can be loaded from a logical drive within an
Extended partition..

No news to anyone much, ****wit.

That isn't generally known,

Complete pig ignorant drivel.

even by sock puppets.

How odd that I said that explicitly too, ****wit.

 

[Timothy Daniels]

You don't understand the difference between "booting" and "starting
Windows".

"Booting" is when the BIOS loads ntldr into memory and starts it.

The boot sector logic loads ntldr in memory and starts it, not the BIOS.
At least, that's what Microsoft documentation claims. |According to MS,
The BIOS loads the MBR into memory and starts it, then the MBR passes
control to the boot sector of the active partition.

"Starting Windows" is after ntldr reads boot.ini, optionally displays the
selection menu and starts Windows from the controller, drive, partition and
directory indicated by the chosen entry. This controller, drive and
partition does not have to be bootable by the BIOS.

One of the purposes is to allow selection of an extended partition or a
drive that the BIOS can't boot to start Windows.

It's not an Extended partition that boot.ini can select, it's one of the
logical drives ("partitions" in your parlance) *within* the Extended
partition. There may be many logical drives in an Extended partition,
and each of them can be designated by a unique "rdisk()" value.
None of those logical drives have a trio of boot files (i.e. no boot.ini,
no ntldr, no ntdetect.com) and none of them can be marked "active",
so booting is under the control of boot files in a Primary partition.

*TimDaniels*

 

[Timothy Daniels]

:

Already posted links to the MS documentation on
the ARC path specification thats used in the boot.ini

In the Microsoft document "How to Determine the ARC Path"
(http://support.microsoft.com/default.aspx?scid=kb;en-us;155222)
it is stated:

"A typical ARC path might be:

multi(0)disk(0)rdisk(0)partition(2)\WINNT="My Server 4.0"

"The rdisk parameter is defined as Harddisk<X> on the
TargetDevice line, where <X> is a variable that represents
the drive ordinal. Note that the rdisk parameter is not used
when SCSI replaces multi in the ARC path."


Clearly, "rdisk()" refers to the position of the physical hard,
but it does NOT state how that position (i.e. the "drive ordinal")
is derived. That is left open to interpretation by manufacturers
such as Dell, to BIOS producers such as Phoenix Technologies,
and to ROM chip producers such as Intel. Seeing that hard
drives do fail now and then, Dell's BIOS allows automatice
selection of another OS if the hard drive containing the primary
OS should fail. This will happen if there is another hard drive
next in the hard drive boot order having a bootable OS on it
in an active partition that has the same partition number as the
primary OS.

Suppose HD0 and HD1 both have WinXP on their 1st partitions
and that both partitions are marked "active". If HD0 is at the
head of the hard drive boot order, its boot.ini parameter for the
hard drive will be "rdisk(0)" and its parameter for the OS's partition
will be "partition(1)".

If HD0 is removed (by failure or disconnection), HD1 will
automatically move to the head of the hard drive boot order -
even though it may remain with the same jumpering, on the same
cable connector on the same IDE channel - and the correct values
for its boot.ini file's hard drive and partition parameters would
remain "rdisk(0)" and "partition(1)". In other words, the boot.ini
files for the two HDs could be determined beforehand - even be
identical - and they wouldn't have to be edited if the primary HD
should fail. Dell's BIOS is more flexible and more convenient
than one which permanently ties its "rdisk()" values to the
Master/Slave and IDE channel values.

*TimDaniels*.

 

[Timothy Daniels]

Irrelevant to what MS intended the rdisk() param to refer to.

Even someone as stupid as you should be able to grasp that
it cant have been intended to refer to the entry in the hard drive
boot order list when it was introduced at a time when NO PCS
ACTUALLY HAD A HARD DRIVE BOOT ORDER LIST.

I'm only reporting the reality of Today. Your reality belongs
to the Past.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote
Timothy Daniels wrote

In the Microsoft document "How to Determine the ARC Path"
(http://support.microsoft.com/default.aspx?scid=kb;en-us;155222)
it is stated:

"A typical ARC path might be:

multi(0)disk(0)rdisk(0)partition(2)\WINNT="My Server 4.0"

"The rdisk parameter is defined as Harddisk<X> on the
TargetDevice line, where <X> is a variable that represents
the drive ordinal. Note that the rdisk parameter is not used
when SCSI replaces multi in the ARC path."

Clearly, "rdisk()" refers to the position of the physical hard,
but it does NOT state how that position (i.e. the "drive ordinal")
is derived.

Yes, but the boot order list doesnt even get a mention, and when the
ARC path naming convention originated at a time when there wasnt
even a hard drive boot order list in most if any bios, it should be
obvious to even someone as stupid as you that it was never intended
to be the ordinal in the hard drive boot order list that didnt even exist.

That is left open to interpretation by manufacturers such as Dell, to
BIOS producers such as Phoenix Technologies, and to ROM chip producers
such as Intel.

Wrong again. The detail just isnt spelt out explicitly in THAT
particular KB article which has a VERY limited purpose. It
aint anything like the definitive statement of the ARC path
naming convention used in boot.ini, let alone saying anything
about who gets to determine how the ordinal is determined.

http://support.microsoft.com/kb/102873/EN-US/
has a much clearer statement about the rdisk() parameter and it says

x86-Based Computers
The following are generic examples of two possible BOOT.INI ARC paths:

multi(X)disk(Y)rdisk(Z)partition(W)\<winnt_dir>
-or-
scsi(X)disk(Y)rdisk(Z)partition(W)\<winnt_dir>

where X, Y, Z, and W are numbers that identify the item to their left.


MULTI(X) Syntax
The MULTI(X) syntax of the ARC path is only used on x86-based computers.
In Windows NT version 3.1 this path is only valid for IDE and ESDI drives;
in
Windows NT version 3.5, 3.51 and 4.0 it is valid for SCSI drives as well.

The MULTI() syntax indicates to Windows NT that it should rely on the
computers BIOS to load system files. This means that the operating
system will be using interrupt (INT) 13 BIOS calls to find and load
NTOSKRNL.EXE and any other files needed to boot Windows NT.

The X, Y, Z, and W parameters have the following meaning:

X is the ordinal number of the adapter and should always be 0 (see the text
below for the reason).
Y is always 0 (zero) if the ARC path starts with MULTI(), because MULTI()
invokes the INT 13 call
as described above and therefore does not need the DISK() parameter
information.
Z is the ordinal for the disk on the adapter and is usually a number
between 0 and 3.

---------------my comment
This is the rdisk parameter and that clearly says DISK ON THE ADAPTER
and says nothing about any hard drive boot order list what so ever.

---------------my comment

W is the partition number. All partitions receive a number except for type
5 (MS-DOS Extended)
and type 0 (unused) partitions, with primary partitions being numbered
first and then logical
drives. NOTE: The first valid number for W is 1, as opposed to X, Y, and Z
which start at 0 (zero).

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.

In a pure IDE system, the MULTI() syntax will work for up to the four
drives
maximum on the primary and secondary channels of a dual-channel controller.

In a pure SCSI system, the MULTI() syntax will work for the first two
drives
on the first SCSI controller (that is, the controller whose BIOS loads
first).

In a mixed SCSI and IDE system, the MULTI() syntax will work only for the
IDE drives on the first controller.

http://www.microsoft.com/resources/...0/server/reskit/en-us/prork/prbd_std_ccef.asp
says the same thing in almost identical words.

Seeing that hard drives do fail now and then, Dell's BIOS allows
automatice
selection of another OS if the hard drive containing the primary OS
should fail.

Irrelevant to what MS states the rdisk() parameter refers to.

This will happen if there is another hard drive next in the hard drive
boot order having a bootable OS on it in an active partition that has the
same partition number as the primary OS.

That is a completely ****ed requirement. What should be done is
to have a boot.ini that lists OSs which are bootable, with a comment
that documents that OS's config, NOT some low level crap like the
partition its been installed in that the user doesnt give a flying red
**** about. Then if a hard drive does die, the user can just select
one of the other bootable OSs that isnt on the drive that has just
died, using the comment about the OS install, and carry on regardless.

Suppose HD0 and HD1 both have WinXP on their 1st partitions
and that both partitions are marked "active". If HD0 is at the
head of the hard drive boot order, its boot.ini parameter for the
hard drive will be "rdisk(0)" and its parameter for the OS's
partition will be "partition(1)".

If HD0 is removed (by failure or disconnection), HD1 will
automatically move to the head of the hard drive boot order

No it wont. The unbootable drive will still be at the head of the
boot order list, it just wont be bootable if the bios cant read it
successfully to get the MBR off it and to initiate the boot off it.

even though it may remain with the same jumpering, on the same
cable connector on the same IDE channel - and the correct values
for its boot.ini file's hard drive and partition parameters would
remain "rdisk(0)" and "partition(1)". In other words, the boot.ini
files for the two HDs could be determined beforehand - even be
identical - and they wouldn't have to be edited if the primary HD
should fail.

Wrong again if the drive at the head of the boot order list isnt
bootable because the bios isnt able to read the MBR off that
drive successfully so it can load it and boot ntldr etc off it.

Dell's BIOS is more flexible and more convenient than one which
permanently ties its "rdisk()" values to the Master/Slave and IDE channel
values.

Wrong again if the user does something as basic as move
a drive which isnt at the top of the hard drive boot order list
in that list. With the completely ****ed approach used in that
PARTICULAR Dell bios, the boot.ini has to be edited when
that drive is moved in the list. With the MS approach it doesnt.

AND Antoine has shown that the effect you are getting isnt
even universal with all Dell bios, let alone all Phoenix bios.

 

[Rod Speed]

Rod Speed wrote

I'm only reporting the reality of Today.

No you arent. ALL you are doing is mindlessly rabbitting on
about WHAT A PARTICULAR ****ED DELL BIOS DOES
ABOUT THE RDISK() PARAM. You arent even stating
what all current Dell bios do according to Antoine.

Your reality belongs to the Past.

No it doesnt. There is NO MENTION WHAT SO EVER BY
MS OR ANYONE ELSE THAT THE RDISK() PARAM REFERS
TO THE ORDINAL IN THE HARD DRIVE BOOT ORDER LIST.

There's a reason for that, stupid.

 

[Folkert Rienstra]

Rod Speed wrote

Rod Speed wrote
Correct, assuming the generally used meaning for
"boot order sequence" ("order inside the IPL table",
also known as "IPL Priority", according to the standard.)
Where exactly are you getting that from ?
Compaq-Phoenix-Intel, BIOS Boot Specification Version 1.01, 1996, 46 p.

http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf
Would you have read/meant anything else?
It wasnt at all clear if you were claiming that it
was general to all bios or just to the Phoenix.

[snip]

???
Compaq, Intel and Phoenix are the 3 "copyright holders" or "authors"
(can't nor want find which is correct here) of this document which is
generally seen as "an industry standard" on the matter. [snip]

There is considerable variation on how it is implemented among
the various BIOS vendors/providers. But the mandatory part is
implemented by all the BIOS I have seen since about 7 years. [snip]

Also there is variation on how the various things
are named, which is why I used the standard term. [snip]

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.

The problem I have with this idea is that by _any_
mean the BIOS allows you to boot the "other"
IDE disk, the BIOS will just switch 0x80 and 0x81,

That is just plain wrong.

Only on the part of "IDE".

In spades when the bios allows you to specify a boot
order with more than just one hard drive in the list.

And the boot drive will have device 0x80 regardless
nomatter how many there are in the list, clueless.

and you cannot make any clear and
ambiguous conclusion about its internal lists. [snip]

Which is the underlying problem. I very much
prefer experimenting a bit with slightly longer lists. [snip]

That's said, since I wrote this, I did some experiment with BIOSes
of two breeds, and they behave _widely_ differently at the respect.

And since Tim, using BIOS of the same maker (Phoenix+Dell)
but a different submodel, got results quite different from mine,
I am standing on my original point: it varies!

[snip].

 

[Folkert Rienstra]

Exactly. I'm so glad you agree with me.

No it doesnt. Its always possible for any app to be file system
aware without being anything like an OS. That is seen with
some of the early imagers for example where they were
NTFS aware when running on DOS which isnt NTFS aware.


Just being file system aware doesnt make it an OS.

Apps have always been able to operate directly on
a file system without there even being any OS at all,
tho you dont see that done very much anymore.

Even a modern DOS boot is file system aware in the sense
that the most basic files used for booting DOS dont need to
be in a fixed location on the drive. They are found using the
file system aware loader, by file name, not physical location.


Doesnt make it an OS either. Most boot managers have
some form of programability but they arent an OS either.

Thanks Roddles, for helping debunk Fiddlers 'point' with us.

 

[Folkert Rienstra]

En news:[email protected], Rod Speed va escriure:

???

It was just the usual sorry excuse to mask that he had never heard of it.

[snip]

 

[Folkert Rienstra]

Gerhard Fiedler wrote

Admitting this lemma...

What's a lemma ?

... it does not match with what Tim was saying initially.

Yes it does.

What you seem to miss is that Tim's BIOS does not have such a concept.

Irrelevant to the whole point of the rdisk() parameter.

All that proves is that Tim's BIOS is a complete abortion
that utterly flouts the whole point of the rdisk() parameter.

Sure, one of my BIOS, and an awful large number of other BIOSes
out there as well, do have such drives; yet, there are other BIOSes
which allow to boot easily from any drive recognized by the BIOS (BAID),

Not when its a logical drive in an extended dos partition.
Huh?


That was always one reason for the ntldr approach,
to allow booting of what the bios could not boot.

and furthermore it seems reasonable to envision this. [snip]

(that is, it can't load ntldr from them).

That's two different things. Being able to boot from
a harddisk is ordinarily reserved to the 80h drive;

No it isnt with modern bios.

Utterly clueless, as always.

Not clear what this is about,

So obviously any further comment can be ignored.

[snip]

 

[Timothy Daniels]

Yes, but the boot order list doesnt even get a mention, and when the
ARC path naming convention originated at a time when there wasnt
even a hard drive boot order list in most if any bios, it should be
obvious to even someone as stupid as you that it was never intended
to be the ordinal in the hard drive boot order list that didnt even exist.

Exactly why you shouldn't have quoted Microsoft's ARC path
documents - it's OBSOLETE!

That is left open to interpretation by manufacturers such as Dell, to BIOS producers such as Phoenix Technologies, and to ROM
chip producers such as Intel.

Wrong again. The detail just isnt spelt out explicitly in THAT
particular KB article which has a VERY limited purpose. It
aint anything like the definitive statement of the ARC path
naming convention used in boot.ini, let alone saying anything
about who gets to determine how the ordinal is determined.

http://support.microsoft.com/kb/102873/EN-US/
has a much clearer statement about the rdisk() parameter and it says

[...........]

Z is the ordinal for the disk on the adapter and is usually a number between 0 and 3.

---------------my comment
This is the rdisk parameter and that clearly says DISK ON THE ADAPTER
and says nothing about any hard drive boot order list what so ever.
---------------my comment

And the Microsoft document clearly states that the document
applies to:

• Microsoft Windows NT Advanced Server 3.1
• Microsoft Windows NT Server 3.5
• Microsoft Windows NT Server 3.51
• Microsoft Windows NT Server 4.0 Standard Edition
• Microsoft Windows NT Workstation 3.1
• Microsoft Windows NT Workstation 3.5
• Microsoft Windows NT Workstation 3.51
• Microsoft Windows NT Workstation 4.0 Developer Edition
• Microsoft Windows NT Advanced Server 3.1


The document is as obsolete as you are, sock puppet.

*TimDaniels*

 

[Timothy Daniels]

Timothy Daniels wrote

What MS intended in the misty past is that "rdisk()" specify
a hard drive and that it's related to some "adapter ordinal".
It doesn't say how that ordinal is to be determined. Since then,
Phoenix and/or Dell decided that the ordinal would be the
hard drive boot order - which in the *default* case is derived
from the IDE channel no. and the Master/Slave settings of
the hard drives. It makes no sense to bind one's thinking and
expectations to vague and obsolete documents. Time and
technology move on, sock puppet.

*TimDaniels*

 

[craigm]

Yes, but the boot order list doesnt even get a mention, and when the
ARC path naming convention originated at a time when there wasnt
even a hard drive boot order list in most if any bios, it should be
obvious to even someone as stupid as you that it was never intended
to be the ordinal in the hard drive boot order list that didnt even
exist.

Exactly why you shouldn't have quoted Microsoft's ARC path
documents - it's OBSOLETE!

That is left open to interpretation by manufacturers such as Dell,
to BIOS producers such as Phoenix Technologies, and to ROM chip
producers such as Intel.

Wrong again. The detail just isnt spelt out explicitly in THAT
particular KB article which has a VERY limited purpose. It
aint anything like the definitive statement of the ARC path
naming convention used in boot.ini, let alone saying anything
about who gets to determine how the ordinal is determined.

http://support.microsoft.com/kb/102873/EN-US/
has a much clearer statement about the rdisk() parameter and it says

[...........]

Z is the ordinal for the disk on the adapter and is usually a number
between 0 and 3.

---------------my comment
This is the rdisk parameter and that clearly says DISK ON THE ADAPTER
and says nothing about any hard drive boot order list what so ever.
---------------my comment

And the Microsoft document clearly states that the document
applies to:

• Microsoft Windows NT Advanced Server 3.1
• Microsoft Windows NT Server 3.5
• Microsoft Windows NT Server 3.51
• Microsoft Windows NT Server 4.0 Standard Edition
• Microsoft Windows NT Workstation 3.1
• Microsoft Windows NT Workstation 3.5
• Microsoft Windows NT Workstation 3.51
• Microsoft Windows NT Workstation 4.0 Developer Edition
• Microsoft Windows NT Advanced Server 3.1


The document is as obsolete as you are, sock puppet.

*TimDaniels*

Try this one.
http://www.microsoft.com/resources/...Windows/XP/all/reskit/en-us/prmc_str_masc.asp

 

[Timothy Daniels]

Antoine Leca wrote


Which supports the proposition that Tim's is a complete
abortion perpetrated by Dell with that PARTICULAR bios,
not even universal to Dell or Phoenix as he claimed, let
alone across all bios on all systems as he originally
claimed. Just another bios that someone has
comprehensively stuffed up the rdisk() parameter with.


The only sensible way to test THAT claim is with
the simplest config of 3 hard drives, with the only
boot.ini on the drive at the top of the boot order list
and swapping the order of the two other drives
which are below that in the boot order list and
see which drive gets booted when the user selects
a particular entry with a particular rdisk() value in
the ntldr boot menu.

Well you've described the minimal test.
What does "Antoine Leca" have to say about the results
of such a test?
So far, we don't even know what model of Dell he tested
or what his methodology or results were.
How about system specs, a full test and the results, Antoine?

*TimDaniels*

 

[Gerhard Fiedler]

... it does not match with what Tim was saying initially.

Well, yes, it does. If you don't have a newsreader with the history of this
thread, I would gladly provide you with quotes.

What you seem to miss is that Tim's BIOS does not have such a concept.

No, I don't miss this -- Tim is missing that this is a special case of his
BIOS.

Tim didn't say "on /my/ machine, the rdisk number seems to be equivalent to
the position in the hard disk boot order list" -- he claims this to be the
case on /all/ machines. Which I seriously doubt, and it seems I'm not alone
with this.

I don't claim to be a specialist in the boot process, but if something
doesn't match, it doesn't.

(Of course, due to entertraining confusion, one has to mentally change "to
load" to the more generally used "to boot" above).

Right... not my idea, though; just trying to accommodate Tim

Well, here you mean "to control" to designate the binary code which is
executing initially.
Yes.

I would reserve "to control" to designate the small, configurable, part
of the process; in the first case, we'll find the "boot order" (whatever
that means), and also the actual MBR and secondary boot code; in the
second case, Boot.ini.

Also makes sense, but doesn't affect the issue: the rdisk number can point
to a drive that doesn't appear in a "hard disk boot order list" (as it is
called by Tim).

What is important here is that both are not completely independant;
particularly, if you change the "boot order" (and hence the placement of the
Boot.ini file, Rod's main point, very true indeed), you could also affect
the interpretation of Boot.ini.

How does the placement of the boot.ini file get changed with the boot
order? The file is there, right with the ntldr, on the active partition. It
doesn't run... Of course, changing drives around (or, in some BIOSes
changing some configurations) can affect the interpretation of the
boot.ini, because the rdisk numbers can change.

Which, ultimately, was Tim's point.

Not quite. You got me there... I need to quote

First post by Tim 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.

Sounds clear as water. A drive not in the hard drive boot order does not
have an rdisk number, according to this description (and his follow-up
clarifications).

Gerhard