Following the failure of my laptop disk last week after Vairam from Mediacom in Singapore left, I was glad I still had a CloneZilla image of my disk from last summer when I upgraded my 60GB disk to a Hitachi 200GB disk.
However this lead to some interesting events which took some time to understand and resolve.
Firstly, when I used CloneZilla to copy the disk image from last summer onto my new Western Digital Scorpio Black 320GB disk (MUCH faster than the dead Hitachi 200GB 7200rpm disk - even BEFORE it died), it also cloned the Windows XP MBR. This MBR also contains information on the disk - in particular, the size. Yes you can guess what happened - following a reboot, the 320GB disk suddenly reconfigured itself to a 54GB disk (the size of the original disk the image was cloned from using CloneZilla). Even the computer's BIOS reported the disk as only 54GB...
There was nothing I could do to convince anything, even a linux computer, that the disk was anything other than a 54GB disk.
Fortunately I found a utility called HDAT2, which allows you to set the disk's "SET MAX". In this case, restore the disk from 54GB back to 320GB.
However if I wanted to restore the CloneZilla image again, it would end up in the same situation.
So this time, I decided to only clone the specific partition. However this required me to manually configure the partition. Which led to another issue - I allocated the entire disk to the partition...and did not leave any space for the MBR or bootstrap. So no boot...
After correctly partitioning, and recloning, the disk still would not boot - it needed to correct MBR. "No problem" - boot from the Windows XP installation CD, run the Recovery Console, and run "fixboot" and "fixmbr". Problem - it wanted the administrator password. However, the password was not set. So I set it. Still no joy...
Fortunately, I found this registry hack to bypass the recovery console password - set "SecurityLevel " in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Setup\RecoveryConsole" to "1". Once set, no password (yes, a "security issue"...but do I care?...)
So now, repeat the whole procedure, call "fixboot", "fixmbr"...and finally, a working image from last summer WITH access to the full 320GB disk...
So...
Only took me three days to work this all out...