GPT partition resizing and boot issues

Question

I am helping a friend migrate his OS from a 500GB mechanical drive to a new 250GB SSD and have run into problems. Where to begin...

His current OS is Windows 10, formatted with GPT and boasting 5 partitions, 3 are system-related and the other two are for Windows (3rd partition) and Program Files (5th partition)

After having moved some data around, the total combined used space of all partitions is around 180GB.

I am using Minitool Partition Wizard's "Migrate OS to SSD" wizard to attempt the migration, this had worked reliably for me in the past many times with MBR-based disks.

When I attempt the migration, after selecting the destination disk (the SSD), I am asked to confirm the partition sizes based on a draft schematic. In the schematic, the OS partition has been shrunk down to it's minimum size, it is 99% full. The 4th partition takes up the rest of the disk, and the programs partition is nowhere to be seen. This is actually not a problem, the end goal is not to store the programs partition on the SSD, but it does seem a little strange that it didn't suggest the Programs partition could be shrunk, and it does indicate the partition positions will be slightly different after migration.

Sure enough, once the migration is complete and the BIOS changes made to address the SSD, the SSD is not bootable. To be clear, the partition migration was successful, all the partitions are present and valid, the drive just isn't bootable. The screen shows an error which is basically telling me that a boot device could not be found. I hate it when that happens...

From a boot sector perspective, I can't understand how the OS partition cant be found, the partitions before it are moved by a couple of MBs but surely Partition Wizard will update the boot sector after making those changes, right?

Googling the problem was an absolute joke, all the search results were SEO-inflated posts from software vendors trying to market their various warez...

Could someone please help me understand why the software-managed migration of GPT partitions is destroying the "bootability"? I can post images of the partition arrangements if required, as well as the exact wording of the error.

Maybe there's a way that I could merge the OS and Program partitions, but they are separated by a recovery partition, and all these boot issues after resizing GPT partitions has got me jittery!

Answer 1

If SSD does not have EFI System, MS Reserved and Data partitions already:

Create 3 partitions on SSD manually (use diskpart.exe or another disk tool):

EFI System - 100 to 500 MB

MS Reserved - exactly 128 MB

Data(basic partition) - rest of disk

Then copy only Windows partition from hard disk to Data partition on SSD using any tool that can backup restore partitions (can recommend Macrium Reflect as I have used it).

Reflect can copy also ESP and MSR so you don't need creating partitions manually.

Then fix booting of SSD using:

bcdboot c:\windows /s S:

where c: is Data partition on SSD and S: is EFI System on SSD. You can map partitions using diskpart.exe or mountvol.exe.

Use only EFI booting for every device! (disable CSM)

Note:

Boot sectors are not used for booting on GPT disks. EFI System partition holds boot related files like boot manager and BCD.

Answer 2

FYI gparted is just the best partitioning software out there. If you have a spare USB stick, install yumi http://www.pendrivelinux.com/yumi-multiboot-usb-creator/, then install gparted through yumi. Boot the stick and choose gparted. Your best friend. Whether it's an HD or SSD is irrelevant from a boot perspective - but if the bios settings are wrong, EFI boot won't work. good luck. You also need to set the boot flag on the EFI partition (can be done through gparted).

Answer 3

His current OS is Windows 10, formatted with GPT

The use of GPT on a Windows boot disk means that the system must be booting in EFI/UEFI mode. This is important....

once the migration is complete and the BIOS changes made to address the SSD, the SSD is not bootable. ... I can't understand how the OS partition cant be found, the partitions before it are moved by a couple of MBs but surely Partition Wizard will update the boot sector after making those changes, right?

There is no such thing as a "boot sector" in EFI-mode booting. EFI boot loaders are stored as ordinary files on the EFI System Partition (ESP), which is a FAT partition with a particular type code. This is much saner than using code splatted into partitions (and even between or before partitions, depending on the boot loader), but it takes some learning -- and unlearning -- to master.

One of the keys to EFI-mode booting is that a reference to the boot loader to be used is stored in NVRAM. This is an extension of the practice on BIOS-based computers of storing a boot order of disks -- only under EFI, the boot order is composed primarily of files, not of disks. (There can also be network boot options and boots of fallback files on disks, but that's going a bit beyond your situation.) Part of the boot loader specification stored in NVRAM is a GUID value associated with the partition on which the boot loader resides. When you cloned the disk, chances are the new disk got a new GUID, and its partitions all got new GUIDs. Thus, your NVRAM entries continue to point to the boot loader on the old disk, which you've now (presumably) disconnected.

This problem can often be worked around by using a "fallback" boot loader, which uses the name EFI\BOOT\bootx64.efi on the ESP. Microsoft normally stores a copy of its boot loader there. My guess is that either it wasn't copied or your firmware is configured in such a way that it's never being tried. If the latter, you may be able to work around the problem, at least on a one-time basis, by using your firmware's built-in boot manager, which may give an option to boot from the fallback filename (probably identified by the disk's make and model number). A few (too few) EFIs also let you launch an arbitrary boot loader by locating it with a file manager. If you're lucky enough to have this option, you could launch the normal Microsoft boot loader (EFI\Microsoft\Boot\bootmgfw.efi) using this feature. Such one-off efforts are unlikely to be workable long-term solutions, though. For that, you'll probably have to use Windows recovery tools to re-install your EFI boot loader. I'm not an expert on this subject, but it seems to be covered in this question and answer, so you should probably read it.

There are some other possible causes of your problem, such as:

• Your cloning utility may have omitted the ESP entirely. In this case, you must first create a fresh ESP before you repair the boot loader problem.
• Some manufacturers provide their own manufacturer-specific ESP-like partitions that are critical to the boot process. Such a partition, like the ESP, might have been omitted in the cloning process.
• Your cloning utility may have created an MBR clone of the original GPT disk. In this case, the easiest solution may be to use my gdisk utility or some other tool with similar functionality to convert from MBR to GPT. You may also need to create a new ESP, and you'll probably have to re-install or repair your existing installation of your Windows boot loader.

There may be other possible causes, too, but with any luck you'll now be able to examine your disks and spot problems like an incorrect partition table type or misplaced boot loader files.