Debian system drive upgrade: copy filesystems from MBR partitions to GPT?

Question

My home server runs Debian Lenny, and I'm about to upgrade the system drive to a larger drive.

In the process, I want to take the opportunity to reorganize the partitions and resize them. For learning purposes, I'm planning to migrate from an MBR partition table to GPT.

Because of those two changes, I can't just run "dd if=/old/drive of=/new/drive" (well, not without lots more work afterwards). I could use the debootstrap process to get a fresh installation on the new system drive, but I used that technique during the last system upgrade and it's probably overkill for this.

Can I just copy the partitions from the old drive to the new?

• Will "dd if=/dev/hda1 of=/dev/hdb2" work, assuming /dev/hdb2 is larger than /dev/hda1? (If so, the filesystem can be resized to take advantage of the new larger partition, right?)

• Would parted (or gparted) be a better tool for copying the contents of the partitions?

Answer 1

Answers are: yes and yes. When you are copying smaller partition to larger GParted is basically doing the same thing: dd'ing old contents and launching resize2fs for the target partition. resize2fs requires some nasty sector computations so I'd recommend you to use (g)parted utilities which do it automatically, but it is of course possible with two mentioned commands. Also parteds do some verifications and sanity checks that won't allow you shoot yourself in the leg.

GPT migration has to do nothing with partition contents: partition table no matter is it GPT or MBR just instructs kernel how to position read/write window for partition device file; it does not affect contents of the partition at all.

Answer 2

Postmortem:

Things went mostly as expected, but there were a couple of hiccups that I should document. Naturally, all partition copying was done from a LiveCD (Xubuntu 9.04, since it was what I had lying around, but any recent LiveCD should do).

• Gparted refused to copy a partition on the old drive to an existing (empty) partition on the new drive. (parted might have worked, but refused because of some "incompatible" filesystem flag on my system partition.) Instead, I had to blow away the partition scheme and allow Gparted to create the partition as part of its copy operation.

• Grub2 was needed on the new drive (Grub1 doesn't understand GPT). This meant installing Grub2 on the new drive while in a chroot environment (similar to the chroot described in these intructions):

  1. While chroot'd into the new system partition, run apt-get install grub-pc to install Grub2 (chroot makes sure we get it from the Debian repositories instead of the LiveCD's Ubuntu repositories).

  2. The next step should be to run upgrade-from-grub-legacy to install the bootloader and configure a basic grub.cfg. But the Grub2 package in the official Debian Lenny repository (currently v1.96+20080724-16) installs a broken /etc/grub.d/20_memtest86+, and the upgrade script breaks while processing it. Edit that file thus:

     1. Change . /usr/lib/grub-mkconfig_lib to . /usr/lib/grub/update-grub_lib

     2. Change all instances of "linux16" to "linux". This is the Grub2 kernel directive -- this step isn't necessary to run the upgrade script, but it doesn't boot the Memtest86+ directive properly.

     3. Run upgrade-from-grub-legacy. It should now complete properly.

  3. Update any hard-coded mounts in /etc/fstab. Since partitions were copied and resized, their UUIDs should be the same. But swap partitions won't have the same UUID, so that'll need updating.

  4. Double-check everything, cross fingers, shut the computer down, disconnect the old system drive, reboot.