1

Since the original SSD of my Laptop (sdb) is relatively small (100GB) I recently installed another SSD (sda) with a larger capacity (500GB). My idea was to clone the old SSD (sdb) onto the new SSD (sda) with the dd command, therefore I ran the following command from a live-usb-ubuntu-stick:

sudo dd if=/dev/sdb of=/dev/sda bs=64K

in order to copy the contents of sdb (older SSD) onto sda (newer SSD).

After I ran this command, I had difficulties booting from either of the two SSDs (both of which are still installed in the laptop). I then ran the boot-repair command and now GRUB starts normally when I boot from sda. GRUB gives me the following options:

 - Ubuntu
 - Windows 7
 - Ubuntu (on /dev/sda5)
 - Windows 7 (on /dev/sda2)

The problem is that when I want to start the Ubuntu version on the newer SSD (option Ubuntu (on \dev\sda5) in GRUB), GRUB still loads the Ubuntu installation on the old SSD \dev\sdb5.

I think I might need to make manual changes in \boot\grub or to the file \etc\fstab on sda?

\etc\fstab currently has the following contents (on \dev\sda):

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb5 during installation
UUID=c4055038-09dd-417e-88f1-228ffcf873c1 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sdb6 during installation
UUID=9c79ac5d-78a8-4ab7-9141-8397cb686e25 none            swap    sw              0       0

EDIT:

When I choose Ubuntu (on \dev\sda5) in GRUB and I then run lsblk in a terminal I get the following:

sda      8:0    0 465.8G  0 disk 
├─sda1   8:1    0   102M  0 part 
├─sda2   8:2    0  78.3G  0 part 
├─sda3   8:3    0     1K  0 part 
├─sda5   8:5    0 195.8G  0 part 
└─sda6   8:6    0   7.9G  0 part 
sdb      8:16   0 119.2G  0 disk 
├─sdb1   8:17   0   102M  0 part 
├─sdb2   8:18   0  78.3G  0 part 
├─sdb3   8:19   0     1K  0 part 
├─sdb5   8:21   0  31.8G  0 part /
└─sdb6   8:22   0   7.9G  0 part [SWAP]
4
  • 1
    Your dd command is a total clone including all UUIDs. And then assumes you disconnect old drive or totally repartition & reformat it. You cannot have duplicate UUIDs. Often easier to just reinstall Ubuntu. But Windows not so easy. You have to change UUIDs in one drive or the other. Or totally erase old drive if new drive works when old unplugged. If you want both installs, you have to change UUIDs & update fstab, grub and a few other settings with UUIDs.
    – oldfred
    Oct 31, 2018 at 21:47
  • Hey, thank you for your reply. If I would physically remove my old SSD from the computer, then I should be able to boot from the new SSD?
    – Mantabit
    Oct 31, 2018 at 21:57
  • Try it and see. If that works, then repartition & reformat old one to use it again. If you run Boot-Repair or just lsblk -f or sudo blkid You should see the same UUIDs on both drives which will not work.
    – oldfred
    Oct 31, 2018 at 21:59
  • You can use gparted to create a new UUID on one of the drives. Update the UUID used in fstab to suit. No reason to reinstall Ubuntu. Nov 1, 2018 at 4:06

1 Answer 1

1

clone-ubuntu.sh Bash Script

Using clone-ubuntu.sh will quickly do what you want. Relevant code snippets to address your problem are included below but visit the link for the complete picture.

Clone like dd

Clone like dd but do it without rebooting into a Live USB. Virtual file systems are automatically skipped to save time and eliminate errors. The script can be rerun if need be (you are testing Ubuntu upgrades/updates for example) and is faster the second time:

rsync -haxAX --stats --delete --info=progress2 --info=name0 --inplace  \
      /* "$TargetMnt"                                                   \
      --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found}

Update /etc/fstab

Using lsblk to ascertain source and target UUID's the changes are made automatically in the new clone:

# Update /etc/fstab on clone partition with clone's UUID
echo ""
echo "====================================================================="
echo "Making changes in: $TargetMnt/etc/fstab"
echo "        from UUID: $SourceUUID"
echo "          to UUID: $TargetUUID"
sed -i "s/$SourceUUID/$TargetUUID/g" "$TargetMnt"/etc/fstab

Update grub menu with new entries

Grub needs to know the correct UUID's and clone-ubuntu.sh automatically makes them for you:

# Update /boot/grub/grub.cfg on clone partition with clone's UUID
echo ""
echo "====================================================================="
echo "Making changes in: $TargetMnt/boot/grub/grub.cfg"
echo "        from UUID: $SourceUUID"
echo "          to UUID: $TargetUUID"
echo "Also change 'quiet splash' to 'nosplash' for environmental awareness"
echo "Suggest first time booting clone you make wallpaper unique"
sed -i "s/$SourceUUID/$TargetUUID/g" "$TargetMnt"/boot/grub/grub.cfg
sed -i "s/quiet splash/nosplash/g" "$TargetMnt"/boot/grub/grub.cfg

Summary

The relevant bash / shell commands are included so you can do the same steps manually for a successful clone that boots and operates as expected.

2
  • Thanks for your reply. I changed the UUID of the new SSD to a new UUID, updated the fstab file and ran update-grub but the problem still persists. I might just format the new disk again and run clone-ubuntu.sh. Is it safe to use with 14.04?
    – Mantabit
    Nov 1, 2018 at 8:30
  • You don't have to format the new disk again to use clone-ubuntu.sh. Just boot with your old disk and point it to the new disk's unmounted partition. I don't have Ubuntu 14.04 to test with but I can't think of any reason why bash won't work on it. Nov 1, 2018 at 10:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .