The question is quite simple. I have search for an answer for a while but not sure I got the correct answer. Since mistakes could easily destroy my drive and data, I really want things to be clear.

I am running Ubuntu on a 250GB SSD (/dev/sda) which has two partitions, each is about 125GB big. The sda1 is mounted to / and sda2 is mounted to /home. Now I want to move everything into a new 1TB SSD (let's say it is /dev/sdc) and expand each drive into 500GB. After some research, I proposed two approaches:

  1. Do dd if=/dev/sda of=/dev/sdc to clone the whole disk. After this I should get a bootable disk with two 125 GB partitions and some unallocated space. Right? Then I need resize the sdc1 and sdc1 into 500GB with something like gparted. The resizing might take long, right?

  2. The second approach is format the new drive first, make two 500GB partitions. Do dd if=/dev/sda1 of=/dev/sdc1 and dd if=/dev/sda2 of=/dev/sdc2 to clone both partitions. At this point, this disk should be unbootable, right? In order to make it bootable, I need copy the bootloader into the new one. All I need is the first 446 bytes. So I can dd if=/dev/sda of=/tmp/mbrsda.bak bs=512 count=1 then dd if=/tmp/mbrsda.bak of=/dev/sdc bs=446 count=1. By doing this I made it bootable and also preserved the partition table for 500GB+500GB. This approach will save me from resizing the disk.

And for both approaches, I need change the UUID in the /etc/fstab file. This can be done by first mount the new drive after cloning: sudo mount /dev/sdc1 /mnt/, then edit the /mnt/etc/fstab file.

Am I right about all of this?
Any potential risk of messing up my old drive here?

  • 1
    Is drive MBR or gpt. Best not to use dd with gpt. Generally I find a new install and copy of /home and maybe some settings in /etc. And export list of installed apps and reinstall that list. That is typically quicker as you avoid all the issues of resizing or resetting UUIDs and reinstalling grub.
    – oldfred
    Commented Jun 19, 2019 at 3:46

4 Answers 4


Any time you use dd (a.k.a. disk destroyer) there is a potential for messing up your data. dd has no safeguards for accidentally writing your new drive over the old drive. The only thing keeping it working right is if you're VERY careful with typing the commands correctly and not mixing up the source and destinations. if= and of= are only one small mistyped keystroke away from each other!

The other problem is that dd is slow and puts unnecessary wear on your target SSD. Most partitions are typically no where near 100% utilization. Using dd to copy a partition with lots of free space ends up copying EVERY BYTE of said partition, even the bytes that aren't actually containing any allocated data!

Here's what I would do if it were my system:

  1. Take a screenshot of your old SSD's partition table for reference later when we set up your new SSD's partition table.
  2. Connect the new SSD to the computer and disconnect the old SSD. Keeping the old SSD disconnected makes it impossible to destroy any of our precious data while we do potentially destructive work.
  3. Boot from the Ubuntu installation USB thumb drive in Linux live mode. Make sure your BIOS always boots the thumbdrive in legacy/MBR mode instead of UEFI mode, since it sounds like your old system is using MBR. If my assumption is invalid, make sure your BIOS boots the thumbdrive in UEFI mode instead. Mixing things up would make it a lot harder to get grub to install properly later on.
  4. Use gparted to set up your new SSD with the desired partition table and format the filesystems. Try to keep everything the same as your old SSD's partition table (aside from partition sizes and UUID's). Don't forget to mark the / root filesystem as active / bootable, just like your old SSD.
  5. Now that all the dangerous partition editing stuff is done, you can safely shutdown and add the old SSD connected to the computer.
  6. Boot the Linux live USB thumb drive again with both drives connected this time. Do not boot from the old SSD (we need to keep that system inactive to make a good clean copy of it).
  7. Once booted, open a terminal and start working through these commands to copy the data from your old SSD to your new SSD. Unlike using dd, the cp command is far more error-proof because you can't destroy anything copying an empty file system over top of your old file system -- there is nothing copied in that case! Plus, we can mount the old SSD in "read-only" mode to avoid any possibility of modifying the old SSD.

    mkdir oldroot newroot oldhome newhome
    sudo mount -o ro /dev/sda1 oldroot
    sudo mount -o ro /dev/sda2 oldhome
    ls oldroot
    ls oldhome

    Verify that you can see your old data. If all you see is an empty file system, perhaps you've got the wrong "/dev/sdXX" device...

    sudo mount -o noatime /dev/sdc1 newroot
    sudo mount -o noatime /dev/sdc2 newhome
    ls newroot
    ls newhome

    Verify that all you see is an empty file system as your destination. If everything is good, issue the following commands to copy all of your files while preserving all the permissions/ownership/SELinux context settings:

    sudo cp -Rfax oldroot/* newroot/
    sudo cp -Rfax oldhome/* newhome/

    Once that's done, unmount everything and sync cached writes to persistent storage:

    sudo umount oldroot
    sudo umount oldhome
    sudo umount newroot
    sudo umount newhome
  8. Now you can safely shutdown and disconnect the old SSD so that we can't possibly destroy anything on it while we work through making the new SSD bootable.

  9. Boot the computer using the USB thumb drive in Linux live mode with only the new SSD connected. Open a terminal and start working through these commands:

    mkdir newroot
    sudo mount -o noatime /dev/sda1 newroot
    sudo chroot newroot /bin/bash
    mount -t devtmpfs udev /dev
    mount -t proc proc /proc
    mount -t sysfs sysfs /sys
    nano -w /etc/fstab

    Now you need to modify the fstab file to match the UUID numbers to whatever they are on your new SSD. You can open gparted to look at your partition table and figure out what the new UUID's are. When done, hit CTRL-X and save the fstab changes to disk.

    grub-install /dev/sda

    If everything is working right, this should configure grub and install it into your new SSD's MBR. After grub is installed, you have to unmount all the stuff we previously mounted from within the chroot environment before exiting. Otherwise, Ubuntu will have a hard time unmounting the Linux partition cleanly when you shutdown.

    umount /sys
    umount /proc
    umount /dev
    sudo umount newroot

And there you have it! Hopefully your new SSD is bootable and everything is good now.

  • 1
    an edit and an upvote! Please review my edits to see how I did that: 8 spaces indent code, 1 space in front of a paragraph indents the entire paragraph. ;-)
    – Fabby
    Commented Jun 19, 2019 at 12:46
  • Much easier to get use cp from device to device. And no fannying around with uuids so your fstab will still work. Your solution is way more error prone and time consuming. Boot from sysrescue, ensure both drives connected. From terminal: cp /dev/sda /dev/sdb. Done.
    – RichieHH
    Commented Oct 18, 2023 at 7:53

I just used gparted to migrate my ubuntu 18.04 from one SATA to another. Gparted provides an easy to use GUI with copy and paste options, and even the UUIDs are the same so I didn't have to update /etc/fstab or install grub on the new disk. It was very smooth, so I haven't check out what happened underneath yet, but during the copy-paste process, e2image(8) was actually invoked. Again, this was all based on my own experience, please correct me and thank you guys.


I post this here, more to share my experience and less to answer the posted question. However, my goal was the same as the stated goal of the OP.

I started with a dual-boot system on a 512 GB SSD, which contained a couple of partitions: EFI, something Microsoft reserved, the Windows system partition, the Linux system partition, the Linux home partition and something recovery something.

My goal was to migrate everything to a 2 TB SSD.

I booted the computer from an Ubuntu Live-USB, and cloned the whole SSD to the new SSD using dd. I got myself a small enclosure for NVMe SSDs which can connect via USB.

The new SSD was used totally untouched: no formatting, no partitions, no nothing.

After cloning with dd I exchanged the SSDs, i.e., I removed the small SSD from the computer and installed the new one.

Linux booted without a hitch, but Windows ran some diagnostic/repair which led to nothing.

Next, I booted the system from the Ubuntu Live-USB again, and launched gparted.

gparted reported some error in the GPT table which it offered to repair. I chose the repair option and proceeded to resize and move the existing partitions. After this was all done, to my surprise, Windows also booted without error.

I am pleasantly surprised that this whole cloning affair went as smooth as it did.

I did it again this week, again with a dual boot machine.

  • Start the computer with the small SSD still inside using a Live-USB
  • Mount the new SSD into an enclosure and plug it in
  • Copy the disks using dd
  • When dd has concluded, launch gparted repair the GPT table, and resize and move the partitions
  • Shut down the computer and exchange the SSDs
  • Both OS' booted just fine

Some notes:

  • Make sure BitLocker is well and truly disabled, if the old SSD contains a Windows partition
  • If you forget to launch dd with any options that display progress, see this answer. You can send dd a signal, causing it to display progress information without disturbing its operation.

Updated to add:

I have now upgraded several laptops with larger SSDs, and I have this to observations to share.

  • Block size: setting a larger block size, e.g. bs=64K vastly improves the copying time.
  • After you have disabled Bitlocker, do a reboot first before, booting into a Live-USB Linux to perform the actual copying operation using dd. The reboot is needed, so that gparted recognizes the partition as being of the type ntfs, and thus editable, rather than of the type bitlocker, which can only be moved but not enlarged (which is the purpose of the whole operation.
  • While you are at it, i.e., enlarging the partitions on the larger drive after dd has done its thing. You may want to throw the Recovery Partion a couple of hundred megabytes, since there's an issue with some Windows Updates and insufficient available space on the Recovery Partition, see this question of mine over on SuperUser and related questions and posts.

I would use partimage to copy the partitions one at a time. After you copy the first partition, increase its size. The resize will be very fast because you won't have to move any adjacent partitions. Then copy the second partition and resize it to fit the rest of the space.

The easiest way to do this is to boot from SystemRescueCD and do everything from that environment. You can make a bootable USB drive so you don't need an actual CD.

You must log in to answer this question.

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