User:Mjb/Boot sector recovery

I wanted to replace my 500 MB Windows 7 boot drive with a 4 TB drive.

The larger one I temporarily mounted in an old USB enclosure. The drive size was reported in Windows Disk Management console as having less than half its actual 4 TB capacity. In this case, the reason is because the enclosure only supports 32-bit addressing. (In other situations it can be for other reasons, like using MBR instead of GPT, or the hardware/OS not supporting UEFI, or disk controller drivers like Intel Rapid Storage Technology being out of date, but in this case I know it's just because of the outdated enclosure which really was made for a ~1 TB or smaller drive.)

Anyway, the reported size is still bigger than my boot drive, so I hoped to copy the contents of the boot drive over to this new drive, swap the drives, and after it successfully boots, just format and use the extra space. Because the boot drive is always in use when Windows is running, this copying needs to be done from outside of Windows, after booting to something other than the boot drive. So this means booting to a CD-ROM, DVD-ROM or USB stick which runs the software for copying.

Apparently (I've read), disk "cloning" software is more about copying the contents of a volume, i.e. a formatted partition on a drive. Disk "imaging" software is about copying the raw contents of an entire drive. "Imaging" is what I need, because I my boot drive has multiple volumes: the mysterious SYSTEM_DRV required by Windows (I have since learned this is for BIOS boot code, not UEFI!), plus the usual C: with all the OS files on it, and also I:, which is a volume I made from free space recovered after shrinking C:.

My boot drive is a "dynamic" disk, meaning it is specially formatted in Windows to have spanning and mirroring capability and 64-bit addressing (so, support for > 2 TB). It also means that under the hood it has a different layout, partition/volume-wise, than a "basic" disk, and relies on newer versions of Windows to work.

I've read that the common, free drive-imaging apps do not support dynamic disks. So I have to try some other method.

I've seen a site that tells how to use Windows Backup & Restore to do this kind of thing by making a "system image" (confusing terminology!) on a USB drive, plus a system repair disc on CD-ROM; swapping in your new, empty drive; booting to the system repair disc; and finally restoring the system image from the USB drive to the new drive. Well, this is not really feasible unless you have all of your "system" on one physical drive, and you have the whole thing being backed up in your "system image". If you are only backing up portions, or if you have multiple drives in use for different parts of your "system", then this method surely will not work for you. And by you I mean me.

I ran across one solution that looked really simple (for me): basically you just boot to Linux on a USB stick (I happened to have an Ubuntu Live USB stick that I made in 2012!) and run 'dd', the program which copies or writes bytes directly to any device the OS knows about.

My Ubuntu distro uses the GNOME desktop and probably is not the current state of affairs, but for what it's worth, all I had to do was open the Disk Utility and see what the device files were for the two drives in question. In my case, the boot drive was /dev/sda and the USB drive was /dev/sdg. After reading http://serverfault.com/questions/4906/using-dd-for-disk-cloning I decided to use this command line in Terminal:

sudo dd if=/dev/sda of=/dev/sdg bs=4096 conv=sync,noerror

From another terminal window, I checked on the status occasionally by

sudo kill -SIGUSR1 6351

where 6351 was the process ID of the 'dd'. Average throughput started around 39 MB/s and as expected, slowly dropped by a few MB/s. So, roughly 300 Mbps, which is normal, maybe even a little on the speedy side for USB 2.0 drives. At this rate, the 500 GB image took about 4 hours.

I then shut down the computer, took out the USB key, swapped the old boot drive for the new, and turned the computer back on.

It actually worked, but when I went into Windows' Disk Management console, I saw that only the first 500 GB was actually partitioned. That makes sense, since that's how the old drive was. I thought, well, I'll just extend the last partition into the unused space. However, Windows could only see 1677 GB of the new drive's ~4000 GB, a 32-bit limitation. Several factors were at play:

• Lenovo did not install Windows with UEFI boot code rather than BIOS boot code. Installing the UEFI boot code is normally only something you do at Windows install time when formatting the disk. Reinstalling Windows is not an option on these PCs which come with an already-installed Windows image. There are no actual Windows installation discs.
• The drive was formatted with an MBR (Master Boot Record) boot sector, whereas it would need to be formatted with a GPT (GUID Partition Table).
• MBR cannot be converted to GPT without data loss using standard Windows tools; it's only an option on unformatted drives. Third-party software exists for this but is either not free (e.g. the sketchy EaseUS a.k.a. MiniTool app, which apparently needs a pricey add-on to have this capability), or only does part of what you need (e.g. gdisk, which can't create the necessary EFI System Partition or put the Windows EFI boot loader into it).

This was in addition to the factors which were not an issue for me:

• The version of Windows must be 64-bit.
• The BIOS must have UEFI boot support and that support must be enabled (or not disabled, whatever your BIOS offers).

In my haste, I didn't learn about the UEFI stuff, and went ahead and tried to convert the MBR to GPT by booting to Linux and running gdisk. I compounded my problems by being careless about having both the old and new Windows boot drives attached at the same time. They appear identical to the boot loaders, and you can't tell which one you are booting from or modifying. There is also some boot code replication (to different drives) going on, which I don't fully understand. Regardless, somehow I managed to corrupt the boot sectors on both the old and new drives! In my defense, people who understand these issues do not do a very good job of explaining it online.

I did not keep careful notes, but here are some random things I recall:

• At one point, in the Windows Disk Management console, I was seeing bogus error messages about the disk not having enough room to change anything.
• I found a site that recommended booting into the Windows 7 recovery environment, which (because of the corrupt boot sector) means booting from a System Repair CD. This did not work for me because my old repair CD was created for a different version of Windows (although I did create it from this Win7 installation). I think this may have to do with the change of disk type from Basic to Dynamic, but not sure. So I had to boot from a Windows 8(!) repair disk I found online. This got me to a prompt where I could see my C: volume.
• I followed instructions found in a Microsoft Technet community post to run bootrec.exe /FixMbr, bootrec.exe /FixBoot ("The volume does not contain a recognized file system"), and bootrec.exe /RebuildBcd ("Total identified Windows installations: 0"). bcdedit /export C:\BCD_Backup "The store export operation has failed. The system cannot find the file specified." ... somehow I got past this and ran the commands at the bottom of https://support.microsoft.com/en-us/kb/927392 but then got "Missing operating system" at boot time.
• Tools which saved my ass:
  • Disk Utility on the Unbuntu Live USB key
  • gdisk on the SystemRescueCd
  • TestDisk on the SystemRescueCd – this was what finally worked

I managed to get my 500 GB drive back to the MBR, Basic disk with the help of gdisk. I don't remember what I did, though.

In the future, if I try this again, this might be the way to go: http://social.technet.microsoft.com/wiki/contents/articles/14286.converting-windows-bios-installation-to-uefi.aspx ... still, it seems this is not a foolproof method. Several interesting comments there.