Upgraded harddrive with encrypted LVM

My HP laptop with 160GB harddrive was getting full and I wanted to upgrade it to a bigger one. Found that 2.5″ 500GB was relatively cheap so I bought one and detailed the procedure of upgrading with all data intact. I bought a 2.5″ USB-SATA chassis as well for the old drive to sit in. As I hit a few snags when doing this I thought it could be useful for others to read about.

I run Fedora 11 on this laptop and had three partitions (that’s slices for you in BSD-land):

  1. /boot, 200MB ext3
  2. OpenBSD slice
  3. Encrypted LVM PV with one Volume Group called Volumes with three Logical Volumes (Swap, Root and Home)

The whole LVM physical volume (PV from here on) was encrypted with LUKS. This is a bit of performance hit so I wanted to get it decrypted in the process.

I hit a few snags along the way so if you want to follow this read the whole thing beforehand if you do not also hit the same snags.

I started of by booting into a Fedora Live CD.

Snag 1: Swapping the drives before migration.

I wanted to see if the drive fit with HPs custom connector so I started of putting the new drive in the laptop and the old one in my USB chassis. As it turns out the SATA connectors seem to have standard placement on drives so that was not a problem. The custom connector was attached to the drive and the drive fit right in its bay. The snaggy bit about this is that the LVM system expected to find the PV in /dev/sda3 but that now became /dev/sdb3 when it was housed in USB. So when I created a PV on /dev/sda3 I could not migrate the volumes with LVM like I wanted (add /dev/sda3 to VG, remove /dev/sdb3 from VG and voila).
Keep the old drive in place until data has been migrated.

Snag 2: Different drives have different geometry

I then proceeded to just block copy the partition table like so

dd if=/dev/sdb of=/dev/sda bs=512 count=10

/dev/sda is the new 500GB and /dev/sdb is the old 160GB. This made sure that the boot sector and partition table was copied over. What I found was about 4MB of space between the partitions. So that was not the correct way to do it.

Create partitions as needed. Do not copy the partition table between disks with different geometry

So what I ended up doing was creating the partitions with the same block size in fdisk instead.

I then proceeded to copy the contents of /boot and OpenBSD with dd.

dd if=/dev/sdb1 of=/dev/sda1 bs=8388608
dd if=/dev/sdb2 of=/dev/sda2 bs=8388608

The big number is 8MB which was the size of a cylinder on my drive. Any number should do I suppose. I just like copying in large chunks.

Then it came to the LVM PV. What I did was to create a new partition (/dev/sda3) that filled the rest of the disk and set it to type 8e (Linux LVM). I then opened the encrypted pv

cryptsetup luksOpen /dev/sdb3 original-pv

and copied the whole thing over. No need for pvcreate and such.

dd if=/dev/mapper/original-pv of=/dev/sda3 bs=8388608

When done (took forever… or just 15 minutes but it seemed like forever) the PV have to be extended to the whole partition.

Snag 3: Remember to fix the bootloader, Luke!

After this I thought I was done but I was not. This is what I had to do to get the system back up.

To fix the boot loader I booted up with the Fedora install DVD and entered rescue mode. Chrooted to /mnt/sysimage and ran

install (hd0)

This will start grub and install the bootsector. If you have a boot partition like I do grub should understand that you are not talking about the disk and not partition and enter (hd0,0) after it has embedded itself in the boot sector.

Snag 4: The system will still ask for a password at bootup

When a new init ramdisk is created a prompt for password is inserted if mkinitrd finds it necessary. To fix this I booted with an older kernel, removed the newer one and installed the newer one again and rebooted into the new kernel.

Snag 5: Tidying up the LVM and filling the disk

I struggled with this a bit until I remembered how to do that. Simple enough

pvresize /dev/sda3

Snag 6: Cannot login as root via gdm

I then wanted to extend /home to the new space. This could not be done with /home mounted and I could not log in as root in GDM. I could do this with the lvm command line tools but I kinda like the system-config-lvm that Red Hat provides so I really wanted to login into a graphical root context. Fedora has prevented this with PAM. Simple enough. Comment out the following line in /etc/pam.d/gdm and /etc/pam.d/gdm-password

#auth required pam_succeed_if.so user != root quiet

I then killall gdm-binary and login as root. There I run system-config-lvm and extend Home. It then helps me with unmounting Home, extending Home volume, extending the filesystem (ext3) and finally mounting Home again.

Final words

Had I known what I know now I would have let the old drive stay as /dev/sda under the whole migration. But in the end I got there in time and now run my laptop with unencrypted data, free for any thief to steal. As I wrote in a tweet a few weeks ago. Stick to ext3. I know it’s tempting to go with ext4 now that they offer it in the default installation but when I wanted to resize Home it thought “Well, I’ll just format it to ext3 first so I know what I’m doing” and all data was gone. Luckily I made backups of my data just as you should.

Back up your data, kids and get of my lawn!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s