Technical Aside: cloning a debian installation

In addition to my everyday workstation, I maintain a separate workstation in our lab area specifically devoted to running image processing software (CellProfiler and the associated CellProfiler Analyst, which I’ve already blogged about). Today I noticed that one of the disks in this machine was in danger of imminent failure (Debian is so vigilant!), and sadly it stored both the OS and lots of important data. Bummer.

Happily we had an unused disk, sourced from an older workstation, which was perfectly good. Why not just clone the install from the failing disk to the functioning disk? Nothing to it right? Well, kind of. There were some snags that I had to iron out which I’ll document here. With an install/rescue Unbuntu disk in hand, I was able to accomplish the following:

  1. Format the replacement to match the partition layout of the failing disk. I took this opportunity to update to ext4 for all non-swap partitions.
  2. Use `su rsync -av ` to copy from one disk to the other. Do not leave tailing ‘/’ characters on your directories, they will flatten out in the destination. The -a option avoids many pitfalls in the data transfer process by preserving permissions, groups, ownership, everything.
  3. Use the Ubuntu Boot-Repair tool to perform a reconfiguration of /boot/grub/grub.cfg. This avoids the mess of ensuring you do chroot properly, mount /dev properly, resolve all permission issues, and so on. You can find it here. The latest version of Boot-Repair (pulled from the repository, check the page) requires both the pastebinit and gawk packages, but to get the former you must enable the ‘universe’ repository in your software sources system configuration. After installing both of those, Boot-Repair did a good job of configuring GRUB2 so that I could boot from the new drive.

However, after booting from the new drive, I got a complaint that debian could not find any partitions to mount. This was because Boot-Repair does not edit /etc/fstab, which must contain the proper UUIDs of the new drive partitions. This is a quick fix:

  1. From a root prompt, execute ‘blkid’, and note the UUID and partition types of all disks.
  2. Execute ‘nano /etc/fstab’. Since this installation is a clone, the structure remains the same, only the UUID and file system types need correcting.
Advertisements