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