Moving GPT partitions to another SSD

I started off with one 240GB SSD having both my Windows and Linux partitions, and wanted to upgrade my PC to have 2 SSDs, one with Windows and one with Linux. I run Windows Server 2008r2, which is basically Windows 7 once you’ve set it up appropriately, and Arch Linux. Both are installed as UEFI systems, and thus my SSD has a GPT partition table. I decided I wanted to move the Windows partition, since I’ve found my Windows partitions to run out of space first and the new SSD is bigger than the old one.

Usually I’d use Windows Server Backup tool for moving Windows to a new disk (it actually works well), but I have a second spinning disk with some less important programs and the pagefiles, so Windows Server Backup wouldn’t let me do a bare metal backup without backing that up as well. I think it therefore also wouldn’t let me restore that backup without supplying two target disks for blowing away and reformatting, which seemed like too much hassle. Because of this, I thought I should clone my old SSD to the new SSD, delete the Linux partitions (/boot and /) from the new disk and the delete the Windows partitions (system reserved & C:) from the old one, leaving me in my desired end state.

I used CloneZilla to clone the disk, and that actually works quite nicely. I missed the memo that said I should use the alternative stable release for GPT disks, so what follows may be a result from that. After cloning the disk I tried booting the partitions individually, with only 1 disk plugged in at a time, and that worked fine. However, when both disks were plugged in, only one of them would boot, trying to boot from the second disk resulted in me getting thrown back to the UEFI boot menu.

Diagnosing the problem from Windows’ disk manager, I noticed that it refused to use the disk because of a disk signature collision, as explained in this article. This was because the GPT disk and partition GUIDs had been cloned. I did not however trust Windows to fix the GUIDs in a way that Linux would remain bootable, since I figured I should edit /etc/fstab and maybe bootloader entries at the same time. It turns out that you can re-generate the GUIDs using gdisk:

I just want to point out that you’ve now got two physical disks with duplicated GUIDs. […] A globally unique identifier (GUID) should be just that — unique. If two disks or two partitions share the same GUID value, then problems can ensue. (GUIDs used as partition type codes are an exception to this rule, though.) AFAIK, Linux doesn’t currently care about this, but it might in the future, and I can make no promises about how Windows or an EFI implementation might react to non-unique GUIDs.

If you want to use both of these disks in the same computer, you can use the ‘g’ and ‘c’ options on gdisk’s experts’ menu to change one disk’s GUID and the partition GUIDs on one disk, respectively. (You’d need to use ‘c’ once for each partition.) Alternatively, you can use sgdisk’s -G/–randomize-guids option to do it all at once.

source: srs5694′ forum post on the Arch Linux forums, emphasis mine.

In addition to that, I also went and updated my /etc/fstab entries to use PARTUUIDs (i.e. GPT GUIDs) rather than UUIDs to reference the partitions; I did this because I now had two EFI partitions as well, and even after randomising the GUIDs those still had the same Linux UUIDs, and I didn’t dare to touch those.

Next, I cleaned up the EFI partitions such that the Linux and Windows bootloaders were on the SSDs they belonged on. Then I discovered that the gummiboot (these days called systemd-boot) bootloader would now no longer discover the Windows bootloader, so I had to switch to rEFInd, which allows me to boot into Windows despite its EFI files being on a different disk.

After all this, I went ahead and expanded the partitions, and all was well. While I spent a significant amount of time investigating the Windows mechanisms for fixing their bootloader, I’m very glad I didn’t have to do any of that.

So, to summarise, here’s a rough recipe for “splitting” one dual-boot GPT-formatted SSD into two:

1. Make backups!!
2. Use Clonezilla (alternate version probably, read the memo) to 1:1 clone the old SSD to the new one
3. Ensure both disks boot separately
4. Delete unwanted partitions from each of the disks, ensuring you’re left with the partitions you want on the disks you want
5. re-generate GUIDs for Linux using gdisk, update /etc/fstab and bootloader as appropriate
6. Ensure you use a bootloader like rEFInd that supports booting OSes from another disk’s EFI partition.
7. Re-size and/or move partitions around to fill available space