Question about backups with Ghost

"Anna" wrote:
Tim:
Let me cite some of my experiences using disk imaging
programs to directly clone the contents of one HD to
another HD and how, for the most significant part, they
parallel your experiences with one or two exceptions. And,
of course, we're speaking about PATA drives here...

1. As I think you know from our past exchanges, I primarily
use the Ghost 2003 disk imaging program to perform direct
disk-to-disk cloning operations although I have used other
DI programs as well, chiefly the Acronis True Image version 8
program. So my comments pretty much refer to the use of
those programs in this area.

2. I most certainly agree with you that it is important, if not crucial,
for the user to disconnect the source disk immediately following
the cloning operation and make that initial boot with only the
newly-cloned HD connected. Future boot problems with that
cloned drive may (but not *always*) occur if the preceding is not
adhered to. At least that has been our experience with the
Ghost & ATI programs, and from reports that I've received from
those who have used other DI programs, the same potential
problem can occur. (BTW, we have run into the same problem
with SATA drives). Incidentally, this potential problem can occur
even if the BIOS boot order priority was changed to make that
initial boot from the cloned HD while both the source & destination
drives were connected at the time of the initial boot to the cloned
HD. The important thing is to disconnect the source disk before
the initial boot to the newly-cloned HD.

3. However, we have never encountered a subsequent boot
problem with the cloned HD if it later was connected as a
secondary drive. At least I can't recall a single problem in this
area. Again, as long as the *initial* boot with that cloned HD
had been undertaken with the source drive disconnected as
indicated above, it didn't matter that the cloned drive was, at
one time or another, later used as a secondary drive. We've
always been able to boot to that cloned drive at some
subsequent time either with the source HD disconnected or
a change in the BIOS boot order should both drives be
connected at the time of that boot.

In this connection - we're assuming two bootable HDs in the
machine - our experience with modern motherboards - let's
say about the past five years - has been (with rare exceptions)
that regardless of the IDE channel (or its position on that
channel) that a bootable HD is connected to, the system will
boot to that drive if it's the only bootable HD currently present in
the system. (A BIOS item change is sometimes necessary to
facilitate this action). I'm not sure if your experience has been
different from mine in this area.
Anna


As I've posted in this and other threads in this NG, my
experience has been identical to yours. I've even posted, in
detail, experiments which I have run regarding boot order and
its effect on the meaning of "risk()" in boot.ini file's ARC pathname
entries. As for the HD boot order, the result of removal of the
existing booting HD is that some other HD in the HD boot order
(if one exists) is given control by the BIOS to do the booting.
That HD is just the next HD in the HD boot order. If the currently-
booting HD is Master on ch. 0, the next will be the Slave on ch. 0.
If there is no HD as Slave on ch. 0, the HD that is Master on ch. 1
becomes the boot HD, etc.

That HD boot order is just the default, though. In BIOSes where
the HD boot order can be adjusted by the user, the boot priority
follows the new boot order. My experiments have shown that the
meaning of "rdisk()" also follows the new boot order, so that
"rdisk(0)" refers to whatever HD is at the head of the ordered list,
and "rdisk(1)" refers to the next HD in that list, etc. For that reason,
"rdisk(x)" may thought of as "The HD at Relative Position 'x' in
the HD Boot Order", where 0 refers to the HD at the head of the list.
This has great impact on the meaning of the entries in the boot.ini
file. For a thorough description of the experiments which led to
this conclusion, see Groups.Google.com in this NG in the past
2 months for the thread titled "meaning of 'rdisk()' in boot.ini file".

Here it is again for the Googling-deprived:

---------------------------------------------------
ABSTRACT

This investigation shows that the "rdisk()" parameter
in the boot.ini file represents a hard drive in terms of
its displacement from the head of the hard drive boot order
in the BIOS. The value of n in "rdisk(n)" expresses this
displacement, where n is an integer value starting with 0,
and where "rdisk(0)" represents the hard drive which is at
the head of the hard drive boot order, i.e. the hard drive
at zero displacement from the head of the hard drive boot
order. The BIOS used in the investigation was the Phoenix
Technologies BIOS as supplied in Dell Dimension desktop PCs.


HARDWARE

Dell Dimension XPS-R450 with a Phoenix Tech BIOS,
(3) Maxtor DiamondMaxPlus 9 hard drives connected to
(1) SIIG IDE PCI controller card used in the 1st half of
the investigation, and connected to
(1) motherboard IDE controller used in the 2nd half of
the investigation.


HARD DRIVE CONFIGURATION

IDE channel 0, Master - 80GB hard drive
IDE channel 0, Slave - 40GB hard drive
IDE channel 1, Master - 120GB hard drive

Each HD had a Master Boot Record (MBR),
each HD had as its partition #1 a Primary partition
that
1) had a Boot Sector,
2) was marked "Active", and which
3) contained the boot files ntldr, boot.ini, and ntdetect.com .


SOFTWARE CONFIGURATION

Microsoft WindowsXP Pro installed in partition #1 of each HD.

boot.ini file in the 80GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 2, part 1" /fastdetect

boot.ini file in the 40GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 2, part 1" /fastdetect

boot.ini file in the 120GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 2, part 1" /fastdetect


Each of the above boot.ini file entries under the line
"[operating systems]" specified an OS in partition #1 of one
of the HDs, i.e. from "rdisk(0)", "rdisk(1)", or "rdisk(2)".
The character string between the quotes in each OS entry
became a line in the on-screen menu displayed by ntldr at
boot time, and it was to aid in identifying which HD got
control from the BIOS (i.e 80GB, 40GB, or 120GB) and which
"rdisk()" value each line corresponded to.

A file with a name identifying the HD which contained it
was put on the Desktop of each OS. This was to aid in identi-
fying the HD of the OS that was loaded.


EXPERIMENT

Each HD was in turn put at the head of the BIOS's hard drive
boot order and the PC was started. Each of the three entries in
the on-screen boot menu was selected in turn, and the OS that
loaded was recorded. Since the boot.ini files contained entries
only for the partition #1 on each HD, the experiment was a specific
test for the meaning of the "rdisk()" parameter.

Then the order of the 2nd and 3rd HD in the hard drive boot order
was reversed in the BIOS, and the above experiment was repeated.

Then, the hard drives were disconnected from the IDE PCI controller
card and connected to the IDE controller on the motherboard, and the
entire experimental sequence detailed above was repeated. A total of
36 boot-ups were executed.


RESULTS

The following results were identical for both the PCI IDE controller
case and for the motherboard IDE controller case:

HD boot order: 80GB, 40GB, 120GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 80GB, 120GB, 40GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1

HD boot order: 40GB, 80GB, 120GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 40GB, 120GB, 80GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 40GB, 80GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 80GB, 40GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1


DISCUSSION

The OS always booted from the hard drive having a position in
the hard drive boot order expressed as the n in "rdisk(n)" parameter
of the boot.ini file entry. This correspondence persisted throughout
all all permutations of the hard drive boot order and despite which
IDE controller the HDs were connected to. Whether this is the case
in other less common BIOSes is unknown by this investigator. But
since the Phoenix Technologies' BIOSes are used by many large
PC manufacturers, it is probably a very common meaning of "rdisk()"
among modern PCs running a Microsoft Windows operating system.


*TimDaniels*

Timothy Daniels wrote:
"Anna" wrote:
Tim:
Let me cite some of my experiences using disk imaging
programs to directly clone the contents of one HD to
another HD and how, for the most significant part, they
parallel your experiences with one or two exceptions. And,
of course, we're speaking about PATA drives here...

1. As I think you know from our past exchanges, I primarily
use the Ghost 2003 disk imaging program to perform direct
disk-to-disk cloning operations although I have used other
DI programs as well, chiefly the Acronis True Image version 8
program. So my comments pretty much refer to the use of
those programs in this area.

2. I most certainly agree with you that it is important, if not
crucial, for the user to disconnect the source disk immediately
following the cloning operation and make that initial boot with only the
newly-cloned HD connected. Future boot problems with that
cloned drive may (but not *always*) occur if the preceding is not
adhered to. At least that has been our experience with the
Ghost & ATI programs, and from reports that I've received from
those who have used other DI programs, the same potential
problem can occur. (BTW, we have run into the same problem
with SATA drives). Incidentally, this potential problem can occur
even if the BIOS boot order priority was changed to make that
initial boot from the cloned HD while both the source & destination
drives were connected at the time of the initial boot to the cloned
HD. The important thing is to disconnect the source disk before
the initial boot to the newly-cloned HD.

3. However, we have never encountered a subsequent boot
problem with the cloned HD if it later was connected as a
secondary drive. At least I can't recall a single problem in this
area. Again, as long as the *initial* boot with that cloned HD
had been undertaken with the source drive disconnected as
indicated above, it didn't matter that the cloned drive was, at
one time or another, later used as a secondary drive. We've
always been able to boot to that cloned drive at some
subsequent time either with the source HD disconnected or
a change in the BIOS boot order should both drives be
connected at the time of that boot.

In this connection - we're assuming two bootable HDs in the
machine - our experience with modern motherboards - let's
say about the past five years - has been (with rare exceptions)
that regardless of the IDE channel (or its position on that
channel) that a bootable HD is connected to, the system will
boot to that drive if it's the only bootable HD currently present in
the system. (A BIOS item change is sometimes necessary to
facilitate this action). I'm not sure if your experience has been
different from mine in this area.

As I've posted in this and other threads in this NG, my experience has
been identical to yours. I've even posted, in detail, experiments which
I have run regarding boot order and its effect on the meaning of
"rdisk()" in boot.ini file's ARC pathname entries.

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so ****ed that it actually does it that way.

As for the HD boot order, the result of removal of the existing booting
HD is that some other HD in the HD boot order
(if one exists) is given control by the BIOS to do the booting.

Not necessarily. With some you just get to boot off a non HD instead.

That HD is just the next HD in the HD boot order.

There isnt necessarily any HD boot order at all.

If the currently-booting HD is Master on ch. 0, the next will be the
Slave on ch. 0. If there is no HD as Slave on ch. 0, the HD that is
Master on ch. 1 becomes the boot HD, etc.

Not necessarily again.

That HD boot order is just the default, though.

There isnt necessarily any HD boot order at all.

In BIOSes where the HD boot order can be adjusted by the user, the boot
priority follows the new boot order. My experiments have shown that the
meaning of "rdisk()" also follows the new boot order,

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so ****ed that it actually does it that way.

so that "rdisk(0)" refers to whatever HD is at the head of the ordered
list, and "rdisk(1)" refers to the next HD in that list, etc. For that
reason, "rdisk(x)" may thought of as "The HD at Relative Position 'x' in
the HD Boot Order", where 0 refers to the HD at the head of the list.

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so ****ed that it actually does it that way.

This has great impact on the meaning of the entries in the boot.ini file.

No you didnt, ALL you ever did was show that THAT PARTICULAR
BIOS does it that way and your nose was rubbed in the FACT that
that is very very uncommon to do it that way.

It isnt even clear if there is actually another bios anywhere
that is so ****ed that it actually does it that way.

Reams of pig ignorant silly stuff that proves absolutely
NOTHING about bios in general flushed where it belongs.

"Rod Speed" got stuck in a groove:
ALL you ever did was show that THAT PARTICULAR
BIOS does it that way...


All WindowsNT/2K/XP OSes do it that way - it's
built into ntldr, the WinNT/2K/XP boot loader. ntldr
doesn't care what BIOS placed the information in the
set location - it's defined for the PC architecture - ntldr
just accesses that information where that information
is supposed to be, and the definition of "rdisk()" follows
from that. If your PC is to run a modern version of
Windows, it had better work that way, and you'd better
learn to set "rdisk()" that way if you expect to do any
multi-booting or anything else that involves editing
the boot.ini file.

*TimDaniels*

On Mon, 20 Mar 2006 13:20:11 -0600, "Bob Davis"
wrote:


"Andy" wrote in message
.. .

When Windows sees two identical drives, it changes the disk signature
of the second one. So if you want to be able to boot the clone, save a
copy of the orignal drive's MBR. When it becomes time to boot the
clone, replace the clone's MBR with the one you saved. Then you'll be
able to boot the clone.

Interesting. How do you do that?

MBRWizard - The MBR utility you've been looking for!
http://mirror.href.com/thestarman/asm/mbr/MBRWiz.html

An Examination of the
Windows 2000 ( NT5.0 )
and
Windows XP ( NT5.1 )
MBR ( Master Boot Record )
http://mirror.href.com/thestarman/asm/mbr/Win2kmbr.htm

Timothy Daniels pig ignorantly lied
Rod Speed wrote

ALL you ever did was show that THAT PARTICULAR BIOS does it that way...

All WindowsNT/2K/XP OSes do it that way

Wrong, as always. Its got absolutely NOTHING to do
with the OS at all, just what the rdisk() param means.

- it's built into ntldr, the WinNT/2K/XP boot loader.

Not what the rdisk() parameter means it isnt.

ntldr doesn't care what BIOS placed the information in the set location -
it's defined for the PC architecture

Not what the rdisk() parameter means it isnt.

- ntldr just accesses that information where that information is supposed
to be, and the definition of "rdisk()" follows from that.

No it doesnt. The rdisk() parameter is NOT
the number in the HD boot order list.

And MS nor anyone else has ever said that the rdisk()
parameter is the order in the HD boot order list.

I've seen no evidence what so ever that anything other
than that particularly ****ed bios you have does it that way.

And its a terminally stupid way to do it too because
if you change the HD boot order list order, you have
to manually edit the boot.ini. Which is why it aint done
that way on any other bios except your completely
****ed one and I bet its just a bug in that one.

If your PC is to run a modern version of Windows, it had better work that
way, and you'd better learn to set "rdisk()" that way if you expect to do
any multi-booting or anything else that involves editing the boot.ini
file.

Thanks for that completely superfluous proof that you have
never ever had a ****ing clue about anything at all, ever.

When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.

"Rod Speed" wrote:
When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.


Those fixed-order BIOSes are from the Old World, Roddles.
Give up that Altos or Amiga PC that you found at a landfill, and
move up into the light of Modern Day.

*TimDaniels*

"Rod Speed" wrote in message
...

The idea apparently is that NT/2K/XP can get identical folders and files
confused on the two drives,

Mindlessly silly.


It seems that way to me too, but Timothy says he's seen it happen.


This sounds specious to me, as how could the OS confuse two different
drive letters?

Maybe they were suggesting that the USER might get confused.


I don't think that's what they were suggesting.


Anyway, in the interest of safety I still try to keep the clone detached
when possible.

That is a bit safer if you want to protect yourself
against the very unlikely possibility of the power
supply dying and frying both drives at once.


Very good point.


that is outside my experience, but I can't imagine ever doing it.

Quite a few do, basically to try the clone after
creating it to be sure that it can be booted.


Makes sense, but I've restored a clone enough that I feel confident in its
integrity.


Yep, if you boot the clone without the original being visible,
it will claim to have found new hardware and will ask to be
allowed to reboot. Once you have rebooted, you can make
the original visible to the system again and you will be able
to boot either of the copys with impunity.


Actually, I just get the "found new hardware" and usually another cryptic
message, then it goes on about its business with no prompt to reboot. It's
been a while since I did it, but that's my recollection.


but cloning in Ghost 2003 has become a ritual for years, and it has never
failed me.

Its significantly crippled in capability.

If it ain't broke....

It is significantly crippled in capability.


It works, and I don't ask to to do much, just clone the drive.


I do it every Sat. morning and not doing so would prolly confuse me for
the rest of the day.

Your problems with OCD are your problem.


I don't have any problems with cloning and have no reason to change. This
procedure has worked for many years, through earlier versions of Ghost.


Windows will look at the system, scan the registry, realizes its
duplicated and deems it's corrupt.

Wrong.


That one sounded a bit over the top to me too.


CAUTION: Do not start the computer after cloning until the
instructions say to do so. Starting a computer from the hard drive
when the computer has two Active partitions can damage program
installations and trigger configuration changes that you might not be
able to reverse without restoring backups.

Just plain wrong. The ONLY thing that you should
avoid is booting the clone with the original visible.

And its completely trivial to test this and prove it.


For me, a red flag always goes up when the software manufacturer issues a
warning this dire. If it makes no sense, I figure I'm missing something.
Thus, in this case I don't do it, and have adapted. That said, I have no
problem inserting the clone to retreive a file, but I just don't leave it in
like I did with Win9x. And like you said, it's safer that way anyway.

"Timothy Daniels" wrote in message
...

The clone only has to be isolated from its "parent" OS
when it's started for its first time.

I can't imagine a scenario when I would boot from the clone with the parent
present. But what about keeping D: as a clone of C: in the machine at all
times? IOW, a clone of C: is made to D:, then you restart XP from C: as
usual and keep D: installed?

I know you can do this with Win9x, as I did it for years--but the caveats
I've seen apparently refer to NT-based OS's (NT, 2K, and XP).

Bob Davis wrote
Rod Speed wrote

The idea apparently is that NT/2K/XP can get identical folders and
files confused on the two drives,

Mindlessly silly.

It seems that way to me too, but Timothy says he's seen it happen.

ONLY if you boot the clone with the original visible.

He said that too.

This sounds specious to me, as how could the OS confuse two different
drive letters?

Maybe they were suggesting that the USER might get confused.

I don't think that's what they were suggesting.

Bet it was if you dont boot the clone with the
original visible for the first boot of the clone.

Or they never did understand that you cant
let the first boot of the clone see the original.

Anyway, in the interest of safety I still try to keep the clone
detached when possible.

That is a bit safer if you want to protect yourself
against the very unlikely possibility of the power
supply dying and frying both drives at once.

Very good point.

But only with internal drives and those in removable
bay kits or eSATA powered from that power supply etc.

If you clone a new drive and then use it as the replacement for C:,
you've just booted from the clone, and I've done this many times. If
you mean boot with the clone with the original drive also on line,
that is outside my experience, but I can't imagine ever doing it.

Quite a few do, basically to try the clone after
creating it to be sure that it can be booted.

Makes sense, but I've restored a clone enough that I feel confident in
its integrity.

Restoring a clone is much more dangerous
when you are testing the backup approach.

Yep, if you boot the clone without the original being visible,
it will claim to have found new hardware and will ask to be
allowed to reboot. Once you have rebooted, you can make
the original visible to the system again and you will be able
to boot either of the copys with impunity.

Actually, I just get the "found new hardware" and usually another
cryptic message, then it goes on about its business with no prompt to
reboot. It's been a while since I did it, but that's my recollection.

Bet you're remembering it wrong.

but cloning in Ghost 2003 has become a ritual for years, and it has
never failed me.

Its significantly crippled in capability.

If it ain't broke....

It is significantly crippled in capability.

It works, and I don't ask to to do much, just clone the drive.

You get a lot more capability with True Image, being able to
image over the lan effortlessly, incremental images, full file
level backups, etc etc etc. Those last two are much better
for your second level backups than your current approach.

I do it every Sat. morning and not doing so would prolly confuse me for
the rest of the day.

Your problems with OCD are your problem.

I don't have any problems with cloning

OCD is obsessive compulsive disorder
and is a problem between your ears.

and have no reason to change.

Yes you do, True Image would be a much cleaner
approach with the secondary backups you do too.

This procedure has worked for many years, through earlier versions of
Ghost.

And is way past its useby date now for the secondary
backups you do that Ghost cant even do.

Windows will look at the system, scan the registry, realizes its
duplicated and deems it's corrupt.

Wrong.

That one sounded a bit over the top to me too.

Yeah, Radified has always been riddled
with over the top pig ignorant crap.

They cant even manage the basics, compare
the two drives and see what actually got
changed. The registry never did get corrupted.

CAUTION: Do not start the computer after cloning until the
instructions say to do so. Starting a computer from the hard drive when
the computer has two Active partitions can damage program installations
and trigger configuration changes that you might not be able to reverse
without restoring backups.

Just plain wrong. The ONLY thing that you should
avoid is booting the clone with the original visible.

And its completely trivial to test this and prove it.

For me, a red flag always goes up when the software manufacturer issues a
warning this dire. If it makes no sense, I figure I'm missing something.

You arent, that claim is just plain wrong.

The only thing the active flag does is allow the bios
which partition to boot on a particular physical drive.

The fool that wrote that is just mindlessly repeating the drivel
thats been pig ignorantly spouted on the net for decades now.

Thus, in this case I don't do it, and have adapted.

Makes more sense to test the claim instead and prove its wrong.

That said, I have no problem inserting the clone to retreive a file, but
I just don't leave it in like I did with Win9x. And like you said, it's
safer that way anyway.

The risk of the power supply failing and killing both drives is very low.

Timothy Daniels wrote
Rod Speed wrote

When the rdisk() parameter is the order of the physical
drives on the controllers, it works fine and you dont have
to manually edit the boot.ini when you change the HD
boot order list order either deliberately or when there
has been a failure of one of the drives in that list.

Those fixed-order BIOSes are from the Old World

I wasnt talking about any fixed order bios, child.

I was talking about drives that do have a HD boot
order list but dont use that for the rdisk() parameter.
The rdisk() parameter is the physical order of the
drives on the controllers, not the HD boot order list.

reams of your puerile **** flushed where it belongs