Boot.ini question

  • Thread starter Thread starter Dave C.
  • Start date Start date
Gerhard Fiedler said:
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 said:
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 said:
"Gerhard Fiedler" enscribed:




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 said:
craigm wrote
Correct.
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 said:
Gerhard Fiedler" wrote
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.
 
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.
 
Rod Speed said:
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 said:
Rod Speed wrote
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.
 
Timothy said:
OK, OK. Ding an Sich.

Still not right. Look it up again :)
There are so many uses of "Ding am Sich"

Google comes up with 148 versions of this your "thing" (some of which may
be yours :) -- and with about 101,000 for "Ding an sich". Doesn't look like
"many uses"...
that I misspelled the pronoun.

Not only that. (A hint: in German, capitalization is important. In English
it is, too, but many don't know that :)
Is that significant to you?

Not that much. It seemed significant enough for you to write about it.
If you want to know what it means, read Kant.

Different from you I /can/ do that -- and if I wanted to, I could cite him
correctly.

But then I don't need to invoke Kant to discuss Microsoft's boot.ini. OTOH,
if you really want to, maybe you read up on what Kant says about the "Ding
an sich" and what we know about it. Then relate that to the sentence where
you first tried to use it.

Gerhard
 
Timothy said:
"Gerhard Fiedler" enscribed:

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

Here's a simpler version, step by step:

1- You claimed that the rdisk number is related to the boot order.

2- One consequence of this is that if a controller can't boot from a disk,
I can't use your rule to determine the rdisk number.

3- I can use boot.ini entries to start Windows on drives the controller
can't boot from.

4- To do this, I use rdisk numbers determined in other ways than suggested
by you, because your method doesn't provide rdisk numbers for drives that
can't be booted by the controller.

5- This works. Windows can start from a drive that can't be booted by the
controller, given that the necessary files (ntldr and boot.ini among them)
are present and properly installed on a drive it can boot from.

6- Your claimed rule can't be used to determine the rdisk number for those
drives, yet they do have an rdisk number that can be used in boot.ini.

7- From this follows that the boot order (the term as used by you) is not a
generally usable method to determine the rdisk number of a drive for use in
boot.ini, as it requires the controller to be able to boot from the drive
in question.


(A maybe important side note: There is a difference between "booting" and
"starting Windows". The boot drive does not have to be the one where
Windows is installed. The boot drive needs to be the one that contains --
among other things -- boot.ini and that gets booted by the controller.
Windows can be installed on another drive; that would be the one the rdisk
parameter points to, and this drive does not have to be bootable by the
controller. It seems you can't replicate such a situation on your system,
because it seems your controller can boot from all drives you have
currently installed. You'd have to install a drive that you can't boot from
or run this on a system that has drives installed that the controller can't
boot to see first hand what I mean -- if you don't know it.)


Got it?

Gerhard
 
Timothy Daniels said:
"craigm" commented:


Yes, the latter.
Nope.

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

Nonsense.
The IDE controller BIOS setup program certainly does, *if* it has one.

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

Which has nothing whatsoever to do with bootorder.
at boot time because that is all the IDE controll knows.

About itself. The system sees them by the device numbers each gets.
It doesn't care about masters or slaves (or SCSI IDs).
 
Gerhard Fiedler said:
1- You claimed that the rdisk number is related to the boot order.


No, I did not. Read again. You will see that I referred to
"hard drive boot order". That is a subset of "boot order",
the latter including removable media devices such as
Zip drives and CD/DVD drives and floppy drives and flash
drives.. If you want to boot from devices other than hard drives,
you're on your own in configuring your boot.ini file.

*TimDaniels*
 
Folkert Rienstra said:
Which has nothing whatsoever to do with bootorder.


Which is my point. It is the BIOS that determines the
hard drive boot order and that order is independent of
the controller. And in the Phoenix BIOS, the BIOS takes
the above list and makes it the *default* hard drive boot
order if the user does not reset it. Most users do not reset
it (or know how to reset it), and for them it *is* the hard
drive boot order.

*TimDaniels*
 
Timothy said:
No, I did not. Read again. You will see that I referred to
"hard drive boot order".

You didn't read my message at all, or if you did, you didn't get it. I
wrote "boot order (the term as used by you)", which should tell you what
you need to know.

You can read my message again and (mentally) substitute "boot order" with
"hard drive boot order", because that's obviously what I was writing about.
We didn't talk about CD-ROMs, did we?
If you want to boot from devices other than hard drives, you're on your
own in configuring your boot.ini file.

I did of course /not/ talk about booting from anything but hard drives --
which anybody (or maybe not) could find out by reading my message.


Fact is that there are disks with perfectly valid rdisk numbers in many
systems that can't be booted by their controllers -- which, according to
you, would mean that they don't have an rdisk number.

Gerhard
 
"Gerhard Fiedler" substituted:
Fact is that there are disks with perfectly valid rdisk numbers in many
systems that can't be booted by their controllers -- which, according to
you, would mean that they don't have an rdisk number.


Whatever.

*TimDaniels*
 
Timothy Daniels said:
Rod Speed wrote

Yep.

just don't see any point in arguing trivia with you and your sock puppet
shelf mates.

Been having these pathetic little delusional fantasys long child ?

Gerhard's style is NOTHING like mine.

And we arent arguing trivia either you
pathetic excuse for a lying bullshit artist.
 
Back
Top