Why won't clone boot?

[Guest]

On my system I had two physical drives, let's call them the Red and Blue
drives.
RED: Primary Master (80h to the BIOS), Volumes C: and others
BLUE: Primary Slave (81h), Volumes G: and others
After using them this way for a few months wanged BLUE to be my only drive
so I:

1. formatted G:
2. used norton Ghost to create an image of my C: (system) volume
3. restored the image to G:
4. Removed RED from the computer
5. Made BLUE the primary master

Now when I attempt to boot from BLUE the system boots until it gets to the
blue WindowsXP screen with the Windows logo and then it hanges. (This is
very far along in the boot process.)

CLUE: Once it, during booting, decided that it was necessary to run Chkdsk
on it and it said it was checking "G", not "C". Now this is strange since
it was booting from that partition, it was on the only drive in the system,
and the volume ID was the same as the C: on RED (I later checked both
volume IDs and they were the same - the entire volumes appear to be
identical.

Why won't it boot?

How does XP know that, prior to restoring the image of RED C: it used to be
drive G:?

Many thanks for any help.

 

[Michal Kawecki]

[...]
CLUE: Once it, during booting, decided that it was necessary to run
Chkdsk on it and it said it was checking "G", not "C". Now this is
strange since it was booting from that partition, it was on the only
drive in the system, and the volume ID was the same as the C: on RED
(I later checked both volume IDs and they were the same - the entire
volumes appear to be identical.

Why won't it boot?

How does XP know that, prior to restoring the image of RED C: it used
to be drive G:?

You must make a _disk signature_ equally on both drives - not Volume ID.
Or, simply clear this signature with fdisk /mbr. More is on
http://www.goodells.net/multiboot/notes.htm.

 

[I'm Dan]

On my system I had two physical drives, let's call them the Red and
Blue drives.
RED: Primary Master (80h to the BIOS), Volumes C: and others
BLUE: Primary Slave (81h), Volumes G: and others
After using them this way for a few months wanged BLUE to be
my only drive so I:

1. formatted G:
2. used norton Ghost to create an image of my C: (system) volume
3. restored the image to G:
4. Removed RED from the computer
5. Made BLUE the primary master

Now when I attempt to boot from BLUE the system boots until it
gets to the blue WindowsXP screen with the Windows logo and
then it hanges. (This is very far along in the boot process.)

CLUE: Once it, during booting, decided that it was necessary to
run Chkdsk on it and it said it was checking "G", not "C". Now
this is strange since it was booting from that partition, it was on
the only drive in the system, and the volume ID was the same as
the C: on RED (I later checked both volume IDs and they were
the same - the entire volumes appear to be identical.

Why won't it boot?

How does XP know that, prior to restoring the image of RED
C: it used to be drive G:?

Very common problem on all the NT-family OS's (NT/2K/XP), and caused by
the manner in which they "remember" drive letters. XP calculates a
drive "signature" for each partition, such as your BLUE primary, and
stores it in the registry, where it associates that signature with the
letter "G:". Now you clone XP from RED to BLUE and the registry goes
with it. But that registry remembers the partition signature of BLUE
belongs to G:, so when you try to boot from BLUE it assigns G: to its
own partition and then looks in vain for C:. The solution is to force
XP to forget the signatures so it doesn't automatically assign itself
G:.

There are several ways to do that, but perhaps the easiest is to boot
from a Win98 boot floppy and issue the command "fdisk /mbr", then remove
the floppy and reboot XP. Note the similar command "fixmbr" from the XP
recovery console isn't sufficient. The XP version leaves the DiskID
(stored in the MBR) intact, but the 98 version inadvertantly overwrites
it, causing XP to regenerate it and new partition signatures the next
time it boots. If you don't have a Win98 boot floppy, you can download
one from www.bootdisk.com.

 

[Guest]

Very interesting. Thank you. I am very familiar with MBRs, having written
code for them that replaces the standard code for security and disk
enhancement products. (That was several years ago.)

I guessed it was something like that, but I did not know where the info
was. I thought they might use one of the other sectors on cyl 0, side 0
(though that would be dangerous since other products do that too.)

Where in the MBR is the signature stored?

Thanks again.

 

[Guest]

Thank you both for your reply. That worked great.

 

[I'm Dan]

Very interesting. Thank you. I am very familiar with MBRs, having
written code for them that replaces the standard code for security
and disk enhancement products. (That was several years ago.)

I guessed it was something like that, but I did not know where the info
was. I thought they might use one of the other sectors on cyl 0, side 0
(though that would be dangerous since other products do that too.)

Where in the MBR is the signature stored?

The partition signature recorded in the XP registry is a combination of
the DiskID and the starting sector location of the subject partition.
You'll find details on my webpage at www.goodells.net/multiboot (check
the Notes page).

(BTW, I learned about the "fdisk /mbr" trick awhile ago from Michal
Kawecki, another respondent in this thread -- thanks, Michal!)

 

[Michal Kawecki]

The partition signature recorded in the XP registry is a combination
of the DiskID and the starting sector location of the subject
partition. You'll find details on my webpage at
www.goodells.net/multiboot (check the Notes page).

(BTW, I learned about the "fdisk /mbr" trick awhile ago from Michal
Kawecki, another respondent in this thread -- thanks, Michal!)

Nothing. Dan, I learn more and more from your site, too. I didn't know
for ex. how to break a 8GB limitation in Win9x or how to fix a Win9x
bootsector on logical partitions... thank you too for a good job.

 

[Alex Nichol]

Very interesting. Thank you. I am very familiar with MBRs, having written
code for them that replaces the standard code for security and disk
enhancement products. (That was several years ago.)

I guessed it was something like that, but I did not know where the info
was. I thought they might use one of the other sectors on cyl 0, side 0
(though that would be dangerous since other products do that too.)

Where in the MBR is the signature stored?

It isn't in the MBR - that just has the standard partition table entry
describing the partition to be booted.

There are two places - one is in C:\boot.ini, where the lines
multi(0)disk(0)rdisk(0)partition(n)\WINDOWS. . .

have the n (1 to 4) indicating the entry in the partition table; and
the other is much more detailed, in the registry at
HKEY_LOCAL_MACHINE\System\MountedDevices.
where it pays to remove the content of the right page and reboot to let
the next boot sort out the enumeration of devices again through PnP and
start over. I would BTW have any Zip drive disconnected at the time -
they can throw the lettering seriously out

 

[Michal Kawecki]

It isn't in the MBR - that just has the standard partition table entry
describing the partition to be booted.

Hmmm.... and what do you think about this text?

"Master Boot Record

The MBR, the most important data structure on the disk, is created when
the disk is partitioned. The MBR contains a small amount of executable
code called the master boot code, the disk signature, and the partition
table for the disk. At the end of the MBR is a 2-byte structure called a
signature word or end of sector marker, which is always set to 0x55AA. A
signature word also marks the end of an extended boot record (EBR) and
the boot sector.

The disk signature, a unique number at offset 0x01B8, identifies the
disk to the operating system. Windows 2000 uses the disk signature as an
index to store and retrieve information about the disk in the registry
subkey:

HKEY_LOCAL_MACHINE \SYSTEM \MountedDevices"

Source:
http://www.microsoft.com/technet/tr...ows2000serv/reskit/serverop/part1/sopch01.asp