My current situation is:

  • One hard disk
  • Dual boot Ubuntu 11.04 and Windows 7. Partitions:
    • 100MB Windows System thingy
    • 144GB Main Windows
    • 160GB Ubuntu
    • 4GB Swap
    • 12GB System Restore stuff

Now I want to install an 80GB SSD and move Ubuntu to it. AFAIK I need to:

  • Shrink the 160GB Ubuntu partition to 80GB
  • Copy it over to the SSD
  • Change fstab to mount the SSD as /

How do I do the second? And what do I need to do about Grub?


5 Answers 5


1) Copying files

You want to copy the FILES, not the whole partition ( including its free space ), so you don't need to resize the partition first. Boot from the livecd and mount both the HD and SSD ( after formatting a partition on the SSD of course ), then copy all of the files over:

sudo cp -Tax /media/hd /media/ssd

Use the correct names for the hd and ssd mount points of course. Then you just need to edit the /etc/fstab on the ssd to point to the new fs UUID ( you can look it up with blkid ). Finally you need to install grub on the ssd.

2) Dealing with GRUB

a) Command line:

sudo -s
for f in sys dev proc ; do mount --bind /$f /media/ssd/$f ; done
chroot /media/ssd
grub-install /dev/ssd

Of course, use the correct device for /dev/ssd. The whole disk, not a partition number.

b) "Recommended repair" magic button in Boot-Repair:


sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair && boot-repair

enter image description here

Finally reboot and make sure your bios is set to boot from the SSD.

  • 12
    I'm posting this comment from my system running perfectly on the SSD. Thanks May 6, 2011 at 12:14
  • 1
    Just something I found doing this with a second PC: The live CD needs to be 64 bits if the OS you're moving is 64 bits too, or the chroot won't work. Aug 28, 2011 at 22:45
  • 4
    What does the chroot command do, and why is it necessary?
    – codeape
    Oct 20, 2011 at 12:26
  • 7
    I found the command should be sudo cp -ax --target-directory=/path/to/ssd /path/to/hdd/* or else it copies over the files but dumps it into a directory on the ssd instead..
    – Pwnna
    Aug 12, 2012 at 15:18
  • 3
    @Balthazar: When using chroot, the new root directory needs to be a complete enough environment that whatever programs/scripts you're going to run can act as if it's a normal root filesystem. Those mount commands drop the "sys", "dev", and "proc" filesystems (virtual filesystems with non-disk-backed files e.g. /dev/zero, which returns all zeros when read) into the right places so that they'll appear in the right place when inspected from within the chroot jail.
    – azernik
    Apr 14, 2013 at 20:51

Here is as good (for 2018) as easy how-to from 2013: http://www.sesser.eu/howtos/hdd2ssd.php by Markus Sesser. But you should read 1st comment here about --exclude "sys" - thanks to @em2er !

It describes migration without booting from live CD. It also respects system dirs and uses rsync, noatime, nodiratime. Just do not forget to omit discard option - it is implemented via cron since Ubuntu 14.04.

Short plan from article:

  1. partition and mount the SSD. I recommend single ext4 on gpt

  2. cleanup source HDD

  3. sync data (rsync)

  4. tune fstab. Also if you will keep HDD in system then I recommend move /home onto SSD while keep user data (~/Video, ~/Audio, etc.) on HDD

  5. install grub

  • 3
    Markus guide is still quite useful except rsync part: e.g. the option --exclude "sys" excludes all paths with sys like /usr/local/go/src/cmd/vendor/golang.org/x/sys/unix/str.go
    – em2er
    Jun 18, 2021 at 10:52

I was able to do this migration successfully thanks to @psusi's instructions, however I observed one "gotcha."

After installing Grub on the new SSD, it still wouldn't boot - it was looking for the ramdisk image using the UUID of my old OS drive, which I had removed. Using the --recheck option fixed this:

$ grub-install --recheck /dev/ssd

This encourages grub to re-scan the BIOS, identify the new drive, and presumably use its UUID when passing the "root=" parameter to the kernel.


Considering your HDD is /dev/sda and SSD is /dev/sdb and partitions are properly sized, you may use simple cp:

cp /dev/sdaX /dev/sdbY

Where X and Y are corresponding partition numbers.

However this method will copy 80GB of data and all sectors on your SSD will be marked as "occupied" initially.

  • Sound easy enough, but that last sentence doesn't mean much to me. Is it, or could it be, a problem? May 5, 2011 at 14:56
  • Well it might negatively impact your SSD speed (however with TRIM support it would recover later). You may read en.wikipedia.org/wiki/TRIM for more information. But, you should really go the route described in the other reply (copy files, not partitions). If you still decide to copy the whole partition, you need to perform grub-install/grup-update as well. May 6, 2011 at 7:41
  • 1
    I wouldn't recommend this approach, it will copy all the filesystem errors you may have on your old partition. The cp -ax approach is both quicker and safer. Nov 23, 2012 at 17:36

I tried to install Boot-Repair tool from instruction in the answer of this question on Ubuntu 20.04 (on installed version, not live) to check that everything will be fine on live version:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair && boot-repair

There was error:

Cannot add PPA: 'ppa:~yannubuntu/ubuntu/boot-repair'. ERROR: '~yannubuntu' user or team does not exist.

Instruction from here helped to me.

Below this instruction (How to install the Boot-Repair tool in an Ubuntu live disc):

sudo apt install software-properties-common; \
sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) universe"; \
sudo add-apt-repository -y ppa:yannubuntu/boot-repair; \
sudo apt-get update; \
sudo apt-get install -y boot-repair && boot-repair

When command:

sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) universe"

was being executed there was the following warning:

W: GPG error: http://ppa.launchpad.net/yannubuntu/boot-repair/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 32B18A1260D8DA0B E: The repository 'http://ppa.launchpad.net/yannubuntu/boot-repair/ubuntu focal InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

But it did not prevent installation of boot-repair. It was installed successfully.

You must log in to answer this question.

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