Trouble cloning XP with Ghost 2003

[Timothy Daniels]

:>>
.........if booted with a new clone with

Ignoring the term "proper boot device", and assuming
that the "new hardware installed" is the new HD itself,
it doesn't explain what causes the apparent "binding"
of the 2 OSes if the clone sees the "parent" on 1st boot.

In trying that very scenario, I got inconsistent results, but
on one occasion, I found that the clone that had been
started for the 1st time with the "parent" visible had its
My Documents folder pointing to files in its "parent".
The clone ran OK, but if I removed the "parent", I
could no longer access the files in My Documents.
At that point, I concluded that Rod Speed's warning
about not starting the clone for the 1st time in the
presence of its "parent" had some truth. But neither
of us knows what the mechanism is that causes it and
how making the "parent" absent avoids it.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

Bob Davis said:
"you can't/shouldn't have a clone of XP running together with
the normal boot drive housing the OS, although I've booted
many times with a clone attached with no adverse effects."

Sure, I was just commenting on the last bit of his, not that bit.

I should have said that more carefully.

One can certainly continue to boot the old OS with the new OS
in the system and visible to the old OS - and do it indefinitely -
with no advers effects. The problem arises when the new OS
(the clone) is booted for the 1st time and the old OS (the "parent")
is visible to it during that 1st boot. IOW, it's when the clone
is loaded and started for the 1st time that is critical, not just
being visible as a file structure (as it would be if the "parent"
were always the OS that was booted). This you and I know,
but it was not what the OP wrote.
Correct.

This was a comment on the term "proper boot device".
The "boot device" is, indeed, established by the boot
order in the BIOS and the 1st device in that order that
is capable of booting.

Not once XP gets involved in the boot. THEN it gets
complicated if you boot the clone with the original
still visible to XP in the first boot after the cloning.

In the case of hard drives, the "active" partition on the selected HD is
expected to have a boot sector and the files boot.ini, ntldr, ntdetect.com,and
perhaps others.

Only if the OS is of the NT/2K/XP family.

The boot.ini contains the menu of partitions from which ntldr is to load
the OS from. In a clone, the boot.ini will be exactly as it was in the
"parent", and when booted in isolation, the clone will behave exactly
like the parent did because its boot.ini is exactly like its
"parent's" boot.ini .

Doesnt explain how XP gets royally confused on the
first boot after a clone has been made, with the original
still visible to XP, so you cant physically unplug the
original later and still have it boot properly. Essentially
because that boot involves the original drive and it goes
flat on its face if you remove the original later coz its gone.

Presumably, the "parent's" boot.ini had as a default an instruction like
"boot from the 1st HD in the boot order, and look in its 1st partition for the
OS". This boot.ini would be coded something like this:

[boot loader]
timeout=0
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /fastdetect

This says that the only optional OS is the same as the default,
and both are to be found on the 1st HD in the HD boot order
(i.e. at relative position 0), and the OS is in the 1st partition of
that HD. Since the timeout is set to 0, no menu will appear
on the screen and ntldr will attempt to load the default OS.

In fact a default install with only a single OS on the
physical drive gets a timeout=30 and you dont see
any menu at all, it just boots the only OS listed.

Now if you have multiple clones in multiple HDs, such as I have, you can
have the boot.ini file in partition 2 of HD 1 specify the OS in partition 4 of
HD 3 to load. IOW, the boot.ini doesn't have to be in the partition that
contains the OS. It can specify *any* partition on *any* HD in the system.
Sure.

Of course! That's the point of the entire discussion.

But not with your comments about that being a deliberate
attempt by MS to prevent cloning of a physical drive.

 

[Rod Speed]

Ignoring the term "proper boot device", and assuming
that the "new hardware installed" is the new HD itself,
it doesn't explain what causes the apparent "binding"
of the 2 OSes if the clone sees the "parent" on 1st boot.

In trying that very scenario, I got inconsistent results, but
on one occasion, I found that the clone that had been
started for the 1st time with the "parent" visible had its
My Documents folder pointing to files in its "parent".

That doesnt really make much sense, the english doesnt.

Wanna try that again ?

The clone ran OK, but if I removed the "parent", I
could no longer access the files in My Documents.
At that point, I concluded that Rod Speed's warning
about not starting the clone for the 1st time in the
presence of its "parent" had some truth. But neither
of us knows what the mechanism is that causes it and
how making the "parent" absent avoids it.

Wrong. The reason it works if the original isnt visible on the
first boot of the clone is because XP detects a change to the
hardware, claims it sees new hardware, asks for a reboot
to allow the changes it makes on the clone to take effect,
and that ensures that the files on the original a no longer
involved in the boot of the clone and so you can safely
physically remove the original drive and the boot of the
clone will still work fine.

 

[Timothy Daniels]

That doesnt really make much sense, the english doesnt.

Wanna try that again ?

When I accessed the files in My Documents of the clone
system, I was actually accessing the files in the "parent"
system. IOW, My Documents was not a folder in the clone,
it was a pointer (or the equivalent thereof) to a folder in the
"parent" system. When I modified files in the My Documents
folder of the clone, I noticed that the corresponding files in
the My Documents folder of the "parent" system had been
changed. That is an example of what I refer to as the clone
"setting its pointers to point to files in the parent". Then, when
I removed the "parent" system (by shutting down, removing
the power to the "parent" HD, and booting up the clone again),
the files that had been in the clone's My Documents folder
were gone. Now I was upset by that, and all I could think was
"that friggin' Rod Speed was right!". And then I wiped out the
clone and remade it, started it up in isolation, checked
My Documents for its contents, modified a file, then shut down,
reconnected the "parent" HD, and booted up the clone again
with the "parent" visible to it, and checked the modified file in
the clone (it was still modified) and checked the corresponding
file in the "parent" (it was unmodified) - all as you'd expect.
And then I muttered again, "that frigging' Rod Speed was right!".
I must admit that I did not do that investigation slowly and
carefully. But it was enough to convince me that the procedure
of isolating the clone at its 1st startup was a Good Thing.

Wrong. The reason it works if the original isnt visible on the
first boot of the clone is because XP detects a change to the
hardware, claims it sees new hardware, asks for a reboot
to allow the changes it makes on the clone to take effect,
and that ensures that the files on the original a no longer
involved in the boot of the clone and so you can safely
physically remove the original drive and the boot of the
clone will still work fine.

That's not what I do. I remove the original drive BEFORE
I start up the clone system. And that is what you appeared
to have been saying for the past couple of years. Are you
actually now saying that you leave the original connected
when you start up the clone for the 1st time?

BTW, the hardware detection phase for WinNT, Win2K and
WinXP occurs in NTDETECT.COM, one of the files below
the root of the system partition. Since that partition needn't
contain the OS that is loaded by ntldr, it's not actually part of
Windows XP per se, but it is used by ntldr so that ntldr can
tell ntoskrnl.exe what hardware is present. And it is ntoskrnl.exe
that is part of the boot partition, i.e. the partition that contains the
operating system to be loaded by ntldr, so by the time that WinXP
(or WinNT or Win2K) are started, the hardware detection has
been completed. My guess is that ntoskrnl.exe, using information
from NTDETECT.COM, does the bad stuff to the clone.

*TimDaniels*

 

[Timothy Daniels]

Not once XP gets involved in the boot. THEN it gets
complicated if you boot the clone with the original
still visible to XP in the first boot after the cloning.

Yes. The above comment was not an explanation of
how the clone gets bolloxed, but merely an explanation
on how the "boot device" is chosen.

Only if the OS is of the NT/2K/XP family.

Yes, and I believe only that family experiences the
phonomenon of bolloxed clones when the clones
are started up for the 1st with the "parent" OS
visible to it.

Doesnt explain how XP gets royally confused on the
first boot after a clone has been made, with the original
still visible to XP, so you cant physically unplug the
original later and still have it boot properly. Essentially
because that boot involves the original drive and it goes
flat on its face if you remove the original later coz its gone.

It wasn't meant to be an explanation of how the clone
"gets confused". It's an explanation of why the clone
can boot up at all when the "parent" is absent.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

When I accessed the files in My Documents of the clone
system, I was actually accessing the files in the "parent"
system. IOW, My Documents was not a folder in the clone,
it was a pointer (or the equivalent thereof) to a folder in the
"parent" system. When I modified files in the My Documents
folder of the clone, I noticed that the corresponding files in
the My Documents folder of the "parent" system had been
changed. That is an example of what I refer to as the clone
"setting its pointers to point to files in the parent". Then, when
I removed the "parent" system (by shutting down, removing
the power to the "parent" HD, and booting up the clone again),
the files that had been in the clone's My Documents folder
were gone.

OK, thats what I thought you meant. I might try it and see.

Now I was upset by that, and all I could think was"that friggin' Rod Speed
was right!".

I NEVER frig and I never do that in the riggin either.

And then I wiped out the clone and remade it, started it up in isolation,
checked My Documents for its contents, modified a file, then shut down,
reconnected the "parent" HD, and booted up the clone again
with the "parent" visible to it, and checked the modified file in
the clone (it was still modified) and checked the corresponding
file in the "parent" (it was unmodified) - all as you'd expect.
And then I muttered again, "that frigging' Rod Speed was right!".
I must admit that I did not do that investigation slowly and
carefully. But it was enough to convince me that the procedure
of isolating the clone at its 1st startup was a Good Thing.

Yeah, I might check what XP actually does to the clone
drive when it claims to detect new hardware when you
boot with the original not visible and allow it to reboot.

That's not what I do. I remove the original drive BEFORE I start up the
clone system.

Thats what I was saying there, tho the
sentance is a tad long and complicated.

And that is what you appeared to have been saying for the past couple of
years. Are you actually now saying that you leave the original connected
when you start up the clone for the 1st time?

Nope, the exact opposite of that. What you say there
I have been saying for the past couple of years, again.

BTW, the hardware detection phase for WinNT, Win2K and
WinXP occurs in NTDETECT.COM, one of the files below
the root of the system partition. Since that partition needn't
contain the OS that is loaded by ntldr, it's not actually part of
Windows XP per se, but it is used by ntldr so that ntldr can
tell ntoskrnl.exe what hardware is present. And it is ntoskrnl.exe
that is part of the boot partition, i.e. the partition that contains the
operating system to be loaded by ntldr, so by the time that WinXP
(or WinNT or Win2K) are started, the hardware detection has
been completed. My guess is that ntoskrnl.exe, using information
from NTDETECT.COM, does the bad stuff to the clone.

Could be.

 

[Andy]

When I accessed the files in My Documents of the clone
system, I was actually accessing the files in the "parent"
system. IOW, My Documents was not a folder in the clone,
it was a pointer (or the equivalent thereof) to a folder in the
"parent" system. When I modified files in the My Documents
folder of the clone, I noticed that the corresponding files in
the My Documents folder of the "parent" system had been
changed. That is an example of what I refer to as the clone
"setting its pointers to point to files in the parent". Then, when
I removed the "parent" system (by shutting down, removing
the power to the "parent" HD, and booting up the clone again),
the files that had been in the clone's My Documents folder
were gone. Now I was upset by that, and all I could think was
"that friggin' Rod Speed was right!". And then I wiped out the
clone and remade it, started it up in isolation, checked
My Documents for its contents, modified a file, then shut down,
reconnected the "parent" HD, and booted up the clone again
with the "parent" visible to it, and checked the modified file in
the clone (it was still modified) and checked the corresponding
file in the "parent" (it was unmodified) - all as you'd expect.
And then I muttered again, "that frigging' Rod Speed was right!".
I must admit that I did not do that investigation slowly and
carefully. But it was enough to convince me that the procedure
of isolating the clone at its 1st startup was a Good Thing.




That's not what I do. I remove the original drive BEFORE
I start up the clone system. And that is what you appeared
to have been saying for the past couple of years. Are you
actually now saying that you leave the original connected
when you start up the clone for the 1st time?

BTW, the hardware detection phase for WinNT, Win2K and
WinXP occurs in NTDETECT.COM, one of the files below
the root of the system partition. Since that partition needn't
contain the OS that is loaded by ntldr, it's not actually part of
Windows XP per se, but it is used by ntldr so that ntldr can
tell ntoskrnl.exe what hardware is present. And it is ntoskrnl.exe
that is part of the boot partition, i.e. the partition that contains the
operating system to be loaded by ntldr, so by the time that WinXP
(or WinNT or Win2K) are started, the hardware detection has
been completed. My guess is that ntoskrnl.exe, using information
from NTDETECT.COM, does the bad stuff to the clone.

Since you're interested in getting to the bottom of this conundrum,
let me suggest the following course of action:
1. Make the clone.
2. Save the MBR of the clone drive using the DOS version of MBRWizard
<http://www.geocities.com/thestarman3/asm/mbr/BootToolsRefs.htm#TOOLS>.
3. Boot from the old disk with the clone drive attached.
4. Save the MBR of the clone drive again, and compare the Disk
Signatures
<http://www.geocities.com/thestarman3/asm/mbr/Win2kmbr.htm>.
The Disk Signature of the clone has been changed, because Windows
cannot operate with two identical drives.
5. Boot from the clone with the old disk attached, and run Disk
Management to see where the Page File is located. The old disk remains
as drive C:, and the Page File is on the old disk, because the
registry points to drive C:.
6. Remove the old disk and boot from the clone. You may get a "cannot
create Page File" error, or it just won't boot, because the Disk
Signature in the MBR does not match the ones in the registry.
7. Using the DOS version of MBRWizard restore the original MBR to the
clone disk, and boot from the clone disk without the old disk
attached. It boots okay and runs as C:.

 

[BBUNNY]

Where did you come from 24hoursupport.helpdesk?? 207 lines and you
don't say anything/