The Problem
The task is one which can be seemingly accomplished by a low-level administrator with a few simple tools; that is, upgrade the hard disk in a laptop computer, running only Windows XP, and keep its contents in-place.
There are additional constraints:
- You can only fit one hard disk in the laptop at a time
- There is NFS and SMBFS access to a disk array which can easily absorb a full disk image
- There is a USB 2.0 disk of sufficient size to absorb a full disk image
- There is not a USB/FireWire adapter for the 2.5" drive, because you forgot that the one you did buy was for a PATA interface, not the shiny new SATA interface
So, the standard approach: make an image of the hard drive onto one (or more for backup) of the larger disks; install the new drive, and image back. Simple, straightforward, and easy, especially with commercial products like Ghost and PartitionMagic available for the process, right?
Wrong.
The Windows Approach
My version of Ghost (admittedly from 2003) was unable to read my USB disk in the DOS mode which needs to be dropped into for the actual imaging operation; similarly, network access under DOS (always sketchy, back in the day) proved impossible due to the non-existence of appropriate Gigabit ethernet drivers for my onboard card (also not suprising).
At this point, a Windows guy with my limited subset of equipment would go and fork over some more money for a shiny new USB adapter that hopefully Ghost could recognize, allowing for direct disk-to-disk transfer overnight. I, however, needed to get this thing going today to keep doing plasma physics research!
So, with the traditional Windows tools exhausted, it's Linux to the rescue! The problem has now officially been promoted to a More Difficult, but Not Impossible task. After all, if Linux can't do it, it's not worth doing; and with more than five years' worth of Linux experience, I should be up to the task -- and with stereotypical Linux snobbery, do it faster and better than Windows could have. :)
The Linux Approach -- Take 1
My approach was the same: make an image of the source disk and restore onto the new one after a hard disk swap. My latest on-hand Fedora Core 5 Rescue CD didn't have the appropriate network drivers for my network card, either; fortunately, the Fedora Core 6 DVD did. By booting into rescue mode (boot: linux rescue) I was able to manually activate my network devices for my home network, create virtual mountpoints in the rescue-mode created ramdisk and attach to my NFS ~1 TB megastore.
My first Dell-specific surprise when using Linux (and fdisk) was that my disk had some hidden partitions on it!
$ cat fdisk.txt
Disk /dev/sda: 38.5 GB, 38502535680 bytes
255 heads, 63 sectors/track, 4681 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 5 40131 de Dell Utility
/dev/sda2 * 6 4074 32684242+ 7 HPFS/NTFS
/dev/sda3 4075 4680 4867695 db CP/M / CTOS / ...
Well, with those guys lying around, it appeared that it was a small diagnostic partition, coupled with a sizable (DVD-sized!) restore partition hanging around, too! No wonder my purportedly 40 GB drive was clocking in near 30 GB in Windows!
Since I figured it'd be good to keep them around to start, the imaging itself was a snap; using dd:
#dd if=/dev/sda of=/path/to/nfs/mount/raw_disk_image
After the image was written, I swapped disks and repeated the process:
#dd if=/path/to/nfs/mount/raw_disk_image of=/dev/sda
Again, after the imaging took, I rebooted; Windows booted normally. I was done -- or so I thought. (Did you see my mistake? Hint: the partition table was copied literally.) Since this was a bit-for-bit raw copy of the source, the new hard disk reported itself as an identically-sized drive. I figured that PartitionMagic could do the trick, as it was designed for just these wacky partitioning schemes.
Unfortunately, both PartitionMagic as well as Windows reported the maximum hard drive size as that of the source, and not of the actual capability of the drive. My next thought was to confirm that the laptop recognized the new drive in its entirety. Strangely enough, the BIOS reported the old disk size as well! This was starting to smell like a Master Boot Record (MBR) problem, since dd happily brought the old one over for the ride.
At this point, I had to do some digging; by visiting my hard disk manufacturer's website, I was able to obtain a bootable CD containing yet another spiffy DOS-based utility to probe the hard drive. Among the tweaks possible was to re-define the capacity of the drive! It took -- at least the BIOS said so -- but Windows and PartitionMagic disagreed; afterward, they had somehow reset the original, incorrect data too. This led to a prolonged sequence of reboots while properly resetting the MBR and trying other tricks.
The problem seemed to stem from inappropriate drive geometry (cylinder, head, sectors) information stored in the MBR. fdisk should be able to take care of that, but for whatever reason, was not being saved properly. D'oh! (Of course, this took several reboot/re-tweak HD size/Windows boot cycles.)
I then turned to a Linux LiveCD to help me out -- the latest version of Knoppix. (After all, a Fedora Rescue CD is rather bare-bones when it comes to the increasingly difficult task I'd set it to do.) Specifically, I was after easy access to try and tweak the partition table using fdisk and gparted, the latter only which runs in an X environment. (gparted is a PartitionMagic clone.) It appeared to work, since I could re-define the partitions, resize the NTFS (!) and go on my merry way.
Until I rebooted, and got a wonderful Windows XP BSOD and a stop code (0x0000007b) which corresponded to a bad boot drive. D'oh!
A bit of googling turned up a problem with gparted, the NTFS toolkit package, and the 2.6.19 kernel used on my Knoppix CD; supposedly the latest, greatest gparted LiveCD using the 2.6.20 kernel fixes the problem.
So, after burning yet another LiveCD, I was able to shrink and un-move the partitions back to under the original 40 GB boundary. Windows booted -- hooray! However, after 6 hours worth of grow/resize/move tricks with gparted (PartitionMagic and Windows continued to refuse to recognize the true drive size) I had to give up.
The Linux Approach -- Take 2 [Works!]
Since dd imaging worked so well, and the MBR squarely identified as the offending culprit, I took the (considerable) time to do my imaging better -- i.e. partition-by-partition, again to the NFS megastore:
#dd if=/dev/sda1 of=./sda1
#dd if=/dev/sda2 of=./sda2
#dd if=/dev/sda3 of=./sda3
Then, I manually zeroed the partition table with fdisk and manually created the necessary partitions of exactly the same size and filesystem type as from the original, except without the 4.6 GB Dell restore partition. (After all, I now had its contents safely pulled out into backup image sda3. Re-imaging:
#dd if=sda1 of=/dev/sda1
#dd if=sda2 of=/dev/sda2
And with a reboot: a nice blinky cursor. My job was not yet finished!
The trick: since the MBR was created from scratch, even though the NTFS partition was toggled to be bootable, there wasn't actually a boot loader to do it!
The solution for that problem is to use the Windows XP Recovery Console, off a trusty Windows XP installation disc (and even more reboots!). Not a big deal; one just needs to run fixmbr under it. That is, until I discovered that Dell had set an Administrator password on my machine that I did not know!
So, I had to hack into my own machine, crack the Administrator password, and then reset it to a new one using yet another Linux LiveCD, this one being custom-tailored to Windows password cracking/resetting.
Following the hack, the Recovery Console fixmbr fix worked like magic; the system booted and PartitionMagic properly recognized the additional hard disk space. One last round of NTFS resizing to claim the 120-ish GB free on the replacement drive and I was successful!
Final Thoughts
If you find yoruself in my position, the right thing to do is to manually re-create the partition table -- don't bring it over via dd! You'll be happier after you do it. Also, Dell steals your hard disk space to leave DVD restoration images -- and leaves secret recovery passwords on the working Windows partition so you can't easily fix things when they go wrong!
No comments:
Post a Comment