Score:1

Moving Ubuntu root to a new SSD which will become the boot device

io flag

I have a Dell desktop which I bought used, at which time it was set up to dual boot Windows (on disk 0 - /dev/sda ) and Ubuntu (on disk 1 - /dev/sdb). I nuked the Windows installation and /dev/sda now contains data.

Fdisk shows:

Device         Start       End   Sectors   Size Type
/dev/sda1       2048   1023999   1021952   499M Windows recovery environment
/dev/sda2    1024000   1228799    204800   100M EFI System ( mounted at/boot/efi)
/dev/sda3    1228800   1261567     32768    16M Microsoft reserved
/dev/sda4    1261568 656621567 655360000 312.5G Microsoft basic data (really linux ext4 fs)
/dev/sda5  656621568 976773119 320151552 152.7G Linux filesystem (ext4)

I am purchasing an SSD which I want to use as the boot device (UEFI, not legacy) and which will contain the root partition. I want to clone the current root partition (/dev/sdb1) to the SSD rather than do a new install of Ubuntu, so I can preserve all customizations and configuration.

I assume the steps, in order, are

  1. Format SSD, create empty GPT partition table (maybe it will have one ???)
  2. Create required partitions on SSD - EFI (fat32), root (ext4)
  3. Populate EFI (grub-install ?)
  4. Copy root from /dev/sdb to SSD

I'm not at all sure how to proceed - should I do all this from a liveUSB of my current Ubuntu (22.04) ? Once I've copied the existing root partition to the SSD I assume I'll need to tweak /etc/fstab ? Are there any other gotchas ?

I'd appreciate a sanity check and feedback.

TIA.

petep avatar
in flag
Look at dis "https://askubuntu.com/questions/740253/how-to-install-grub-in-an-external-hard-drive"
PonJar avatar
in flag
You have nothing to lose by using GParted in a live environment to “copy/paste” the partitions you want to move to the ssd. After that you will probably need to adjust UUID’s or whatever you use to identify partitions in fstab. You may also need to fix grub. If you are happy to tackle these potential issues then that would be my preferred approach.
oldfred avatar
cn flag
Are you keeping current drive with Ubuntu? If so you cannot have duplicate UUIDs or GUIDS. While possible to change, it really is quicker & easier to do new install & restore from your normal backup. And if backup is not complete to fully restore system, you still have old install. Backup at minimum should include list of installed apps, /home, any other data partitions and if server type apps, web, database, those folders in / (root). If you do not have good backup, you should not be making major changes.
Score:0
ls flag

You have some of your steps out of order and there are a few pieces missing here, but the general idea you have is good.

Firstly, yes, you will want to use a live USB to do the cloning. You should have every file on your root partition "at rest" (i.e., no program actively using it) while cloning things.

Next, you are right about first making an EFI partition and then a root partition. However, this will give you two EFI partitions, one on your old disk and one on the new one, which could cause confusion. We can deal with that part at the end.

The next step is not the grub-install step. Rather, this is when you want to do the cloning. From a live USB, you'll want to do something like this:

cd /mnt
mkdir source
mkdir dest
sudo mount /dev/sdXY ./source    # this isn't guaranteed to be sdb1 anymore, so check it with lsblk first!
sudo mount /dev/sdAB ./dest
sudo cp -a ./source/. ./dest/.   # the slashes and periods are important here

That last command will take a while to run, depending on how much it has to copy. This will copy over all of the files on your root partition to the new partition, preserving as much info as possible, including file permissions. (Do NOT use cp -r here, it will mangle file permissions and you'll almost certainly get a broken clone. cp -a is the way.)

Once that finishes, your clone is done, but you're not quite out of the woods yet. You still have to install the bootloader, but also, you will have to tweak /etc/fstab. This is the file that tells Linux what to mount and where to mount it during bootup. Usually /etc/fstab identifies your root partition via UUID, and your partition's UUID will be different than it used to be.

To figure out your partition's UUID, use lsblk -f. This will display a bunch of partition info, including the UUIDs. Find the UUID of your destination drive, and copy it into a text file.

Next, run "sudo nano /mnt/dest/etc/fstab", and find the line that mounts your root partition (it will have a single / as the mountpoint). Replace the UUID in this line with the UUID of the new partition that you found earlier. Then press Ctrl+S to save, and Ctrl+X to exit.

Now we can install the bootloader. Mount the new EFI partition using sudo mount /dev/sdAC /mnt/dest/boot/efi (replacing AC as appropriate). Then you should be able to install the bootloader with a command like this:

sudo grub-install --target x86_64-efi --efi-directory /mnt/dest/boot/efi --boot-directory /mnt/dest/boot

And lastly, generate the GRUB configuration:

sudo grub-mkconfig -o /mnt/dest/boot/grub/grub.cfg

With that complete, shut down the computer, disconnect the old drive to keep the old EFI partition from causing confusion, and then try and boot into the cloned installation. If you can boot successfully, you hopefully should be good to go!

Simon R avatar
io flag
Thanks for getting me launched. Everything was fine until the 'grub-mkconfig' step, which unfortunately did not work - it failed with a 'failed to get canonical path of /cow' error, due to the live cd environment. I edited the existing /boot/grub/grub.cfg on the SSD drive (which was copied from the HDD /sdb1) to change the UUIDs to point to the Linux on the SSD. After some fiddling with the BIOS boot options so that the default boot was to the SSD I was able to reboot into the new install successfully.
ArrayBolt3 avatar
ls flag
@SimonR Ugh, I forgot about the live boot environment part. You have to chroot into the installed system *after* doing some bind mounts in order to make it work. I'll try and edit that in sometime soon. Anyway, glad it worked!
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.