Cloned drive refuses to boot.

[Brian Smither]

Starting with a laptop drive (12G) running WinXP-NTFS on a Toshiba Tecra
8100, I installed it in another laptop (Chicony MP-978) along with another
laptop drive (10G). I then booted the Chicony with a DriveWorks 6 bootable
floppy (from V-Com).

I told DW6 to clone the 12G-NTFS to the 10G. It said it could, but that
during the process, the 3.5G unused space in the partition would get
truncated to 1.5G unused space. Three hours later, it was done.

I put the 10G in the Tecra and got a "Error Reading drive". I put the 10G
back in the Chicony and the drive would boot up to but not past the white
text-based boot phase. The computer would lock up at that point.

Am I mistaken - doesn't "clone" imply that the 10G drive should behave
exactly like the 12G drive?

(After spending a considerable amount of time getting to a point where I
would get *any* Recovery Console up and running,) I ran the FIXMBR and
FIXBOOT commands. No change. I verified that the BOOT.INI was proper.

I put the 10G in the secondary IDE slot of the Chicony and booted to
Windows 2000 Pro. I could see all files and folders. A scan of \Windows and
\System32 seemed to show everything was where it should be.

So what the hell is left to do?

Interesting but probably not pertinent to the solution:
My first attempt at getting to a Recovery Console revealed that my bootable
XP install CD does not list "R"-Recovery Console. There is no "Welcome to
Setup". There is "Windows XP Professional Setup". Apparently, from some
obscure comments I found on the Web, OEM bootable XP install CDs do not
include the ability to start the Recovery Console. You can install it as a
boot option (listed in the menu of OS's to boot). I created the six-pack of
floppy disks to get to the RC.

I created a single floppy with NTLDR, BOOT,INI, and NTDETECT on it after
formatting it in Windows XP. The BOOT.INI pointed to the correct partition.
But immediately, I got a "HAL.DLL is damaged or missing". Not. It's a clone
fer cryin' out loud.

 

[Attack of the Clones]

You cloned a 12 gig drive to a 10 gig drive and you
cannot see the problem? Use your imagination.

 

[Guest]

Whats the issue with that ?? It all depends on the data,
not the size of the anymore. Most NEW programs get around
that.

 

[Crusty \(-: Old B@stard :-\)]

You can't clone a larger drive to a smaller drive. You will have problems
every time. You even got an error message that said as much!

Now you must perform a clean install. I hope you have backed up your
important data!

 

[I'm Dan]

Starting with a laptop drive (12G) running WinXP-NTFS on a
Toshiba Tecra 8100, I installed it in another laptop (Chicony
MP-978) along with another laptop drive (10G). I then booted
the Chicony with a DriveWorks 6 bootable floppy (from V-Com).

I told DW6 to clone the 12G-NTFS to the 10G. It said it could,
but that during the process, the 3.5G unused space in the partition
would get truncated to 1.5G unused space. Three hours later,
it was done.

I put the 10G in the Tecra and got a "Error Reading drive". I put
the 10G back in the Chicony and the drive would boot up to but
not past the white text-based boot phase. The computer would
lock up at that point.

Am I mistaken - doesn't "clone" imply that the 10G drive should
behave exactly like the 12G drive?

I'm not surprised it wouldn't boot in the Chicony -- you can't expect XP
to boot in different hardware than it was originally configured in. The
HDD size difference normally shouldn't be a problem -- good cloning
tools can correctly alter the boot sector and file system structures to
handle that (I'm not familiar with DW6, so don't know how good it is).
Common cloning issues like boot.ini and partition signature problems
shouldn't give you that error msg, so with that particular error msg I
would investigate:

(1) possible hardware failure -- seems unlikely, since it seems to read
fine in the Chicony, but perhaps the HDD manufacturer has a drive
fitness tester you can download and run to check the integrity of the
HDD.

(2) possible corrupted boot sector and/or FAT/MFT -- possible, since DW6
must alter those to copy the original to a smaller target, and maybe it
didn't do it right. You could try redoing in two steps (first resizing
the original from 12G to 10G and then recloning), but I'm not sure I'd
be comfortable risking my original before I knew I could get a copy
running properly. Ghost, DriveImage, PartitionMagic, and BootItNG can
successfully handle resizes, so perhaps try one of those (BootItNG can
be downloaded for a free, fully functioning, 30-day trial).

 

[Brian Smither]

Dan, thqanks for the intelligent comments.

Replies follow your comments:

I'm not surprised it wouldn't boot in the Chicony -- you can't expect XP
to boot in different hardware than it was originally configured in.

Actually, if XP is anything like Win2K, I would expect to have at least a
blue-screen. But I get behaviors that are other than "Inaccesible boot
device", or "<file> not found", or any of several other known behaviors
that I have seen many times.

But I agree that transplanting WinXP in a foreign system invites serious
problems. Thing is, I get further in the Chicony than in the Tecra.

My main concern about the Tecra is if Toshiba may require a special format
that deposits something beyond the end of the partition, not visible to the
cloning program. But that's a stretch.

...so with that particular error msg I
would investigate:

(1) possible hardware failure -- seems unlikely, since it seems to read
fine in the Chicony, but perhaps the HDD manufacturer has a drive
fitness tester you can download and run to check the integrity of the
HDD.

Even if the HDD is currently not *bootable*, it is still read/writable.
Therefore, I conclude that the partition's boot record (signature? as you
call it) and the partition table is intact. DriveWorks 6 performed a 30-
minute surface scan of the 10G drive before moving data to it. But this is
a good thought.

(2) possible corrupted boot sector and/or FAT/MFT -- possible, since DW6
must alter those to copy the original to a smaller target, and maybe it
didn't do it right.

And so I was lead to believe that the Recovery Console FIXMBR would have
taken care of that. As for the FAT tables, does NTFS use FAT tables?

There was a CHECKDISK (however it is spelled) performed with a report that
nothing was amiss.

Ghost, DriveImage, PartitionMagic, and BootItNG can
successfully handle resizes, so perhaps try one of those (BootItNG can
be downloaded for a free, fully functioning, 30-day trial).

I also ran DI2002 and PQMagic6 to investigate the drive and the partition.
Neither complained of any abnormalities. Both said the one and only
partition was Primary and Active.

Again, thanks for the comments.

 

[Crusty \(-: Old B@stard :-\)]

Brian,

Partition Magic 6 IS NOT compatible with Windows XP. The NTFS file system
has enough changes to warrant a newer version. Partition Magic 7.01 (not
7.0) and 8.0 are compatible!

 

[Alex Nichol]

Starting with a laptop drive (12G) running WinXP-NTFS on a Toshiba Tecra
8100, I installed it in another laptop (Chicony MP-978) along with another
laptop drive (10G). I then booted the Chicony with a DriveWorks 6 bootable
floppy (from V-Com).

I told DW6 to clone the 12G-NTFS to the 10G. It said it could, but that
during the process, the 3.5G unused space in the partition would get
truncated to 1.5G unused space. Three hours later, it was done.

I put the 10G in the Tecra and got a "Error Reading drive". I put the 10G
back in the Chicony and the drive would boot up to but not past the white
text-based boot phase. The computer would lock up at that point.

Am I mistaken - doesn't "clone" imply that the 10G drive should behave
exactly like the 12G drive?

What is being cloned is the partition (and *strictly speaking a change
in size ceases to be a clone). But it does not write the Master boot
record code (MBR) outside the partition, that BIOS uses to find the
partition to be booted.

You can do that with either a Win98 startup floppy and the command
FDISK /MBR

or from a retail XP CD, - Set the BIOS to boot CD before Hard Disk.
Boot the XP CD and, instead of Setup, take the immediate R for Repair.
Assume any password requested is blank, and TAB over. Give
FixMbr

Also the boot of XP requires that the partition shall be in the same
place in the partition table of the drive - but in a simple single
partition on each that will not be changed. If that goes wrong you get
a 'hal.dll not found'

 

[I'm Dan]

Even if the HDD is currently not *bootable*, it is still
read/writable. Therefore, I conclude that the partition's boot
record (signature? as you call it) and the partition table is
intact. DriveWorks 6 performed a 30-minute surface scan
of the 10G drive before moving data to it. But this is
a good thought.



And so I was lead to believe that the Recovery Console
FIXMBR would have taken care of that. As for the FAT
tables, does NTFS use FAT tables?

There was a CHECKDISK (however it is spelled)
performed with a report that nothing was amiss.


I also ran DI2002 and PQMagic6 to investigate the drive
and the partition. Neither complained of any abnormalities.
Both said the one and only partition was Primary and Active.

Re: possible hardware failure, I'm thinking of a bad/unreadable sector
on the disk. DI, PM, and a standard CHKDSK won't necessarily reveal
that -- the rest of the disk can work fine, and the directory structures
can be intact, but if one of the files needed at startup covers a bad
sector, it won't read when Windows needs it. Nevertheless, we wouldn't
expect a new HDD to come a bad sector, and a positive 30-min surface
scan would seem to make this an even less likely possibility.

Re: possible corrupted boot sector and/or FAT/MFT -- no, NTFS has a MFT
in place of FAT (I didn't know whether you were using NTFS). The
various parts of the disk involved in the boot process will start with
the MBR, partition table, partition boot sector, FAT or MFT, and boot
files. The FIXMBR command only addresses the MBR, not the other parts.
CHKDSK should check the integrity of the PBS and FAT/MFT. PM6 won't
handle XP/NTFS. DI2002 will check the partition table, but probably not
the PBS and certainly not the FAT/MFT until you actually start creating
a partition image.

With the combination of checks you've done, I don't see evidence
implicating DW6 of any wrongdoing. Nonetheless, I'd probably try
recreating the copy with something else. BootItNG (aka, BING) can be
downloaded for a free trial, and your new partition doesn't presently
work, so it won't cost you anything to try it. Download BING
(www.bootitng.com), make the floppy disk, boot from the floppy, press
Cancel (since you don't want to install the BING boot manager), and go
to Partition Work.