In getting several (5) systems up and running on Windows 8 and 8.1 recently, I’ve had the chance to learn a great deal more recently about the way that UEFI systems work and behave, particularly when it comes to moving SATA drives around, and when seeking to switch a system over from a conventional spinning hard disk to a faster purely digital SSD equivalent. This learning has been surprising, occasionally painful, and quite illuminating.
I got my first clue that something was up when I used Acronis True Image Home 2014′s “Clone Drive” utility to create a bit-for-bit copy of a WD Scorpio Blue 750 GB conventional disk onto a Samsung 840 EVO SSD this weekend. As I ran the program, it informed me that I would not be able to use the resulting drive image to boot a system. “Hmmmm,” I said to myself upon seeing this, “I wonder what’s up with this? I hope I can find a way to work around it.”
My search for enlightenment led me to the following pithy and dense paragraph of information on Paragon Software’s “Migrate OS to SSD 3.0” web page (I reproduce it verbatim here, because it makes numerous points I need to unpack and explain a little further, fractured English notwithstanding):
Introduced back in 2005 by Intel to lift restrictions of the old MBR (Master Boot Record) and PC BIOS (Basic Input/Output System), uEFI (Unified Extensible Firmware Interface) is now a recommended platform for new 64-bit Windows 8 computers. And the reason is easy to catch – besides other unique features impossible for the traditional tandem of BIOS+MBR, only a uEFI-based platform enables to accommodate Windows OS on a partition larger than 2.2TB. Despite all uEFI advantages however, it has one quite naughty issue: A pretty standard operation with a bootable device for instance involving its connection to another SATA port results in unbootable Windows. You’ll get the same result if trying to boot from a cloned system hard disk. All these problems originate from the way uEFI+GPT bundle is organized. Microsoft provides how-to guides to tackle this type of problems, but they demand a great deal of experience from the user, involving the use of the cmd, diskpart and bcdedit tools. [Emphasis mine; content Paragon Software's.]
Here’s what I’ve learned that this really means, thanks to some initially puzzling trial and error, and subsequent more deliberate experimentation
1. You can’t move the boot drive from one SATA connector to any other connector on the motherboard on a UEFI-based install. Once it’s plugged into a port, it has to stay there forever, workarounds and shenanigans nothwithstanding. I learned this the hard way when I took my wife’s new mini-ITX machine apart a couple of times to play with an mSATA drive in that machine. As I plugged the HD and DVD SATA connectors back into the motherboard, the only thing that produced a bootable configuration was when placing those two plugs into the very same receptacles they’d occupied when I performed the initial OS install.
2. You can’t boot from a cloned system disk (this applies equally to targeted hard disks or SSDs). Apparently, some kind of unique ID is created when the initial install occurs, with a pointer to a unique and specific drive/deviced ID. That information does not work if any hardware (such as the system/boot drive) or connections (home SATA port) change for any reason.
3. All these problems originate from the way the UEFI + GPT bundle is organized. I’m still in process of digesting and understanding this, to the point where I’m talking to a senior support specialist and a development engineer from Paragon tomorrow morning so they can explain this to me further. I though I understood the basics of the GUID partition table (GPT) an dhow partitions are handled in this kind of environment, but in looking over the kind of problems that people have reported in integrating MBR disks into a UEFI environment (superuser.com) or when upgrading to Windows 8 (EDNnetwork), I quickly realized the situation is more complicated than it used to be in the BIOS/MBR 32- or 64-bit era of computing, now largely supplanted by UEFI/GPT 64-bit computing. See the EDNnetwork article for some highly informative diagrams that explain where the problems come from, and why they can be vexing to fix. Paragon offers a “Boot Correction Wizard” to deal with these issues, which is why I’ll be talking to them further about this tomorrow.
All I can say is that certain issues in working with UEFI and GPT are now somewhat clearer to me, and I think I understand what went south on my various migration shenanigans this weekend. I’ll follow up later with more information, and no doubt clearer explanations, after I have a chance to review this with the folks from Paragon.