Sign in with
Sign up | Sign in
Your question

Ghosting system to a different drive number & BOOT.INI

Last response: in Windows XP
Share
Anonymous
August 25, 2005 8:13:06 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Frome what I've gathered from various posts, Ghosting an IDE master to
an IDE slave almost always works because the new drive can be made to
look like the same drive number simply by changing the master/slave jumper.

However, what if the new drive is on another IDE channel (disk 2 versus
disk 0/1) or a SATA drive (disk 4). Such a drive can't be made to look
like the original boot IDE by jumpering, and boot.ini references the
drive and partition number. If these don't match the physical location
of the new drive, Windows won't boot correctly.

What's the recipe to successfully cloning to a different disk number and
have it boot as drive C:?
Anonymous
August 25, 2005 8:13:07 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Animated Shockwave Ghost tutorial with sound
http://www.symantec.com/techsupp/tutorial/ghost_2002/20...

How to perform a disk-to-disk clone
http://service1.symantec.com/SUPPORT/ghost.nsf/pfdocs/2...

--
Carey Frisch
Microsoft MVP
Windows XP - Shell/User
Microsoft Newsgroups

-------------------------------------------------------------------------------------------

"Pat Coghlan" wrote:

| Frome what I've gathered from various posts, Ghosting an IDE master to
| an IDE slave almost always works because the new drive can be made to
| look like the same drive number simply by changing the master/slave jumper.
|
| However, what if the new drive is on another IDE channel (disk 2 versus
| disk 0/1) or a SATA drive (disk 4). Such a drive can't be made to look
| like the original boot IDE by jumpering, and boot.ini references the
| drive and partition number. If these don't match the physical location
| of the new drive, Windows won't boot correctly.
|
| What's the recipe to successfully cloning to a different disk number and
| have it boot as drive C:?
August 25, 2005 9:42:06 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

"Pat Coghlan" <info@coghlan.ca> wrote in message
news:jDpPe.851$Ld.326645@news20.bellglobal.com...
> Frome what I've gathered from various posts, Ghosting an IDE master to an
> IDE slave almost always works because the new drive can be made to look
> like the same drive number simply by changing the master/slave jumper.
>
> However, what if the new drive is on another IDE channel (disk 2 versus
> disk 0/1) or a SATA drive (disk 4). Such a drive can't be made to look
> like the original boot IDE by jumpering, and boot.ini references the drive
> and partition number. If these don't match the physical location of the
> new drive, Windows won't boot correctly.
>
> What's the recipe to successfully cloning to a different disk number and
> have it boot as drive C:?


Pat:
In terms of a disk imaging program such as Symantec's Norton Ghost or
similar program, a clone is a clone is a clone. It makes no difference how
the drives are connected/configured at the time the clone is created. All
that is essential is that the user select the correct source and destination
disks when he or she performs the cloning operation..

After the clone is created, one should ordinarily disconnect the source disk
and boot to the newly-cloned drive. In most (but not all) cases it makes no
difference how that newly-cloned (IDE/PATA) disk is connected/configured,
i.e., whether it's on the Primary or Secondary IDE channel or whether it's
configured as Master or Slave. In most (but again, not all) cases (assuming
you've created a viable clone), the system will boot to that drive. There
are, however, motherboards that will refuse to boot to a bootable drive if
it's not connected/configured as Primary Master. And we've come across a few
motherboards that would permit a boot only if the drive was connected on the
Primary IDE channel (regardless of whether the drive was connected as Master
or Slave). In both cases it involved only a relatively few motherboard
models.

The important thing to remember is that following the disk cloning operation
to boot to the newly-cloned drive that's the *only* storage device connected
during that initial boot whether it's a PATA or SATA drive.. Afterwards it
makes no difference if both drives are connected.
Anna
Related resources
Anonymous
August 26, 2005 4:48:46 AM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

"Pat Coghlan" wrote:
> Yes, but boot.ini points to a disk # and partition #. I think
> everything has to match in order for the new drive to boot
> successfully. I'm not sure how the disk # is determined though.


boot.ini entries include the term "rdisk()" which refers to
the HD's relative position in the BIOS's HD boot order.
The HD named at the head of the list is at relative position 0
and it's referred to as "rdisk(0)". "rdisk(1)" refers to the HD
at the next position in the HD boot order, etc. By looking
at the HD boot order in the BIOS, you can see what all the
rdisk() values refer to.

The partition numbering for boot.ini starts with "1" for the
1st partition, and the term for the 1st partition is "partition(1)".

The boot.ini file used in the boot process is the boot.ini
in the "active" partition of the HD that is at the head of the
BIOS's HD boot order and which has a good Master Boot
Record (MBR). The ntldr program in that "active" partition
displays the contents of the boot.ini file, and it loads the OS
in the partition indicated in the boot.ini entry that is selected -
either by time-out or manually by the user. Note that the OS
to be loaded can be in any partition on any HD in the system.

This also means that you can have several partitions with
the boot.ini/ntlder (and ntdetect.com) files to perform the
loading operation. The one to do it will be the one marked
"active" on the HD that is at the head of the BIOS's HD boot
order. And the HD boot order can set manually in the BIOS
by the user for full control over which boot.ini defines the
OSes which can be loaded.

*TimDaniels*
Anonymous
August 26, 2005 12:13:24 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

> Er, but if the original drive is reconnected, it will once again be the
> detected by the BIOS as the first bootable primary partition, marked as
> drive 0 and Windows will boot from there, no?
>
> Heck, I disabled the primary IDE channel in the BIOS and I still ended
> up with my old D-drive mapped! I'm pretty sure if I reconnect it and
> enable the primary IDE channel, I'll be booting off it again. I'm going
> to take it straight to its new home - a drive upgrade for my in-laws
> computer.
>

This has more to do with the motherboard BIOS than Windows. Some
motherboards will always boot from an IDE device on the primary controller
no matter how you set things up. Sometimes if you change the boot order to
SCSI first it will work, Some motherboards you can pick the drive you want
to be active. Some refuse to cooperate no matter what you do. If this is the
case then you can't boot from a SATA drive if a PATA drive is installed.

Kerry
Anonymous
August 26, 2005 12:42:03 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Timothy Daniels wrote:
> "Pat Coghlan" wrote:
>
>> Yes, but boot.ini points to a disk # and partition #. I think
>> everything has to match in order for the new drive to boot
>> successfully. I'm not sure how the disk # is determined though.
>
> boot.ini entries include the term "rdisk()" which refers to
> the HD's relative position in the BIOS's HD boot order.
> The HD named at the head of the list is at relative position 0
> and it's referred to as "rdisk(0)". "rdisk(1)" refers to the HD
> at the next position in the HD boot order, etc. By looking
> at the HD boot order in the BIOS, you can see what all the
> rdisk() values refer to.

Are rdisk() and disk() mutually exclusive then? What is disk() used to
specify?

> The partition numbering for boot.ini starts with "1" for the
> 1st partition, and the term for the 1st partition is "partition(1)".

I would assume, then, that if a user clones a drive to a different
partition number, the new drive will either not boot or boot a different
OS, if present.

> The boot.ini file used in the boot process is the boot.ini
> in the "active" partition of the HD that is at the head of the
> BIOS's HD boot order and which has a good Master Boot
> Record (MBR). The ntldr program in that "active" partition
> displays the contents of the boot.ini file, and it loads the OS
> in the partition indicated in the boot.ini entry that is selected -
> either by time-out or manually by the user. Note that the OS
> to be loaded can be in any partition on any HD in the system.

So the "active" partition is really just a starting/launch point.

> This also means that you can have several partitions with
> the boot.ini/ntlder (and ntdetect.com) files to perform the
> loading operation. The one to do it will be the one marked
> "active" on the HD that is at the head of the BIOS's HD boot
> order. And the HD boot order can set manually in the BIOS
> by the user for full control over which boot.ini defines the
> OSes which can be loaded.

Thanks for the explanation :-) Much appreciated.
Anonymous
August 26, 2005 1:15:01 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

"Pat Coghlan" wrote:
> Timothy Daniels wrote:
>> "Pat Coghlan" wrote:
>>
>>> Yes, but boot.ini points to a disk # and partition #. I think
>>> everything has to match in order for the new drive to boot
>>> successfully. I'm not sure how the disk # is determined though.
>>
>> boot.ini entries include the term "rdisk()" which refers to
>> the HD's relative position in the BIOS's HD boot order.
>> The HD named at the head of the list is at relative position 0
>> and it's referred to as "rdisk(0)". "rdisk(1)" refers to the HD
>> at the next position in the HD boot order, etc. By looking
>> at the HD boot order in the BIOS, you can see what all the
>> rdisk() values refer to.
>
> Are rdisk() and disk() mutually exclusive then? What is disk() used to
> specify?


I don't know exactly what multi() and disk() are used for. In ALL
multi-booting operations that I've done using several clones on
several HDs, I've never had to touch those parameters in the
boot.ini file. A search in www.Microsoft.com might reveal
something, but those parameters are certainly not well
documented.



>> The partition numbering for boot.ini starts with "1" for the
>> 1st partition, and the term for the 1st partition is "partition(1)".
>
> I would assume, then, that if a user clones a drive to a different
> partition number, the new drive will either not boot or boot a different
> OS, if present.



That is correct. There are two solutions. I use a generic boot.ini
that allows booting to any of 4 partitions on 3 HDs. (This leaves
out the 3rd and 4th partitions of the 3rd HD since ntldr seems
only to display 10 boot menu entries.) Thus, any "parent" and
any clone have the means to boot any OS in the system. You
could also edit the clone's boot.ini file after cloning but before
the clone is booted for its 1st time by booting up the "parent"
OS with the clone present. Remember, though, that the
meaning of the argument in "rdisk()" changes with the BIOS's
HD boot order, so if you remove the "parent" HD, the next HD
in the boot order (usually, but not necessarily, the clone) becomes
rdisk(0).


>> The boot.ini file used in the boot process is the boot.ini
>> in the "active" partition of the HD that is at the head of the
>> BIOS's HD boot order and which has a good Master Boot
>> Record (MBR). The ntldr program in that "active" partition
>> displays the contents of the boot.ini file, and it loads the OS
>> in the partition indicated in the boot.ini entry that is selected -
>> either by time-out or manually by the user. Note that the OS
>> to be loaded can be in any partition on any HD in the system.
>
> So the "active" partition is really just a starting/launch point.


That is correct. It contains the loading and loading info -
what some call the "boot manager", i.e. boot.ini/ntldr/
ntdetect.com files. That "loading partition" is labeled by
Disk Management as the "system" Local Disk (i.e.
partition), and the partition containing the OS that gets
loaded it labels the "boot" Local Disk. Microsoft's use of
"boot" and "system" in this case seems counter-intuitive,
but Hey!, that's Microsoft.



>> This also means that you can have several partitions with
>> the boot.ini/ntlder (and ntdetect.com) files to perform the
>> loading operation. The one to do it will be the one marked
>> "active" on the HD that is at the head of the BIOS's HD boot
>> order. And the HD boot order can set manually in the BIOS
>> by the user for full control over which boot.ini defines the
>> OSes which can be loaded.
>
> Thanks for the explanation :-) Much appreciated.


It's all buried in the Microsoft online documentation for
Windows XP, and it takes some plowing, so few people
have waded through it. Let me know if you figure out
multi() and disk().

*TimDaniels*
August 26, 2005 3:08:44 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

>>"Pat Coghlan" <info@coghlan.ca> wrote in message
>>news:jDpPe.851$Ld.326645@news20.bellglobal.com...
>>>Frome what I've gathered from various posts, Ghosting an IDE master to an
>>>IDE slave almost always works because the new drive can be made to look
>>>like the same drive number simply by changing the master/slave jumper.
>>>
>>>However, what if the new drive is on another IDE channel (disk 2 versus
>>>disk 0/1) or a SATA drive (disk 4). Such a drive can't be made to look
>>>like the original boot IDE by jumpering, and boot.ini references the
>>>drive
>>>and partition number. If these don't match the physical location of the
>>>new drive, Windows won't boot correctly.
>>>
>>>What's the recipe to successfully cloning to a different disk number and
>>>have it boot as drive C:?


>> Anna wrote:
>>Pat:
>>In terms of a disk imaging program such as Symantec's Norton Ghost or
>>similar program, a clone is a clone is a clone. It makes no difference how
>>the drives are connected/configured at the time the clone is created. All
>>that is essential is that the user select the correct source and
>>destination
>>disks when he or she performs the cloning operation..



"Pat Coghlan" <info@coghlan.ca> wrote in message
news:Hb-dnQb6oKYYOZPeRVn-pA@rogers.com...
> Yes, but boot.ini points to a disk # and partition #. I think
> everything has to match in order for the new drive to boot
> successfully. I'm not sure how the disk # is determined though.
>
> I got it to work tonight, but there were a few quirks. For example,
> after the SATA drive came up as the C-drive, the old D-drive (2nd
> partition on original boot IDE) appeared...even though I had disabled
> the drive in the BIOS! The old drive was still connected, but only the
> 2nd partition got mapped to a drive letter. Luckily the old C-drive was
> nowhere to be seen. I went back and disconnected it and restored D: on
> the 2nd SATA partition a second time, after which I had my D-drive back.


>>Anna wrote:
>>After the clone is created, one should ordinarily disconnect the source
>>disk
>>and boot to the newly-cloned drive. In most (but not all) cases it makes
>>no
>>difference how that newly-cloned (IDE/PATA) disk is connected/configured,
>>i.e., whether it's on the Primary or Secondary IDE channel or whether it's
>>configured as Master or Slave. In most (but again, not all) cases
>>(assuming
>>you've created a viable clone), the system will boot to that drive. There
>>are, however, motherboards that will refuse to boot to a bootable drive if
>>it's not connected/configured as Primary Master. And we've come across a
>> >>few motherboards that would permit a boot only if the drive was
>>connected on >>the Primary IDE channel (regardless of whether the drive
>>was connected as >>Master or Slave). In both cases it involved only a
>>relatively few motherboard
>>models.


Pat continues:
> Again, as long as the new drive number matches what is in boot.ini
> everything should work, but what if the drive number in boot.ini is
> hijacked by another drive (or is this impossible, assuming that the
> drive containing the first bootable partition is assigned as drive 0 by
> the BIOS)?


Anna again:
>>The important thing to remember is that following the disk cloning
>>operation
>>to boot to the newly-cloned drive that's the *only* storage device
>>connected
>>during that initial boot whether it's a PATA or SATA drive.. Afterwards it
>>makes no difference if both drives are connected.
>>Anna


Here's Pat again...
> Er, but if the original drive is reconnected, it will once again be the
> detected by the BIOS as the first bootable primary partition, marked as
> drive 0 and Windows will boot from there, no?
>
> Heck, I disabled the primary IDE channel in the BIOS and I still ended
> up with my old D-drive mapped! I'm pretty sure if I reconnect it and
> enable the primary IDE channel, I'll be booting off it again. I'm going
> to take it straight to its new home - a drive upgrade for my in-laws
> computer.


Pat:
With all due respect, you're making this process of cloning the contents of
one hard drive to another hard drive much more complicated than it need be.

Please forget about BIOS detection, modifying the boot.ini file, drive
letter assignments, drive numbers, jumper settings, and the like.

As I previously stated, the process of cloning one internal HD to another
internal HD is relatively simple & straightforward. With your two drives
(source and destination) connected, you use a disk imaging program such as
Symantec's Norton Ghost or Acronis True Image to identify the source disk
(the drive you're cloning FROM) and the destination disk (the drive you're
cloning TO). Two or three keyclicks later the cloning process begins. And
that's it at this point. No need to modify BIOS settings, no need to change
drive letter assignments, no need to modify the boot.ini file (or any other
file), etc., etc.

After the cloning operation has been completed, you disconnect the source
disk and boot up with the destination disk to check that you now have a
viable (bootable) clone. To repeat what I stated before...

In most (but not all) cases it makes no difference how that newly-cloned
(IDE/PATA) disk is connected/configured, i.e., whether it's on the Primary
or Secondary IDE channel or whether it's configured as Master or Slave. In
most (but again, not all) cases (assuming you've created a viable clone),
the system will boot to that drive. There are, however, motherboards that
will refuse to boot to a bootable drive if it's not connected/configured as
Primary Master. And we've come across a few motherboards that would permit a
boot only if the drive was connected on the Primary IDE channel (regardless
of whether the drive was connected as Master or Slave). In both cases it
involved only a relatively few motherboard models.

If you've cloned to a SATA drive the system will ordinarily boot to that
drive without incident.

After you've determined that the cloned drive is bootable, you may want to
change its connection and jumper setting (assuming it's a IDE/PATA disk) to
Primary Master *if* you now want to use that drive as your new working HD.
And, in that instance, of course, you'll change the connection/configuration
of your former source disk. Otherwise, no changes are necessary if you're
simply going to use the newly-cloned drive as your backup drive.
Anna
Anonymous
August 26, 2005 3:08:45 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

"Anna" wrote:
> Pat:
> With all due respect, you're making this process of cloning the contents of
> one hard drive to another hard drive much more complicated than it need be.
>
> Please forget about BIOS detection, modifying the boot.ini file, drive
> letter assignments, drive numbers, jumper settings, and the like.
>
> As I previously stated, the process of cloning one internal HD to another
> internal HD is relatively simple & straightforward. With your two drives
> (source and destination) connected, you use a disk imaging program such as
> Symantec's Norton Ghost or Acronis True Image to identify the source disk
> (the drive you're cloning FROM) and the destination disk (the drive you're
> cloning TO). Two or three keyclicks later the cloning process begins. And
> that's it at this point. No need to modify BIOS settings, no need to change
> drive letter assignments, no need to modify the boot.ini file (or any other
> file), etc., etc.
>
> After the cloning operation has been completed, you disconnect the source
> disk and boot up with the destination disk to check that you now have a
> viable (bootable) clone. To repeat what I stated before...
>
> In most (but not all) cases it makes no difference how that newly-cloned
> (IDE/PATA) disk is connected/configured, i.e., whether it's on the Primary
> or Secondary IDE channel or whether it's configured as Master or Slave. In
> most (but again, not all) cases (assuming you've created a viable clone),
> the system will boot to that drive. There are, however, motherboards that
> will refuse to boot to a bootable drive if it's not connected/configured as
> Primary Master. And we've come across a few motherboards that would permit a
> boot only if the drive was connected on the Primary IDE channel (regardless
> of whether the drive was connected as Master or Slave). In both cases it
> involved only a relatively few motherboard models.
>
> If you've cloned to a SATA drive the system will ordinarily boot to that
> drive without incident.
>
> After you've determined that the cloned drive is bootable, you may want to
> change its connection and jumper setting (assuming it's a IDE/PATA disk) to
> Primary Master *if* you now want to use that drive as your new working HD.
> And, in that instance, of course, you'll change the connection/configuration
> of your former source disk. Otherwise, no changes are necessary if you're
> simply going to use the newly-cloned drive as your backup drive.
> Anna


That is correct. For making a clone to replace the existing OS
hard drive, you don't have to do anything with or know anything
about the BIOS's HD boot order, the boot.ini file contents, and
which partition is marked "active". Using Cable Select (for
Parallel ATA HDs), you don't even have to fiddle with jumpers.
Just put the "parent" at the end connector of the cable and the
clone-to-be at the intermediate connector, do the cloning, then
remove the "parent" HD and put the clone HD in its place, and
fire it up.

An understanding of what you're doing is only necessary if you
do multi-booting, and a deeper understanding is necessary
only if you put several OSes on a single HD.

*TimDaniels*
Anonymous
August 26, 2005 6:37:43 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Timothy Daniels wrote:
>
> That is correct. For making a clone to replace the existing OS
> hard drive, you don't have to do anything with or know anything
> about the BIOS's HD boot order, the boot.ini file contents, and
> which partition is marked "active". Using Cable Select (for
> Parallel ATA HDs), you don't even have to fiddle with jumpers.
> Just put the "parent" at the end connector of the cable and the
> clone-to-be at the intermediate connector, do the cloning, then
> remove the "parent" HD and put the clone HD in its place, and
> fire it up.
>
> An understanding of what you're doing is only necessary if you
> do multi-booting, and a deeper understanding is necessary
> only if you put several OSes on a single HD.

Do programs like Ghost clone an entire physical drive (including MBR and
all partitions) or just individual partitions? In the case of the
former, the new drive will be a replica of the old drive in terms of
number of partitions and their types...with additional unallocated space
on it. In the case of the latter, there must be an underlying assumption
that the original drive has Windows in the first (primary) partition and
that the clone is being performed to the first primary partition on the
new drive, otherwise there is the potential for the clone to not work as
expected.
Anonymous
August 26, 2005 6:37:44 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

"Pat Coghlan" wrote:
> Timothy Daniels wrote:
>>
>> That is correct. For making a clone to replace the existing OS
>> hard drive, you don't have to do anything with or know anything
>> about the BIOS's HD boot order, the boot.ini file contents, and
>> which partition is marked "active". Using Cable Select (for
>> Parallel ATA HDs), you don't even have to fiddle with jumpers.
>> Just put the "parent" at the end connector of the cable and the
>> clone-to-be at the intermediate connector, do the cloning, then
>> remove the "parent" HD and put the clone HD in its place, and
>> fire it up.
>>
>> An understanding of what you're doing is only necessary if you
>> do multi-booting, and a deeper understanding is necessary
>> only if you put several OSes on a single HD.
>
> Do programs like Ghost clone an entire physical drive (including MBR
> and all partitions) or just individual partitions? In the case of the
> former, the new drive will be a replica of the old drive in terms of
> number of partitions and their types...with additional unallocated space
> on it. In the case of the latter, there must be an underlying assumption
> that the original drive has Windows in the first (primary) partition and
> that the clone is being performed to the first primary partition on the
> new drive, otherwise there is the potential for the clone to not work as
> expected.


Ghost 9.0 (and its predecessor, Powerquest's Drive Image 7)
clone a designated partition at a time. During the setup of the
process, the options are given to clone the MBR and to mark
the resulting partition "active". There is no assumption about
the position of the source partition. In Casper XP, the MBR
is copied if the destination HD doesn't have one, and the
resulting partition is marked "active" (if I recall correctly). For
cloning, I prefer the simplicity (and lower price) of Casper XP.
Casper XP also does NOT require MS's .NET Framework,
but since .NET Framework will be needed for more and more
apps in the future, that may be a moot advantage.

Partition Magic will also clone single partitions, but PM wants
first to compact the partitions together that may already exist
on the destination HD before making its clone, and that can
take a lot of time - approximately the time to do a cloning for
each partition that is moved. Since I use clones to keep
several archived copies of an entire OS as immediately-
bootable backups on a single large HD (on a removable tray),
such shuffling of partitions are prohibitive for me.

Of course, the newer partitions are a little larger (generally) than
the ones that they are replacing. So what I do before cloning
a partition is to use Partition Magic to shrink the partition a
little to remove some of its unused space. Then it will fit into
the space left by a partition that has been removed to make
way for it on the archival HD.

*TimDaniels*
Anonymous
August 26, 2005 9:24:24 PM

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

"Timothy Daniels" wrote:
> Of course, the newer partitions are a little larger (generally) than
> the ones that they are replacing. So what I do before cloning
> a partition is to use Partition Magic to shrink the partition a
> little to remove some of its unused space. Then it will fit into
> the space left by a partition that has been removed to make
> way for it on the archival HD.


What I should have said is:

"In case the newer partition may not fit exactly into the space of
the older partition which it will replace, I use Partition Magic to
shrink the new partition a little to remove some of its unused
space."

*TimDaniels*
!