I want to clone my existing Kubuntu OS from my HDD to SSD...

[imstupid]

I think I know how to do that from KDE Partition Manager from a .iso USB, but I have no idea how to make sure the grub is updated. I had a Google but could find the right steps for KDE distros.

Here is how I think it works...

1) Boot into .iso USB stick and open KDE KDE Partition Manager
2) Right-click then Copy the existing OS on the HDD
3) Right-click then Paste into the new SSD.
4) Grub??

TBH I'm not sure if I even have 2 & 3 correct. Any pointers would be helpful!

[oshunluvr]

I think that would work but that's gonna take a while to complete. Honestly, I've considered using KDE Partition Manager to copy an entire partition. I read the manual and it says it will even allow you to shrink or grow the partition during the operation. I say go for it.

Since grub uses UUIDs to determine boot device, before rebooting, I would check the UUIDs of both partitions. If they are the same, then you would need to change the source (HDD) file system to a new UUID. That way, theoretically, GRUB would just boot to the new partition. If the UUIDs are different, you would need to change the new (SSD) file system to the same as the old file system, THEN change the old file system to a new UUID.

Not too hard in a terminal. I didn't see a way to do it using Part. Manager.

This command will list the UUIDs

blkid

This will generate a new UUID for the old partition

sudo tune2fs -U random <partition>

You for sure have to make sure the UUIDs are different somehow.

Assuming the new SSD copy has a different UUID than the old HDD, another way would be to reboot to the original install, mount the new SSD partition and edit /etc/fstab and /boot/grub/grub.cfg to show the new UUID, then run update-grub. Then you could boot either install.

BTW, if you're using UEFI to boot, all bets are off. I'm not sure what you'd have to do in that case.

[jlittle]

KDE Partition manager doesn't appear to have a new UUID function, but Gparted does. If you do copy partitions, you really do want to make sure the UUIDs are not shared, or OS and user will be confused.

I think copying and pasting partitions in the partition manager is problematic, but might work, perhaps very slowly.

Assuming the computer uses UEFI...

On the hard drive you likely have three or four partitions: a small FAT32 "EFI System Partition" (ESP), /, /home, and possibly a swap. (If you don't know whether you need a swap partition, it's likely you don't; in any case, it's not useful to copy it.)

I usually don't like to give suggestions without testing them myself, but I don't have a spare SSD lying around, so with that misgiving, here goes. I can think of three things to be fixed up:

1. /etc/fstab
2. grub in /boot/efi/EFI/ubuntu/grub.cfg
3. The boot variables in NVRAM that tell the computer where to boot from.

The /etc/fstab needs the UUIDs changed (or IMO better, use labels, but no-one else uses them).

2 and 3 could both be sorted by running grub-install with the --boot-directory and --efi-directory options. While booted from the HDD, you'd mount the new ESP partition and the new root partition somewhere (say, /mnt/newesp and /mnt/newroot) and run

grub-install --efi-directory=/mnt/newesp --boot-directory=/mnt/newroot/boot

Again, I haven't tested this.

I would use a partition manager to make the partitions you want on the SSD, adjusting the sizes to suit the SSD, and noting the new UUIDs. After mounting the new partiions I'd use sudo rsync -aAxX to copy the files from / to the new root and /home to the new home; that way unused space is not copied. Then I'd edit the /etc/fstab, and run the grub-install.

[Qqmike]

By "copy," does that mean a file system copy or a dd copy (I presume the latter?). This whole issue can be fraught with catches. If copy is by dd, dd will copy everything -- including filesystem structure. Always, the boot device must be fixed afterwards, as the guys have said, and UUIDs are dd'd exactly, so there is an issue. Size matters: can't go from a big drive to a smaller one; ideal to go from and to same-sized drives; but what if you go from a smaller drive to a larger drive? -- on the end result of the larger drive, is that larger drive then "seen" as a small drive? I have done a lot experiments in the past; but like jlittle, I'm hesitant to say too much nowadays without some up-to-date experimenting. And THAT may be what you end up doing for us here, imstupid! testing out your plan.

[Snowhog]

Very old (7+ years ago), but it does contain detailed 'instructions'. Thought you might find it interesting, maybe even useful? https://unix.stackexchange.com/quest...s-will-need-ed

[Qqmike]

Interesting, Snowhog, thanks. I only quickly scanned over it, but can see that some surgery is called for! especially on the source disk. And tricks to fool the process, like forcing the backup GPT to be in its proper place on the target disk. And so on. No easy ride, no free lunch, and something must give for it to work. Thanks, again.

[jlittle]

By "copy," does that mean a file system copy or a dd copy (I presume the latter?)...

I think the OP meant copy and paste within the KDE partition manager. I tried to do that on an old MBR drive, for a small boot partition, and the partition manager accepted the commands, queueing up an operation to "copy and resize" the partition, but it didn't work, without a failure message, though it took a long time about it. I suspect there was some MBR complication, like too many primary partitions. I expect the operation would be similar to a dd copy.

I prefer creating a target partition first, then a file copy with sudo rsync -aAxX (or something similar, like sudo tar cf - * | (cd /mnt/new;sudo tar xf -). It means the target partition is created with options suitable for an SSD, though I'm not sure if this is still an issue. As well, one can change the partition type that way, or copy from one system to another. Unless the partition being copied is very full, or has very many small files, a file copy will be faster than dd.

[Qqmike]

Ah, yes, I see now. No wonder I am confused here! ha! I'll have to re-read everything. When I see the word "clone," I think "dd"! Thanks.