Changing Mailman Python Scripts for Virtual Host Support
JQuery Venetian Blinds Transition Effect
Symfony 2 Crash Course
Getting Set up with Ogre 3D on Ubuntu
Installing Xdebug for use with Eclipse or Netbeans on Linux
Using Multi-Byte Character Sets in PHP (Unicode, UTF-8, etc)

Moving Arch Linux to a new SSD with rsync

Thursday, 11 July 13, 11:20 am
So we all got shiny new SSDs at work recently, and I was keen to get a new Arch installation up and running from the lovely new silicon. A bit-wise clone of the old disk's contents wouldn't work for me, as that was still formatted using ext3, and I wanted to use this opportunity to switch to ext4.

My initial plan was to just install a fresh copy of Arch from a USB, and it was as I was doing this that I realised I should be able to do the exact same procedure but from my existing Arch installation. After all, the Arch install process simply boots you into a minimal Arch on your USB drive (or CD-ROM/DVD), and then installs onto the target drive with the help of chroot. So, from my old Arch system, I tried the standard install procedure of running the pacstrap script. This script was not available however, and I couldn't immediately find it in the repos.

As I was searching online for suggestions, I came across this page in the wiki, which describes how to use rsync to make backups of your complete Arch system, and it has a section headed Boot requirements which explains how you can make these backups bootable.

I adapted this process to copy my current Arch install over to the new SSD. This method works very smoothly, with the trickiest part being reconfiguring the boot loader. Here's the steps I followed:
  1. From the current full Arch install, mount the SSD:
    sudo mkdir /mnt/newarch sudo mount /dev/sdb1 /mnt/newarch
  2. Run rsync (if you have any large folders you don't want to include, add them to the list of excluded system folders shown here):
    sudo rsync -aAXv /* /mnt/newarch --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/var/tmp/*,/run/*,/mnt/*,/media/*,/lost+found}
  3. Edit /etc/fstab on the new drive. Here's how mine looks on the HDD (and therefore how the one on the SSD was originally):
    tmpfs /tmp tmpfs nodev,nosuid 0 0 UUID=079b9ff7-45ed-b0e9-1587-76e02c968d5b swap swap defaults 0 0 UUID=185d0dce-46f6-a03a-a7c2-181b7293d38e /boot ext2 defaults 0 0 UUID=59afd210-4ed8-c8c8-a65e-a40274495df3 / ext3 defaults 1 0 UUID=79be5820-95a4-e4cc-43a2-6c03128dd508 /mnt/newarch ext4 defaults 1 0
    As you can see, I used separate partitions for boot and swap when I set up the HDD, but there's no performance benefit to this, and it can be a problem should you ever wish to change the space available for either. Thus I've just got the one partition on the new SSD:
    tmpfs /tmp tmpfs nodev,nosuid 0 0 UUID=79be5820-e4cc-43a2-95a4-6c03128dd508 / ext4 defaults 1 0 UUID=59afd210-4ed8-c8c8-a65e-a40274495df3 /mnt/hdd ext3 defaults 1 0
    I've also added a mount for the old drive, as I'm keeping it in the system as a data drive. It doesn't matter whether you choose to use disk UUIDs or by label (eg /dev/sdb1): the main advantage of UUIDs is that they won't conflict when the drive is physically moved, for instance into a new system. To find your UUIDs, just run this command:
    ls -l /dev/disk/by-uuid
    We now have two copies of Linux on the two drives. The problem left to sort out is booting. In my case, there is no boot loader on the SSD, because it was in its own partition on the HDD which hasn't been copied. Even if you didn't have it in its own partition but in a boot directory on the same partition as Linux, you'll still need to follow the same steps below so that it boots from the new drive.

  4. If you're using Grub, make sure you have os-prober installed at this point:
    sudo pacman -S os-prober
    You can skip this step if you're not going to keep the HDD in the system as a backup bootable Linux.

  5. To reinstall the bootloader, we're going to chroot into the new filesystem and make our changes there. chroot simply allows you to set any directory to temporarily act like the filesystem root, and you've probably already used this when first installing Arch. We're going to chroot to the mountpoint of our new Arch like so:
    sudo su cd /mnt/newarch mount -t proc proc proc/ mount --rbind /sys sys/ mount --rbind /dev dev/ chroot /mnt/newarch /bin/bash
    You should now see your prompt change to show that we're in the root directory - although really we're still in /mnt/newarch and it just appears to be the root. Now we can reinstall the bootloader so it recognises the SSD. For Grub, run the following (change sdX to the disk label of your SSD):
    grub-install --target=i386-pc --recheck --debug --boot-directory=/boot /dev/sdX grub-mkconfig -o /boot/grub/grub.cfg
    The new SSD should now be fully bootable and if you have installed os-prober, the Grub menu should have an option for booting from the old HDD.

  6. Type exit to leave the chroot and return to the old HDD filesystem. If you're going to want the HDD to still be bootable, run grub-mkconfig again and it will now pick up the boot on the SSD and add a corresponding menu entry.

If all's gone well, you should now be able to boot into Linux on your new SSD. You'll need to reconfigure your BIOS boot order so that it boots from the SSD, although whichever disk you boot from should offer the choice of booting from Linux on either the SSD or HDD.


11:00 pm, Saturday, 14 March 15

hello!, just a little comment here, in the step 5, after executing the next command:
grub-mkconfig -o /boot/grub/grub.cfg
in my computer took a really long time, several minutes, I dont know why, but it involved
a connection refused to lvm.socket or something like that, then it changed to manual mode,
thats when apparently was stalled, but after a few minutes, it completed, and show some os-probe
access denied errors, but os-prober is actually installed, but it completed with no other problems
but it took a lot of cpu power, but even with all that. The installation/clone process was a success!

thanks for your guide!

Ameer Elsherif

5:00 pm, Thursday, 24 August 17

Really really helpful
Thank you


11:26 pm, Tuesday, 5 September 17

Thank you, helped me to move my gpt installation (also had to mount /boot/efi in chroot before installing grub and use x86_64-efi target)


11:35 pm, Wednesday, 1 November 17

Thanks for this!!

Skip step 4 and 6 if youre concern only about migrating to a new drive.
2  Leave Comment

/xkcd/ Self-Driving Issues

About This Page