Migrate Linux/win10 dual boot from MBR nvme drive to a new GPT nvme drive

bluemoo · 09-25-2018, 01:24 AM

Hello. I am attempting to migrate my current dual boot (opensuse/win10) setup from one nvme(nvme1) drive to a bigger & faster drive (nvme0). I'd like to utilize ~100gb for the opensuse root (/) and ~400gb for windows on nvme0. I mount /home to a separate ssd and will move that to nvme1 after the migration. I'd also like to keep grub2 and other boot information on nvme1 since I heard windows10 updates might overwrite the boot record.

nvme1 uses MBR, and I am interested in using GPT on nvme0 due to faster bootup/shutdown times.

fdisk -l for nvme1

Code:

Disk /dev/nvme1n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x006fe885

Device         Boot     Start       End   Sectors   Size Id Type
/dev/nvme1n1p1 *         2048 281810337 281808290 134.4G  7 HPFS/NTFS/exFAT
/dev/nvme1n1p2      281810944 283592703   1781760   870M 27 Hidden NTFS WinRE
/dev/nvme1n1p3 *    283594752 388452351 104857600    50G 83 Linux
/dev/nvme1n1p4      388452352 405225471  16773120     8G 82 Linux swap / Solaris

I've tried cloning nvme1 -> nvme0 using clonezilla, however that appears to preserve the MBR partition table. Cloning partition->partition was giving me 'drive full' errors, even though the target was much larger than the source.

I also tried creating partitions using gparted on nvme0 and I'm not sure if I was successful, because I see the following via fdisk -l even though I created an ext4 file system on /dev/nvme0n1p1:

Code:

Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2762A1CE-CDA6-402B-A862-6296FB7B0182

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048 204802047 204800000  97.7G EFI System
/dev/nvme0n1p2 204802048 974981119 770179072 367.3G EFI System
/dev/nvme0n1p3 974981120 976773119   1792000   875M Windows recovery environment

I just don't know where to really go to proceed, does anybody have any guidance on what steps I should take? I'd prefer not to reinstall either OS if I didn't have to.

Thank you!

bluemoo · 09-25-2018, 01:25 AM

I'm not sure if this will help, lsblk and blkid:

Code:

~ » sudo blkid                                                                                                                                            
[sudo] password for root: 
/dev/nvme1n1p1: UUID="24900E3A900E134A" TYPE="ntfs" PARTUUID="006fe885-01"
/dev/nvme1n1p2: UUID="2232A70232A6D9D5" TYPE="ntfs" PARTUUID="006fe885-02"
/dev/nvme1n1p3: UUID="169a071a-7c11-47d5-97d5-5b254961bd23" TYPE="ext4" PTTYPE="dos" PARTUUID="006fe885-03"
/dev/nvme1n1p4: UUID="05bb9846-3b9a-44b3-824f-1b2f8b9c6c2b" TYPE="swap" PARTUUID="006fe885-04"
/dev/nvme0n1p1: UUID="7048d98a-3171-4125-a2db-c5629184459d" TYPE="ext4" PTTYPE="dos" PARTUUID="54bd6459-f33e-4e60-8267-a74a56e63be3"
/dev/nvme0n1p2: UUID="24900E3A900E134A" TYPE="ntfs" PARTUUID="1b83b710-4b5e-4a5e-a671-0a29eac985b1"
/dev/nvme0n1p3: UUID="2232A70232A6D9D5" TYPE="ntfs" PARTUUID="cb4fce2e-fef4-4b04-9566-8a6ecd4ccbcd"
/dev/sda1: LABEL="/home" UUID="3276d664-9f26-4a5a-9ec2-f1b37cac06a0" TYPE="ext4" PARTUUID="ebcca366-01"
/dev/sda2: LABEL="Steam" UUID="502054A5205493B6" TYPE="ntfs" PARTUUID="ebcca366-02"
/dev/sdb1: UUID="2018-08-16-12-47-49-00" LABEL="2.5.6-22-amd64" TYPE="iso9660" PTUUID="6c8ebbf5" PTTYPE="dos" PARTUUID="000b6c22-01"
/dev/sdc1: LABEL="SYSRCD-5_3_" UUID="FAF1-E1D4" TYPE="vfat" PARTUUID="000c5847-01"
/dev/nvme1n1: PTUUID="006fe885" PTTYPE="dos"
/dev/nvme0n1: PTUUID="2762a1ce-cda6-402b-a862-6296fb7b0182" PTTYPE="gpt"
------------------------------------------------------------
~ » lsblk                                                                                                                                                 
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 232.9G  0 disk 
├─sda1        8:1    0   120G  0 part /home
└─sda2        8:2    0 112.9G  0 part 
sdb           8:16   1   1.9G  0 disk 
└─sdb1        8:17   1   1.9G  0 part 
sdc           8:32   1   7.6G  0 disk 
└─sdc1        8:33   1   7.6G  0 part 
nvme1n1     259:0    0 232.9G  0 disk 
├─nvme1n1p1 259:1    0 134.4G  0 part 
├─nvme1n1p2 259:2    0   870M  0 part 
├─nvme1n1p3 259:3    0    50G  0 part /
└─nvme1n1p4 259:4    0     8G  0 part [SWAP]
nvme0n1     259:5    0 465.8G  0 disk 
├─nvme0n1p1 259:6    0  97.7G  0 part 
├─nvme0n1p2 259:7    0 367.3G  0 part 
└─nvme0n1p3 259:8    0   875M  0 part

FWIW, sdb and sdc are clonezilla and system rescue cd, respectively.

mrmazda · 09-25-2018, 04:58 AM

Quote:

Originally Posted by bluemoo

nvme1 uses MBR, and I am interested in using GPT on nvme0 due to faster bootup/shutdown times.

Where did you get the idea that there could be a difference in times according to whether MBR or GPT is used? The bus, media and filesystem selection determine I/O speed, not the partitioning type. I do partition to partition cloning routinely. It's part of my backup/restore system. P2P works well once the tools' ropes are understood.

syg00 · 09-25-2018, 05:55 AM

Indeed.
Not the only strange thing - why have you allocated the new nmvme partitions as type EFI ?. I don't see an EFI on the old SSDs, which (to me) implies a BIOS based system. If you go gpt, you'll need a BIOS_boot partition. And that's just for grub - I have no idea what Windows will do when the architecture of the disk changes like that. I always just re-install when I have to change a Win disk - path of least resistance.

Stick with MBR (aka dos-mode) partitioning to save yourself the grief - there is likely no advantage to gpt with such small disks. I'm not a fan of imaging systems, but should work ok.

yancek · 09-25-2018, 06:39 AM

If you want windows on a GPT disk, it must be EFI or it will fail. With Linux, you can create a BIOS boot partition as suggested above and then use GPT. It will be a lot easier to just stick with MBR partitioning as suggested if you do not want to reinstall.

bluemoo · 09-25-2018, 09:46 AM

Quote:

Originally Posted by mrmazda

Where did you get the idea that there could be a difference in times according to whether MBR or GPT is used?

I think I got that idea by watching this video from MS about their mbr2gpt utility, though looking at it again it seems they were talking about uefi vs bios.

Quote:

Originally Posted by syg00

Indeed.
Not the only strange thing - why have you allocated the new nmvme partitions as type EFI ?

That was my failed attempt at creating a partition structure with gparted.

Given the feedback here, I'm not going to mess with GPT for now as my drives are <2tb. What steps are recommended at this point? Clonezilla device-to-device from nvme1->nvme0?

syg00 · 09-25-2018, 05:31 PM

As I said, I gave up attempting to clone Win systems years ago. Unless the partition structure is the same (boot/system, physical order) it always seemed to bitch and moan - in one case I had to ring M$osft and get the system re-activated because I had "changed disk too often". And that took hours.
Idiotic arrangement.

You state clonezilla wouldn't work partition-to-partition, but in theory that should be a good way to go. I also haven't bothered with it in years, so can't comment on current state of the tool. gparted apparently allows you to "copy-and-paste" partitions, so that might be quickest for the Linux partitions. Personally I just allocate partitions then rsync and cleanup things like bootloader and fstab later.

bluemoo · 09-25-2018, 06:42 PM

I decided to reinstall windows after fudging around with trying to get it to boot on the new drive with no success. Definitely a lesson learned.