Boot.ini question

[Timothy Daniels]

Rod Speed va escriure:

I did not read it this way, but if he said that, it would be very wrong.

Also, the fact there is or not a MBR should not come into play.
You can perfectly boot a computer with a device whose sector
LBA0 ends in 55AAh but lacking a MBR.
Perhaps you'll have to disable the advanced "features" like "virus
protection", though.

My comments about a hard drive's MBR were in reference to
Microsoft's description of the boot process in which Microsoft
states that the hard drive *with an MBR* that is nearest the head
of the hard drive boot order has control passed to its MBR. I have
not experimented with hard drives not having MBRs, so I don't
know whether the hard drive 2nd in the order would be given
control if it were the 1st one to have an MBR. Thus, my experiment
concerned just hard drives having a valid MBR.

*TimDaniels*

 

[Timothy Daniels]

Rod Speed va escriure:

And its completely trivial to prove that it doesnt with the test
I posted.

You meant:
] The obvious problem with your claim is trivial to prove.
] Setup a test config where the boot.ini comes off the
] first drive in the boot list in the bios, with an entry to
] boot off a different physical drive. When you move
] that later physical drive in the boot order in the bios,
] that doesnt make any difference to which drive gets
] booted when you select that entry in the boot.ini at
] boot time. The N value changes according to you
] because you have moved it in the bios boot sequence
] list. XP still boots the same physical drive regardless.

The problem with this test is that it does not work in general.

[......]
Now, if you change the "Hard disk drive sequence" in the
BIOS, how could that ever work?
Changing the sequence will assign 0x80 to the array, so it
boots from it; we should first assume the BOOT.INI had be
moved accordingly; but to boot successfully you also need
to correct its content also, here to rdisk(0).

Forget it. Rod's motive is to obuscate. That's
why the above paragraph is gibberish - it's meant to
confuse, not clarify. This is evident from his insistance
that one boot.ini file be used for the entire experiment.
If one were to change the boot order such that a different
hard drive moved to the head of the hard drive boot order,
the MBR of that different hard drive would get control, then
the boot sector of the "active" partition on that hard drive,
then the ntldr in that partition, and so the boot.ini file on
that different hard drive would direct loading. Thus, by
moving a different hard drive to the head of the hard drive
boot order, a different boot.ini file would *have* to be used.

*TimDaniels*

 

[Gerhard Fiedler]

Forget it. Rod's motive is to obuscate.

Kind of, partly. But you don't know either what your BIOS does when you
change the boot order of the disks -- something that's not common (even if
you say it is).

It is easily possible that the BIOS changes several internal lists with
this process -- which then would mean that the relationship only exists in
your specific computer.

Do you know for sure that this is not the case? Do you know exactly what
your BIOS does when you use this non-standard feature? It's often
misleading when trying to generalize from a single instance to a generic
rule.

Gerhard

 

[Rod Speed]

Rod Speed wrote

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.

And since the bios are considerably modified by the motherboard
manufacturer, it isnt at all relevant what Compaq has chosen to do.

I did not read it this way, but if he said that, it would be very wrong.

Yes, like I said, he is very wrong.

Also, the fact there is or not a MBR should not come into play.

Correct. And he must have mentioned MBRs explicitly for a reason.

You can perfectly boot a computer with a device whose
sector LBA0 ends in 55AAh but lacking a MBR. Perhaps
you'll have to disable the advanced "features" like "virus
protection", though.

Thats all rather irrelevant to what is being discussed in general, the
claim
that the rdisk() parameter refers to the boot order list entry number.

You meant:
] The obvious problem with your claim is trivial to prove.
] Setup a test config where the boot.ini comes off the
] first drive in the boot list in the bios, with an entry to
] boot off a different physical drive. When you move
] that later physical drive in the boot order in the bios,
] that doesnt make any difference to which drive gets
] booted when you select that entry in the boot.ini at
] boot time. The N value changes according to you
] because you have moved it in the bios boot sequence
] list. XP still boots the same physical drive regardless.

The problem with this test is that it does not work in general.

Irrelevant when testing for what the rdisk() parameter actually refers to.

Assume you have two controlers: say two IDE drives and a RAID array.

Irrelevant when testing for what the rdisk() parameter actually refers to.

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.

According to your hypothesis, we will assume that the booting
("system" in MS parlance) drive would be the first IDE, so 0x80,

We arent assuming anything, just using that simple config to clarify
just what the rdisk() parameter in the boot.ini actually refers to by
testing.

the second would have number 0x81, and the array will get
the next position, 0x82. We also assume that Windows is
on the RAID array, so BOOT.INI reads> something as
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS

Thats all an irrelevant complication when testing what the
rdisk() parameter in the boot.ini actually refers to by testing.

Now, if you change the "Hard disk drive sequence"
in the BIOS, how could that ever work?

Thats why its a useless config for that test. Obviously the two
bootable drives need to be bootable to when testing what the
rdisk() parameter in the boot.ini actually refers to by testing.

Changing the sequence will assign 0x80 to the array, so it boots from
it; we should first assume the BOOT.INI had be moved accordingly;
but to boot successfully you also need to correct its content also,
here to rdisk(0). The IDE drives will get 0x81 and 0x82, but they
are irrelevant as far as your scheme is concerned.

See above.

Basically, I feel that the NTLDR scheme is dependant upon _both_ the
identification of the system device (the one where BOOT.INI is) and
the boot device a.k.a. where Windows kernel is (indicated by the
ARCpath). Moving any of those results usually in impossibility to
boot and need to mess with the location and content of BOOT.INI

We are testing what the rdisk() paramater refers to. Thats why there
is only a boot.ini file on the hard drive at the top of the boot sequence
table and both of the other drives are fully bootable, have the Win
kernal installed on them. You see what selecting a particular entry
in the only boot.ini file produces in the sense of which drive gets
booted with both possibilitys of the location of the two drives that
dont have a boot.ini on them in the boot order list.

Thats the only viable way to see if the entry in the boot
order list in the bios is what the rdisk() entry refers to.

(there is hope the new BootMgr scheme will
solve part of these problems, but I am not sure).

Again, irrelevant to what is being tested.

Sorry about the double negative,

That isnt a double negative.

I thought it could be understood. I wrote it was my impression you did
_not_ know about some BIOS that allows to _change_ the order the
various drives on a single controller/device are getting assigned.

If I was wrong and you do know about it, please elaborate.

All irrelevant to what is being discussed, what the rdisk() param refers
to.

 

[Rod Speed]

Rod Speed va escriure:

And its completely trivial to prove that it doesnt with the test
I posted.

You meant:
] The obvious problem with your claim is trivial to prove.
] Setup a test config where the boot.ini comes off the
] first drive in the boot list in the bios, with an entry to
] boot off a different physical drive. When you move
] that later physical drive in the boot order in the bios,
] that doesnt make any difference to which drive gets
] booted when you select that entry in the boot.ini at
] boot time. The N value changes according to you
] because you have moved it in the bios boot sequence
] list. XP still boots the same physical drive regardless.

The problem with this test is that it does not work in general.

[......]
Now, if you change the "Hard disk drive sequence" in the
BIOS, how could that ever work?
Changing the sequence will assign 0x80 to the array, so it
boots from it; we should first assume the BOOT.INI had be
moved accordingly; but to boot successfully you also need
to correct its content also, here to rdisk(0).

Forget it. Rod's motive is to obuscate.

Lying, as always.

That's why the above paragraph is gibberish

You did manage to work out what I was proposing, liar.

- it's meant to confuse, not clarify. This is evident from his
insistance that one boot.ini file be used for the entire experiment.

What a terminal ****wit you have always been, child.

If one were to change the boot order such that a different
hard drive moved to the head of the hard drive boot order,

I CLEARLY SAID THAT THE DRIVE AT THE TOP OF THE
BOOT ORDER SHOULD NOT BE CHANGED AND THAT
ONLY THE DRIVES BELOW THAT SHOULD BE SWAPPED.

the MBR of that different hard drive would get control, then
the boot sector of the "active" partition on that hard drive,
then the ntldr in that partition, and so the boot.ini file on
that different hard drive would direct loading. Thus, by
moving a different hard drive to the head of the hard drive
boot order, a different boot.ini file would *have* to be used.

Presumably you actually are that stupid.

 

[Rod Speed]

Timothy Daniels wrote

Kind of, partly.

Nope, not in the slightest. I do ocassionally get a comment
that I tend to use longer sentences than are desirable for
the best clarity, but I also get other comments that I tend
to be too cryptic and dont provide enough detail too.

But you don't know either what your BIOS does
when you change the boot order of the disks --

He does now that he did get off his lard arse and do
the test I told him is the viable way to test what the
rdisk() paramater in the boot.ini actually refers to.

something that's not common (even if you say it is).

He didnt say that changing the boot order is common.
Its just what he chooses to do to produce the quickest
recovery when a particular drive isnt bootable with the
approach he chooses to use for backup.

It is easily possible that the BIOS changes several internal
lists with this process -- which then would mean that the
relationship only exists in your specific computer.

Do you know for sure that this is not the case? Do you know exactly
what your BIOS does when you use this non-standard feature?

Thats why I proposed that test, to see what the rdisk() actually
refers to, whether its affected by the entry in the boot order list or not.

It's often misleading when trying to generalize
from a single instance to a generic rule.

In spades when there is no mention of the boot order list in
any of the documentation of the ARCpath naming convention.

And its a terminally stupid way to implement it too because
the boot.ini has to be edited when the boot order is changed.

 

[Peter]

Isn't it time for a wet paper bag? LOL

 

[Timothy Daniels]

"Rod Speed" fumed:

I CLEARLY SAID THAT THE DRIVE AT THE TOP OF THE
BOOT ORDER SHOULD NOT BE CHANGED AND THAT
ONLY THE DRIVES BELOW THAT SHOULD BE SWAPPED.

And that is exactly what I did. Breathe deeply, count to 10,
and read the description of the experiment again. You'll see
that for each of the 3 HDs, I used the same boot.ini file to boot
each of the 3 HDs. Then I rearranged the HDs below the head
of the hard drive boot order and re-did the procedure. Then,
in changing the head of the hard drive boot order to do the whole
process over again, your proposed scenario was implemented.
IOW, your proposed experiment was a subset of what I did, but
you don't recognize that what I did was just your own proposed
configuration and procedure done on a larger scale. IOW, your
own proposed experiment proved you to be wrong.

*TimDaniels*

 

[Timothy Daniels]

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.

*TimDaniels*

 

[Timothy Daniels]

We are testing what the rdisk() paramater refers to. Thats why there
is only a boot.ini file on the hard drive at the top of the boot sequence
table and both of the other drives are fully bootable, have the Win
kernal installed on them. You see what selecting a particular entry
in the only boot.ini file produces in the sense of which drive gets
booted with both possibilitys of the location of the two drives that
dont have a boot.ini on them in the boot order list.

Thats the only viable way to see if the entry in the boot
order list in the bios is what the rdisk() entry refers to.

Everything you propose was done as part of the experiment,
it was just done 3 times - once for each HD, not just for one of
them. Then the whole experiment was done again to appease
your unnatural attachment to motherboard controllers. Perhaps
you should read the thread "meaning of 'rdisk()' in boot.ini".

*TimDaniels*

 

[Gerhard Fiedler]

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.aspx?scid=kb;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. 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?

Gerhard

 

[Timothy Daniels]

"Gerhard Fiedler" asked:

http://support.microsoft.com/default.aspx?scid=kb;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. 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?

What's your point? (All I see is a non-sequitur question.)

As for the meaning of "rdisk()", you're falling into Rod Speed's
habit of relying on specifications and ignoring the Ding am Sich.
What is more significant - the way things REALLY are or the way
some obsure spec says they SHOULD be?

*TimDaniels*

 

[Rod Speed]

Isn't it time for a wet paper bag? LOL

Funny you should say that, I just applied one |-)

 

[Rod Speed]

Rod Speed wrote

And that is exactly what I did.

Lying, as always. You not only had a boot.ini on EVERY drive,
you ALSO changed the drive at the top of the boot list.

Breathe deeply, count to 10, and read the description of the experiment
again.

Dont need to, it stays shit no matter how often its read.
And its better to hold your breath when reading shit too.

You'll see that for each of the 3 HDs, I used the same boot.ini file to
boot each of the 3 HDs.

Pity I said to have JUST ONE BOOT.INI FILE ON THE DRIVE
THAT STAYS AT THE TOP OF THE LIST AND ISNT EVER
SELECTED IN THE MENU THE BOOT.INI PRESENTS.

Then I rearranged the HDs below the head of the hard drive boot order and
re-did the procedure. Then,
in changing the head of the hard drive boot order to do the whole
process over again, your proposed scenario was implemented.
IOW, your proposed experiment was a subset of what I did,

Yes, but I clearly didnt specify that subset to
CONFUSE anyone, you silly little pathological liar.

but you don't recognize that what I did was just your own proposed
configuration and procedure done on a larger scale.

Irrelevant to your lie that my test was to CONFUSE.

IOW, your own proposed experiment proved you to be wrong.

No it didnt with your pig ignorant claim that the rdisk() param
ALWAYS refers to the boot order sequence number.

It certainly does apply to that very badly designed steaming turd
you are using if you arent actually lying about what gets booted,
but you havent proven a damned thing about any other system.

And since you are clearly a pathological liar, I wouldnt believe
what you claim you are seeing on that system of yours either.
I'd want to see someone else agree that they get that ****ed
result on another Dell or Phoenix biosed system first.

 

[Rod Speed]

Rod Speed wrote

Rod Speed wrote
And its completely trivial to prove that it doesnt with the test I
posted.
You meant:
] The obvious problem with your claim is trivial to prove.
] Setup a test config where the boot.ini comes off the
] first drive in the boot list in the bios, with an entry to
] boot off a different physical drive. When you move
] that later physical drive in the boot order in the bios,
] that doesnt make any difference to which drive gets
] booted when you select that entry in the boot.ini at
] boot time. The N value changes according to you
] because you have moved it in the bios boot sequence
] list. XP still boots the same physical drive regardless.
The problem with this test is that it does not work in general.

Irrelevant when testing for what the rdisk() parameter actually refers
to.
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".

No point, it has no relevance what so ever to what I was commenting on
there.

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.

Irrelevant to what I was commenting on there.

 

[Rod Speed]

Timothy Daniels wrote

http://support.microsoft.com/default.aspx?scid=kb;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.

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.

 

[Folkert Rienstra]

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.


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


Would always have rdisk numbers.

Utter Nonsense. Bios support can be disabled.

 

[Rod Speed]

"Gerhard Fiedler" asked:


What's your point? (All I see is a non-sequitur question.)

As for the meaning of "rdisk()", you're falling into Rod Speed's
habit of relying on specifications and ignoring the Ding am Sich.
What is more significant - the way things REALLY are

You aint established that that is the way they REALLY
are except on that steaming turd of yours.

And its very bloody unlikely indeed that the rdisk() param
is the boot order sequence number when the MS documentation
and everyone else's documentation of the ARCpath spec
doesnt even mention the boot order sequence at all.

or the way some obsure spec says they SHOULD be?

Never ever could bullshit its way out of a wet paper bag.

If the rdisk() param really did refer to the boot order
sequence number on many systems at all, you'd see
comments about that using google.

You dont, so your pig ignorant claim that
its universal is clearly just plain wrong.

 

[Gerhard Fiedler]

What's your point?

Simple logic.

(All I see is a non-sequitur question.)

Can you point out exactly what is "non-sequitur" here?

As for the meaning of "rdisk()", you're falling into Rod Speed's habit of
relying on specifications and ignoring the Ding am Sich.

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

What is more significant - the way things REALLY are or the way some
obsure spec says they SHOULD be?

You seem to have a pretty clear vision of how things /should/ be on other
machines, derived from how they may be on yours -- and not care much about
how they /really/ are...

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.

Gerhard

 

[Timothy Daniels]

"Gerhard Fiedler" enscribed:

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

*TimDaniels*