Clones

I spent a little time this weekend playing with cloning of hard drives. One of my computers has been saddled with a little 80 Gb drive from day 1 even as the replacement 1 Tb drive has sat in its unopened package for several months. Like many people, the holidays are a time where I think about dotting some ‘i’s, crossing some ‘t’s etc, and replacing that drive has been a goal for some time.

I had played in a slightly messy way with adding a drive to one of my laptops using a cloned drive approach. With that one, I used dd to clone the drive but then realized that doing so gave the hardware an identical name to the existing one. It seems obvious now, but I didn’t realize that the intent behind replacing drives and cloning is typically to actually ‘replace’ them, not have them run concurrently. So I went down the rabbit hole of how to get a new UUID, editing grub.cfg files, etc. and eventually life worked. I documented much of it but I’m sure I didn’t get it all down. So I knew that this time, I’d probably have a learning curve again (and I wanted to try a different approach.

I ended up doing the following:

• clone the current hard drive to a bootable USB drive.
• clone the current hard drive to the new 1 Tb drive.

The idea of saving to a bootable USB drive was intriguing to me, even if the practical benefit seems limited. The guide for this was a page in the Debian wiki meant to be on the subject of partclone – an app that allows one to clone single partitions. In short, the process was as follows:

1. On the legacy system, use gparted to create a single bootable partition on a USB drive. One ‘gotcha’ here was that you start by creating a partition table for the drive. There are multiple partition table types out there and I chose BSD (as in BSD Linux) since this sounded closest to a Linux-happy system. That turned out to be a bad choice. You want to use msdos. This isn’t the first time I’ve seen it, but it’s strange to have to rely on something linked to Microsoft to facilitate a Linux operation. Per the recommendation on the Wiki, the filetype for the partition was ext-2. I used a 29 Gb drive.
2. Mount the usb drive.
3. Run blkid to identify the UUID values for everyone, notably for the USB drive. The UUID is used to modify the subsequent fstab.
4. Use dd to create swap space (1 Gb from /dev/zero)
5. Use rsync to copy everything from / on the legacy system to the USB drive (at its mount point). Options ‘auv’ included. (archive, update, verbose)
   1. The rsync was done excluding the contents of many of the legacy system directories (not the directories themselves however):
      1. /mnt/*
      2. /media/*
      3. /sys/*
      4. /tmp/*
      5. /etc/fstab
      6. /proc/*
      7. /lost+found/*
      8. /dev/*
      9. /home/user/[a-zA-Z0-9]*
   2. Edit the new /etc/fstab to reflect the UUID of /
   3. update-grub
   4. grub-install –recheck –root-directory=usb_mountpoint /dev/sdx (where sdx is the usb device)

Now I did run into some problems, notably when I attempted to have the USB drive run at the same time as the hard drive. Also learned of a suprising amount of flexibility in the current system regarding who to use to boot. As usual, you can specify the boot priority in the BIOS (F2). On boot, you can also press F12 to directly intervene to get to who you want to boot, overriding what is the BIOS default. Additionally, grub.cfg, created when you you run update-grub, is aware of the boot capabilities of all attached hardware. Thus, when you boot from the USB drive, it is still aware of the boot entries for the hard drive. In retrospect, I think the old LILO used to do this to.

When I booted from the USB stick, it still ended up mounting the HD. It looked like update-grub did not push the UUID to all relevant places for the menu items related to the USB. I manually edited and then sort of worked but kept getting an fsck error even though I had set the last entry of fstab to 0 for the drive – which should theoretically keep it from running.

Eventually, I came across some postings that got me to the answer: there’s something called update_initramfs which needs to be run. I could do this, because fsck failure came at a stage after the disk is mounted but before the X-system is fully up. Thus, I could not log in at the graphical interface but I could open a text console. There, I was able to run update_initramfs and, voila!, I could run happily. I also re-ran update-grub, but I’m not sure when. It’s the one nagging thing that bugs me – did I run that correctly? I should not have had to have edited gsub.cfg. Maybe if I had run the update_initramfs earlier? Well, something for later. For now, yes, I have my system fully available and bootable from that usb drive.

Stage 2: move to larger drive.

Here, I went the clonezilla route which seems to have a lot of fans. I was troubled by the poor quality of their website and the stilted quality of their documentation, both of which felt amateurish. But I did the the following:

1. Create a ‘live’ clonezilla usb drive. The clonezilla website has directions for this -you need to use gparted to create a Fat-32 partition on the drive and make it bootable. I don’t recall if I ran a dedicated clonezilla app to then copy clonezilla to the drive or not.
2. Boot from the clonezilla usb and run the cloning program. It has lots of options so you need to track with the website on the navigation (clonezilla supports lots of things including restoration of backups). The first menu item (and the easiest to overlook) was to go directly to the menu item that looks like ‘other’ or something similarly vague. After that, the options are more intuitive.
3. The execution of the cloning process is accompanied by a few questions which are difficult to read (yellow text on white background). I needed to copy the question and copy to a local emacs session just to make sure I was reading what they were asking before responding.
4. Once it started, the cloning process took around 10 minutes. I rebooted and resized the partitions on the new drive using gparted with the legacy drive. Powered down, remove the original drive, and reboot. All looks good!

Because no story can end happily, here’s what happened next. I went to replace the physical spot inside my machine containing the 80 Gb drive with the new one. I removed the existing one. I had earlier noted that the data connector to the legacy drive was weird in that the pins were ‘free-standing’ like real pins rather than backed by a plastic support (similar to USB connectors) and in fact had seen that one or two pins were bent but was able to straighten them out by hand. Now, the SATA cable did not fit the new hard drive! I thought there was some shift in SATA design and maybe this was just old, but I eventually figured out was: the original drive did have a platic backing but this had broken off and was stuck inside the cable side. That also explained the bent HD pins. So, I need a new SATA cable (the one I used for the new drive throughout is a 6″ temporary, not suitable to sit inside the box after I close it up). No hurry for that though and I think things are okay.