Andre's Blog
Perfection is when there is nothing left to take away
Moving Linux installation to new hardware

I finally decided to abandon the old 700 MHz box I was using as a CVS repository and to do Fedora builds of Stone Steps Webalizer. The replacement machine was not new, but I just cannot complain about a 2.8GHz CPU and extra storage! Before this weekend, I never restored a Linux backup onto new hardware and I learned a thing or two about Linux in the past couple of days.

The original disk started to fail from time to time, causing "short read" messages appearing once in a while when bad blocks were being read or written. The disk had three partitions - the boot (sda1), swap (sda2) and the root (sda3). I booted the old machine using the Rescue CD, plugged in an external eSATA drive (sdb) and backed up the boot and root partitions:

mkdir /mnt/backup
mount /dev/sdb /mnt/backup
dump -0 -f /mnt/backup/boot-20081214.dump /dev/sda1
dump -0 -f /mnt/backup/root-20081214.dump /dev/sda3

Then I booted the new machine using the same Rescue CD and skipped network installation and mounting the existing installation at sysimage.

Using fdisk I created three partitions on the new drive, similar to the layout of the original drive, but with larger swap partition to account for more memory. Once this was done, I created two ext2 file systems and labeled them, so I don't have to use device names, which may change when removable drives are attached:

make2fs -c /dev/sda1
make2fs -c /dev/sda3
e2label /dev/sda1 /boot
e2label /dev/sda3 /

The -c option checks the drive for bad blocks, which may cause make2fs take a while to complete. Then I initialized and labeled the swap partition using mkswap:

mkswap -c -L /swap /dev/sda2

Now it was time to restore backups. I plugged in the external eSATA drive, mounted all file systems:

mkdir /mnt/boot
mkdir /mnt/root
mkdir /mnt/backup

mount /dev/sdb /mnt/backup
mount /dev/sda1 /mnt/boot
mount /dev/sda3 /mnt/root

, and used restore to recover the data:

cd /mnt/boot
restore -r -u -f /mnt/backup/boot-20081214.dump
cd /mnt/root
restore -r -u -f /mnt/backup/root-20081214.dump

Now I had to reconfigure grub to find the new boot files. The first sector of the first cylinder of the active disk contains the partition table and the bootstrap code. All that is in mere 512 bytes, so the code has to be very tight. Different loaders approach this problem by either placing files in a well-known location or by patching up boot components after they are installed.

For example, DOS used to read and execute code in the first sector of the active partition, which in turn looked for two files at the very beginning of the root directory. GRUB, on the other hand, patches up code, so GRUB binaries can be located by the tiny code in the first sectors of the disk and the active partition, which are called stage1 and stage2 in GRUB documentation. In addition to the two sectors, GRUB makes use of the first 63 sectors of the first cylinder, which are not used in most partitioning schemes. This additional code is called stage1.5.

The recommended way to install GRUB is use grub-install. However, this utility never worked for me - it kept trying to find grub under the boot sub-directory of whatever directory I specified as root, so I dropped into the grub shell instead (just type grub on the command line) and completed the configuration. In the grub shell, I ran these commands:

root (hd0,0)
setup (hd0)

, which indicates that GRUB should use the first partition (0) of the first disk (hd0) as a root. This partition maps to the sda1 device, which is the boot partition. Note that the setup command refers to the entire drive, not just a partition.

At this point I was able to boot successfully, but ran into a cryptic message during the startup sequence, saying that the file system /dev/root cannot be mounted. After some searching and thinking I realized that the problem was that the new machine had different hardware and the configuration I restored from the backup simply was not good anymore.

I found a bunch of forum posts describing a similar problem, but none specifically advised anything usable. It took me a while to figure out how to deal with this one. Eventually, trying to run various tools like depmod and modprobe, I realized that I'm missing various system directories, such as /sys, /proc, etc.

Fortunately, the Rescue CD came in handy for this - I booted off the Rescue CD again, activated the network and when the installer asked me whether I want to mount the existing system or not, I did so and I had all system directories mounted along with all file systems. All I had to do then was to run these commands, so I can capture the configuration detected by the installer:

chroot /mnt/sysimage
depmod -a
modprobe --show-depends --set-version= 
mkinitrd /boot/initrd-

That was it - the new hardware found by the installer was properly configured and all I had was to exit chroot, unmount all file systems and reboot the machine.