Clone dual-boot XP/Vista to new drive: "disk read error"

Hi.

I've been using True Image for years, but am new to TI 2009. I'm using True Image Home 2009.

I would like to clone from a single 250GB drive with 2 partitions to a single 1TB drive with the same 2 partitions. The partitions are C: (Win XP) and D: (Vista). Both OS's read the drives in that order. I'm using the Vista Boot Manager to select the OS. I do not want to increase the size of the XP partition.

Oddly, I performed this exact same procedure with TI10 to get to the 250GB drive in the first place, but somehow I'm unable to do it with 2009.

I ran TIH2009 a couple of days ago and the process completed without errors. Both drives are SATA. I left the old drive installed in its original "master" location, and cloned to the new drive as "slave" using the Vista interface (not a boot disk). I disconnected the old drive and placed the new drive as master. I then tried to boot to the new drive, but I got the error message: "disk read error, press ctl+alt+del to restart." That of course solves nothing.

I've been searching these forums for the last 2 days trying to figure out what I need to do, but I'm probably more confused now than when I started. Do I just need to run Vista's boot recovery tool (I haven't tried this because we moved recently and I'm fairly certain that my Vista DVD is in a storage locker...)? Or did I foul up the clone process, so I need to start over? I will note that I could not find an option in the clone disk wizard to copy the MBR to the new disk.

Any and all help immensely appreciated.

Thanks,
Rev

 

Rev:

First thing to check is your PC BIOS settings. On some PCs when you remove a disk and replace it with another, the boot device setting will change. Check the BIOS settings to see which disk it thinks it is booting from. Some BIOS menus have more than one place where the disk order is set -- one menu for the boot device type (Hard disk, CD, floppy, network, etc) and another menu for the order (Disk 1, Disk 2, etc).

 

Thanks, k0lo, but the problem turned out to be more interesting (and unexpected) than that. Recorded below for posterity and Googlers.

I double-checked the BIOS settings, and everything was as it should be. So I booted up with the Vista DVD to run the boot recovery program, but it informed me that there were no Windows installations on the drive. Odd. I proceed to manually run bcdedit, and learn that there is no boot store on the drive. Odd again.

I boot into Windows on the old drive and figure that something went haywire in the clone, but TI didn't tell me, so I'll try again. Load up the Vista disk manager, and what do I find? Not my 953GB (I hate NTFS) drive, but a 32MB drive that is all MBR. I tried to format and reinitialize the disk using the Vista manager and TI's add disk utility, but no matter what I do, I get 32MB.

A little googling revealed that this drive (Samsung 1TB) occasionally goes nutty and reports only the size of its CACHE as the drive size. A quick fix with the Samsung ESTool and it now reports as 953GB again.

I did the clone again, but this time I did it "as is" and used the Vista disk manager to extend the Vista partition over the unallocated 700ish GBs on the disk. I don't know if it was TI's expansion of the original partitions that caused the drive to freak out, but I figured it was less risky overall.

TI performed beautifully and my dual boot was perfectly preserved. But I'm still a little nervous about this drive. How long until it reverts to 32MB and my installation is tanked? It would be the equivalent of the drive spontaneously destroying all partitions. Not sure I can live with that risk, even with daily back-ups.

Anyway, like I said, thanks for your help.

 

That is a new one for me. I took a look at Samsung's ESTool and found the following under the "Set Max Address" function that allows you to choose the number of LBAs on the disk:

So to answer your question, it would seem that choosing "Non-Volatile" would write the size change permanently to the drive's firmware, therefore you would not need to worry about the drive size changing again.

 

Yeah, I set it to non-volatile, but I don't think it will matter. It seems the problem is my motherboard. http://forums.storagereview.net/index.php?showtopic=26874

Apparently older Gigabyte motherboards (like my GA-965P-S3) have trouble with the Host Protected Area on large drives (like my F1). Ordinarily these boards reserve 1MB of space of the primary master for a failsafe backup of the BIOS. The older BIOS (like mine) don't know how to do that with a large drive. This explains why the drive got blitzed as soon as I moved it from the slave to master positions. A poster on Storage Review confirmed that the BIOS will once again set an incorrect max LBA after a couple of reboots - don't know if that will blitz the partitions or not. I'm going to update the BIOS tonight, but there isn't a documented fix for this problem in any of the BIOS changelogs (and the newest BIOS for my board is from April 2008...). I may have to leave the old drive in as the primary master, but boot from the new drive. Not ideal, but functionally it shouldn't matter.

Ain't technology grand?

 

Host Protected Areas on hard disks are a bad idea. There are a lot of forum participants here who have been bitten by Dell's HPA on their older MediaDirect laptops. When they install a new, larger hard disk the result is a visible partition the size of their old disk and a larger HPA, and they are left wondering where the extra disk space went. IBM/Lenovo used to use an HPA to store their recovery partition but have since abandoned the practice. Gigabyte's scheme of storing a backup of the BIOS on a hard disk HPA sounds like another example of an idea that sounded good on paper but had unintended consequences in the real world.

Hope you can get a BIOS update to fix the problem.

 

Final update, mostly for posterity, in case this may be of interest to whatever artificial or extraterrestrial intelligence finds this complete record of human experience that we call the Internet.

I updated my board to the most recent BIOS, and that seems to have taken care of the problem. 14 reboot cycles and the drive still reports the proper LBA/size. For some reason it takes like an extra minute to boot to Windows now, though. Luckily I rarely restart and mostly use S3 suspend.