I have only been seriously using Linux for a couple of months; I cannot find a simple solution to copy an OS over to another drive, despite there being hundreds of articles on the topic.

First I tried a straight copy of the root, obviously this was a fail.

Using my rudimentary comprehension I tried the following:

  1. Get new SSD, plug in
  2. type lsblk
  3. see the drive is called sdb (for example)
  4. type sudo mkfs.ext4 /dev/sdb
  5. create a partition with fdisk (sdb1 for example)
  6. put GPT on the partition (sdb1) with fdisk
  7. copy contents: sudo rsync -WavxHAX / --exclude={"/media/*"} /media/Rob/3a9142f5-8916-406e-87b0-4ec87d7a3d12/

(assuming the drive is mounted in media) I may have also skipped a mounting step like:

sudo mount /dev/sdb1 /mnt

This was written from memory, the steps were probably tried out of order, such as create GPT then format partition to ext4; but I couldn't figure it either way. Anyway, the basic concept is outlined above; no extra downloaded programs or live USBs need apply.

Can someone please shed some light as to how I could accomplish this?

  • Why can't you use a live USB? In general you can't get a good copy of the system while it is running. You really have to umount the drive that you want to image. May 31, 2020 at 3:14
  • Hi user1794469, well I've heard it be done, granted odd that seems so obscure to do so, so I'm hoping otherwise. I see a variety of issues in having to use a USB and needing one on-hand, besides the hassle. Wouldn't I need the same OS on the boot media as the OS I was moving across?
    – 1toneboy
    May 31, 2020 at 11:13
  • Note all the hassle you are having. A new install to a prepartitioned gpt SSD takes about 10 minutes or less. Then you restore your data & settings from /home from your backup and reinstall exported list of installed apps from backup. That verifies your backup process includes everything while you still have old drive just in case backup is not complete.
    – oldfred
    May 31, 2020 at 15:23

2 Answers 2


Assuming your system is on sda and your new drive is sdb having enough capacity, I would suggest you to consider using dd to get a functionally identical copy of your OS:

dd if=/dev/sda of=/dev/sdb bs=128M

you may want adjust bs (block size) paramteter depending on your disk size/preferences. Just be careful to not confuse: if is for source of is for destination

Once the copy is completed, the sdb disk can be used right away after you change you BIOS/EFI settings to boot from the sdb - you'll have to identify it there first.

  • Hi Tagwint, I used dd and it worked! Very easy method, thanks I like it. Where can I learn about what is a suitable 'bs=...'?
    – 1toneboy
    Jun 8, 2020 at 11:59
  • Right reference would me man dd, but considering you are newbie to that, you can start with other's answers like this: stackoverflow.com/a/27772496/439650
    – Tagwint
    Jun 8, 2020 at 12:38
  • 1
    if sda bigger than sdb and contains gpt you won't have a working copy! if sda smaller than sdb it will make sdb size same as sda size and hides remaining free space! dd clonning is perfect for same sized disks or it'll need more workarounds.
    – Yunus
    Jun 8, 2020 at 12:55
  • Hi Jonah/Tagwint, so Tagwint, there is no best default but you recommended 128mb, yet the rule-of-thumb that person gave was 64kb? That's a big difference, is it a trade-off between speed and disk space consumption efficiency? Jonah, so you wold only recommend using dd if two SSDs are the same size? If sdb is bigger then can you not access the remaining hidden space at all?
    – 1toneboy
    Jun 9, 2020 at 2:36
  • @1toneboy, I think now it is time for you to do some research yourself and show your effort, there are ways of getting the hidden space back or limit the dd scope of copying in advance. These would be another questions i guess, we should not transform this comment chain to a tutorial, should we ? :) Here some start point for you to start your way: unix.stackexchange.com/questions/475177/…
    – Tagwint
    Jun 9, 2020 at 8:40

you cannot copy an os while running because of the mounted stuff inside /dev /proc /sys ,

but the ext4 allows us to mount a partition to different mount points,

and also you can bind already mounted folder .

# create mbr table on new SSD printf '%s\n' o w |sudo fdisk /dev/sdb;

# create partition on it printf '%s\n' n p 1 '' '' y w |sudo fdisk /dev/sdb;

# write ext4 fs on new partition sudo mkfs.ext4 /dev/sdb1;

# create folder where to bind / (root) sudo mkdir my_os; # mount new partition sudo mount /dev/sdb1 /mnt/; # mount|bind actual system to /mnt sudo mount --bind / my_os/; # like it will clone / to my_os but excluding sub mountpoints /dev /proc /sys # copy the system sudo cp -arxpf my_os/* /mnt/;

# unmount my_os sudo umount my_os;

# remove created folder my_os sudo rm -r my_os;

# change partition UUID inside new system oldUUID="6e92d1d9-ca30-42d9-9e14-c749d0f349b5"; newUUID="$(eval $(sudo blkid /dev/sdb1|awk '{print $2}') ; echo $UUID)";

# loop over files that contains old UUID replace oldUUID by newUUID sudo grep -rl "${oldUUID}" /mnt/{etc,boot} | while read f;do sudo sed -i --follow-symlinks "s/${oldUUID}/${newUUID}/g" "${f}" done

now if you wish to use this as dual boot then you just need to update the grub

sudo update-grub;

if you wish to use on other pc then you need to install grub for that hard drive to be able to boot to do so you have two ways :

  • first

by installing curent grub to the new hard drive , (a bit risky)

sudo grub-install /dev/sdb;
sudo update-grub;
# unplug new SSD
sudo grub-install /dev/sda;
sudo update-grub;
  • second

by chroot into the SSD and install its grub , update it from there !

# mount SSD in not mounted to /mnt
sudo mount /dev/sdb1 /mnt/; 
# prepare chroot envirement
sudo mount -t proc /proc /mnt/proc;
sudo mount -t sysfs /sys /mnt/sys;
sudo mount --rbind /dev /mnt/dev;
sudo cp -f /etc/hosts /mnt/etc/;
sudo cp -f /etc/resolv.conf /mnt/etc/resolv.conf;
sudo chroot /mnt rm /etc/mtab 2> /dev/null ;
sudo chroot /mnt ln -s /proc/mounts /etc/mtab ;
# get SSD path by UUID , probably it's /dev/sdb 
grub_install_target="$(sudo chroot /mnt blkid |grep "${newUUID}"|awk -F: '{print $1}')";
((${#grub_install_target})) || echo you cannot continue;
# install grub and update it
sudo chroot /mnt grub-install "${grub_install_target}";
sudo chroot /mnt update-grub;
# unmount SSD before unluging it 
sudo umount -fl /mnt;

when you boot new copy google about adding a swap file (optional)

but as it was told to you a fresh installation is super quick and fine , if you just cannot use usb think about grub-imageboot or grml-rescueboot, you can boot an iso from your actual hard drive an install it to the new SSD .

good luck

  • Hi Jonah, Thanks for the reply I feel like it's going to be very helpful for me, however despite following it up with some research I still feel as though I only understand half of it and am too scared to try and implement it. Could you please add a bit of elaboration to the reasoning and clarify the steps?I only have a very basic understanding of what GRUB or chroot are. Is the mount --bind of root /somewhere/ just arbitrary and the /elsewhere/ the new drive? If so, why the need? An fictitious example would be great. Thanks heaps
    – 1toneboy
    May 31, 2020 at 10:54
  • P.S the contents of my fstab file: # Pluggable devices are handled by uDev, they are not in fstab UUID=6e92d1d9-ca30-42d9-9e14-c749d0f349b5 / ext4 defaults 1 1 UUID=f6fa5d86-ca03-41b8-b59e-ce427520787a swap swap defaults 0 0 Does that effect your while-do loop?
    – 1toneboy
    May 31, 2020 at 11:27
  • yes i'll update the answer with more details, but it'll be better if you tell how you wanna use the new copy : do you wanna replace your actual hard drive ? do you wanna keep both on same machine as multiboot? cause diffrent way for each case!
    – Yunus
    May 31, 2020 at 13:31
  • Hi Jonah, I'm really impressed with your reply, thank you. I don't know much about file systems, but why did we create an MBR instead of a GPT? And why did we have to make a blind mount of the root to /mnt? Admittedly I didn't mkdir sdb1, I just mounted /dev/sdb1 straight into /media. But this shouldn't matter should it? Anyway, I don't think the UUID actually worked. This is what it says:
    – 1toneboy
    Jun 1, 2020 at 12:26
  • ...It says: $ blkid /dev/sda1: LABEL="rootMX19" UUID="6e92d1d9-ca30-42d9-9e14-c749d0f349b5" TYPE="ext4" PARTUUID="31d3ad8c-01" /dev/sda2: LABEL="swapMX" UUID="f6fa5d86-ca03-41b8-b59e-ce427520787a" TYPE="swap" PARTUUID="31d3ad8c-02" /dev/sdb1: UUID="89aacba3-0311-4fe7-aff5-7a0e137c2e54" TYPE="ext4" PARTUUID="5e432ae4-01" They are still different. Is it the PARTUUID that matters? Why does it need to change at all? Sorry about all the questions. Thank you very much!
    – 1toneboy
    Jun 1, 2020 at 12:30

You must log in to answer this question.

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