I wanted to see how much better my old P4 machine fairs running on an SSD so I took one from work and set out on a journey with a few surprises, as it turned out. It has to be said upfront that the BIOS seems to be picky about SSDs. I brought an OCZ Agility 3 120GB home, but the BIOS did not see the drive. It’s an ABIT IS7 board with the latest BIOS and Intel ICH5 south bridge with 2 SATA1 ports. Once booted into XP or Linux the drive showed up, so it was not the drive or the SATA1 controller. An ASUS P8P800SE board saw the drive in the BIOS as well, so it must be the BIOS. So I decided to bring a spare Kingston home, which is a V200 64GB drive. This one showed up in the BIOS, so I could boot from it and see how it worked. Both SSDs are SATA3.
I installed the SSD into the PC and grabbed my GParted USB stick. I have a Win98 FAT16 partition on the HDD as well, mainly for legacy reasons, and XP installed onto an extended partition, and yet another partition for data a some programs, so I had to copy both the Win98 and XP partitions at least. The HDD is an 80GB drive, and almost full so I had to opt for keeping the data partition on the HDD, but that was not to be a problem. First I copied the FAT16 and XP partitions to the SSD when I realized the SSD needs MBR boot code as well, so I copied the whole MBR sector from the HDD to SSD, but then GParted said the SSD has no partitions. GParted, or Linux, must have seen that the extended partition extends beyond the size of the disk and decided to show the drive not having anything. Anyhow, I created partitions, copied the Win98 and XP again and this time only copied the boot code part of the MRB from HDD to SSD. A side note that I told GParted to align the partitions to MB boundary, so it wanted to resize the FAT16 partition which is could not for some reason and said that it should be converted to FAT32 in which case old DOS would not see it. I did not want that, so I clicked Cancel. Not sure if this was the cause, but when I booted off the SSD I was told that NTLDR could not be found (in this partition scheme it lives on the FAT16 partition!). Great… Booted back into GParted, opened a terminal, and used dd to copy the first 20 or so GBs from the HDD to SSD (dd if=/dev/sda of=/dev/sdb bs=1G count=20). The first 20GB covers the Win98 and XP partitions and a bit from the data partition as well, just to be sure I copied everything. As noted above GParted does not see the partitions in this case, but fdisk does. So started fdisk, listed the current partitions, took note of the starting and ending sectors, deleted the XP, data and extended partitions and recreated the extended and XP partitions, where the extended partition was now reaching to the end of the SSD. Yes, you can safely delete and create partitions in fdisk, no data or boot sector will be overwritten (note that this is the Linux fdisk command, not a DOS/Windows one). I had to set fdisk to DOS compatibility mode otherwise partitions would not start where they started before the deletion (MB boundary alignment). Went back to GParted and was happy to see that the two partitions are visible on the SSD. I realigned (moved) and resized the XP partition so its clusters fall on 4k boundaries (search the Internet for partition alignment on SSDs to understand why I did this) and have some more space. Fiddled with the BIOS to boot from the SSD and probably this is where all went wrong somehow.
I’m not sure of the steps I took, but the system did not boot from the SSD, it actually BSODed with an error I’ve never seen before (something like Session Manager Instantiation error). This was I believe because the partitions on SSD were not assigned the same drive letters they were on the HDD and thus XP could not load bits. This I could fix, once I fixed my messed up HDD XP as well, read on. So I decided to search the internet, which meant booting back into the HDD XP, and this is when things went bad. Somehow the drive letters of the partitions got changed, probably when trying to boot from the SSD with the HDD still connected, and the symptom was and endless login-logout loop. Oh boy, I have no working PC. I reverted to my trusted Nokia E90 Communicator and started searching. What most people suggested was that the registry key that usually points to userinit.exe was modified by some virus to point to some file that does not exist any more, hence the session could not be created. Someone suggested that one can connect to the registry remotely, but my user had no password set, so that did not work. When I was searching for an offline registry editor (I could attached the disk to a Windows 7 notebook and edit registry) I found a very cool solution. Windows 7 recovery option allows to run a Command Prompt and has regedit.exe as well, all I needed was a 32bit Windows 7 installer, which I had at hand on a USB stick. Booted into Win7, started regedit, opened the relevant registry key only to see that it was in order, that was not the reason. But when I booted up Win7, for some reason it did a disk check of the drive letter of the data partition where it deleted the hiberfil.sys file entry. Hang on… that is not supposed to be there, and this gave me the light bulb moment. I opened regedit again, went into HKLM\SYSTEM\MountedDevices and deleted the \DosDevices\ entries and lo and behold, XP booted up fine. And this made me realize the SSD XP must have the same problem, so I edited the registry on that as well, shut down the PC, unplugged the HDD to avoid messing up things again (although I think deleting the MountedDevices entries would have prevented that anyway) and booted up into my SSD XP. Shut down again, reattached the HDD, and after one or two more reboots the HDD data partition was the correct drive letter for the SSD XP as well.