I'm ghosting my system. Can I move partitions one at a time?

[Steve the Pocket]

I'm in the process of trying to ghost my system onto a bigger drive, but after using dd to ghost all of sda onto the new drive, I discovered that Partition Manager wouldn't let me expand the main partition. I'm assuming it's because the partition it's using for swap space is in the way, order-wise. Will it work if I start over and this time move each partition one at a time, so I can expand sda1 before moving the swap space? I was worried maybe it wouldn't know where to look for things if they weren't in exactly the same spot as before.

[Qqmike]

I'm in the process of trying to ghost my system onto a bigger drive ...

You raise a good issue, though. I would need to dig into my notes, but I'm pretty sure that when you use dd to go from smaller to bigger (drive-wise), the result is not seen as a "bigger" drive. dd copies everything, including filesystem structure and related data. As an experiment, you could try partition-by-partition, but, again, I'm kind of certain that that won't work either (to get the use of the bigger drive). I remember experimenting like you here, and think I came to the conclusion that it won't work as expected. I wrote this how-to, but now not remembering at the moment if/how I addressed this, but pretty sure I advised not doing it! I.e., to back up a drive, you should use two drives of the same size.

The dd Command
https://www.kubuntuforums.net/showth...The-dd-Command

[Snowhog]

I'm pretty sure that GParted would do what you want.

[Steve the Pocket]

You raise a good issue, though. I would need to dig into my notes, but I'm pretty sure that when you use dd to go from smaller to bigger (drive-wise), the result is not seen as a "bigger" drive. dd copies everything, including filesystem structure and related data.

If you're suggesting it will make the OS see the entire drive, as in the physical drive, as a smaller one than it is, I assure you that it doesn't; now that I've dd'd the entire 500GB drive onto a 2TB one, Partition Manager can see the almost terabyte and a half of leftover space—and it will let me expand the dba2 partition that holds the swap space, probably because it's the last one before the empty space starts. It will also let me shrink either partition (meaning the down arrow isn't grayed out), so it's not like anything is locked down.

To clarify, the plan was to dd sda1 by itself, then use Partition Manager to expand it, then dd sda2.

[Qqmike]

What dd command are you using?

Smaller disk to larger disk, yes, should work, after which you should be able to use GParted (or similar) to expand partitions.

I found one command I had used:

dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror

[Steve the Pocket]

I was planning to use

dd if=/dev/sda1 of=/dev/sdb1 bs=64K status=progress

But that reminds me: Do I have to create the destination partition ahead of time, or will it do that for me? All of the guides I've found don't actually say. And the swap space is defined as a partition (sda5) inside another partition of the same size (sda2), so I don't know if just duplicating sda2 would do the trick or if it gets even more complicated.

[Snowhog]

dd is a 'bit for bit' clone of the source to the destination.

[Steve the Pocket]

Right, but what does that mean if I use the command I listed and /dev/sdb1 doesn't exist yet?

[Snowhog]

If the output destination (of=) doesn't exist; isn't mounted; the command is going to fail.

[Qqmike]

dd will create a file if it isn't already created; but a partition is another matter. Slippery slopes here.

[oshunluvr]

Yeah, I can think of safer and easier ways to do this. Qqmike is correct, to dd /dev/sdb is just a destination. If there's no device mounted there, dd will not fail. It will create a file of the size you send it.

Proof:

stuart@office:~/.local$ ll /dev/sdm
ls: cannot access '/dev/sdm': No such file or directory
stuart@office:~/.local$ sudo dd if=/dev/zero of=/dev/sdm bs=1024 count=512
[sudo] password for stuart:  
512+0 records in
512+0 records out
524288 bytes (524 kB, 512 KiB) copied, 0.000482235 s, 1.1 GB/s
stuart@office:~/.local$ ll /dev/sdm
-rw-r--r-- 1 root root 524288 Mar  2 17:28 /dev/sdm

So you can see a slight misstep with dd can have disastrous effects. If you sent your whole drive image there, you would fill the entire drive and maybe not know why or how to fix it.

Why not boot to clonezilla and let it do a partition to partition clone? Why not re-install and just move your home? Why not boot to a liveUSB and do an rsync? Why not use a backup and restore program?

BTW, just because it's my thing and I can't help myself, if you had used btrfs we wouldn't be having this discussion at all. You already be done.

[jlittle]

I was worried maybe it wouldn't know where to look for things if they weren't in exactly the same spot as before.

No, where a file system is gets resolved at mount time, except that the boot loader (by default grub) has to find a system to boot it. By default, both use the UUID. You can use sudo blkid to list them, and check the entries in /etc/fstab. Running sudo update-grub will sort out grub.

One gotcha I learned the hard way is that cloning a partition usually just clones its UUID, and confusion occurs if at boot the UUIDs are not unique. gparted has a "New UUID" function to avoid that case.

Now, a thought. I dislike UUIDs, and I use labels instead. I have to make sure my drives have unique labels, but that's easy.

Regards, John Little