Intro
Moving your current OS setup to a new machine can occur because of many reasons. The most common is the need for a more power system, or upgrading to a commercial-grade server. It's usually best to start with a fresh OS install. However, due to time constraints and heavy modifications of the OS and it's configuration files, you may opt to transfer the entire file system to the new machine, rather than doing a fresh install and customizing the system all over again.

The biggest issues is to get the system to detect new hardware. Often times this can mean new sound cards, different video cards, additional devices (such as USB), and often a SCSI subsystem.

In the example below we migrate data from a generic Intel server running with an IDE subsystem. Our new setup will be a Dell PowerEdge 1750 without RAID.

This can be a complex operation, and it is only recommended for persons with a good bit of Linux experience. This document serves primarily as a check-list.

Packaging up the old file system.
The first step is to package your files (entire OS) for migration to the new machine. We use the built-in tar command to put all data in a file called archive.tar.

tar --atime-preserve -cf archive.tar <filelist>

Our <filelist> usually consists of the usual suspects:
/aquota.user /bin /boot /dev /etc /home /initrd /lib /misc /opt /root /sbin /tftpboot /tmp /usr /var

We recommend avoiding the following files in the archive for various reasons:
/proc /mnt /floppy /cdrom

Drive Preparation
On many commercial systems you'll want to use included drive-preparation software before installing your new drive. For instance, a Dell will have "Open Manage" software with it for formatting the drive and preparing it for use. Failure to use this software can sometimes cause Linux to refuse to use a drive. For instance, it may be able to be mounted, but can cause various messages such as non-BIOS drive warnings.

File Transfer
Next you will have to transfer the tar file to the new system (destination server). We typically have multiple drives in the destination system. One drive has Red Hat Linux installed to give us something to work with (we call this the workdisk). The other drive is an empty drive (our install drive) that will be our new main drive for the server.

Transferring the data to the new system can be done via FTP if the file is less than 2.1 gigs. Often times FTP can have trouble above this point. In this case we'd recommend a temporary NFS mount or other hardware-based solutions.

We'll save the archive.tar file in /tmp/ on the workdisk.

Partitioning
While running off the workdisk, we'll want to partition the install drive. We use the fdisk command. At it's most basic level, you'll probably want a boot partition in the beginning of the disk, a swap partition, and a root partition. Remember to set the swap partition to "Type 82 Linux Swap". In the case of a commercial server, you'll most likely have a partition that exists called "Dell Utility" or in the case of laptops a partition that stores the hibernation data. Be sure to leave this partition as it is.

Formatting
Next we'll have to format the partition we added/created. Again, it's important to leave any system partitions (such as Dell Utility) the way they are.

Assume your install drive is sdb, and the partition map looks like the following:
Device Boot Start End Blocks Id System
/dev/sdb1 1 7 56196 de Dell Utility
/dev/sdb2 * 8 73 530145 83 Linux
/dev/sdb3 74 204 1052257+ 82 Linux swap
/dev/sdb4 205 4427 33921247+ 83 Linux

In the above situation we'd want to make a journaled file system on partitions sdb2 (our /boot partition) and sdb4 (our / root file system). We'd want to format our swap drive as swap.

We'd type the following as root:
mke2fs -j /dev/sdb2
mke2fs -j /dev/sdb4
mkswap /dev/sdb3

Disk Labeling
After disk labels are applied, it is important to make sure you do not boot the system with both drives at the same time again. This can cause the Linux to become confused when there are multiple partitions on multiple drives with the same label. We want sdb2 to be our /boot and sdb4 to be our / root. So we type the following:
e2label /dev/sdb2 /boot
e2label /dev/sdb4 /

Unpacking
After transferring the file to the new system, on our workdisk we'll need to unpack it. This means we need to mount both sdb2 and sdb4. Assuming that sdb4 is our root partition and is mounted under /mnt/sdb4, we'd type the following:
mkdir /mnt/sdb4
mount /dev/sdb4 /mnt/sdb4
cd /mnt/sdb4
tar --same-owner --atime-preserve -xf /tmp/archive.tar

Moving Boot
We'll also need to move boot files to the appropriate partition. In our case we made /dev/sdb2 our boot partition.
mkdir /mnt/sdb2
mount /dev/sdb2 /mnt/sdb2
mv /mnt/sdb4/boot/* /mnt/sdb2/

Creating Proc
The new system will need a /proc directory to mount to. We'll create the /proc directory:
mkdir /mnt/sdb4/proc/

GRUB File Modifications
We'll also need to check that our grub files point to the proper locations. For instance we might see something like the following when we look at the grub.conf file:
title Red Hat Enterprise Linux ES (2.4.21-15.0.3.EL)
root (hd0,0)
kernel /vmlinuz-2.4.21-15.0.3.EL ro root=LABEL=/
initrd /initrd-2.4.21-15.0.3.EL.img

Notice the line root(hd0,0). This means the grub root (our boot partition) is drive 0 partition 0. (This correlates to /dev/hda1 or /dev/sda1 depending on your drive setup.) Yes, this gets a bit confusing! Partitions in Linux start at 1 for the first partition. However GRUB starts with the first partition being 0.

Our new boot partition (GRUB's root) is /dev/sdb2. So we'd do the following:
nano -w /mnt/sdb2/grub/grub.conf

Modify the root(hd0,0) line to show the new root:
root (hd0,1)

fstab File Modifications
While we're modifying files, we'll need to check how drives are mounted. Since file system labels are used for / and /boot, we should be okay there. But we might need to change the fstab to show a new location for our swap space.
nano -w /mnt/sdb4/etc/fstab

We might see a line like the following:
/dev/hda2 swap swap defaults 0 0

However, now we're using a SCSI drive (sda rather than hda) and the swap partition is now on /dev/sda3, rather than /dev/hda2. So we'll change the line to read:
/dev/sda3 swap swap defaults 0 0

Booting
Next we'll shutdown the system, remove our workdisk, and solely use the install disk as our primary drive. Also insert the Red Hat Linux install CD. At the prompt type:
linux rescue

At this time the system should boot off CD and load the operating system from the new drive under /mnt/sysimage. We'll type:
chroot /mnt/sysimage

We'll want to install the boot loader on the new drive. (The new drive isn't able to boot since there is nothing on it's boot block, hence why we booted via CD in rescue mood.) GRUB install usually detects the new drive if we use the (hd0) parameter. So we'll type:
grub-install (hd0)

New Hardware
Since your new system probably has new hardware, we'll need to detect that. The kudzu utility detects hardware. Be sure to backup your /etc/sysconfig/network-scripts/eth[x] files, as they may be overwritten if a new Ethernet chip is detected. We'll type:
kudzu

Init RAM Disk
Finally, to support our new hardware, we'll need a new RAM disk during bootup. Failure to create a new RAM disk can cause the kernel to not recognize important devices (such as the SCSI system!) and therefore the kernel may panic. Error messages such as the following can indicate that the SCSI driver isn't loaded, and the drives aren't being read by the kernel:
VFS: Cannot open root device "LABEL=/" or 00:00
Please append a correct "root=" boot option
Kernel panic: Unable to mount root fs on 00:00

To keep this from happening we'll create an initrd. To do this you'll have to determine which kernel you'll be booting into. Then append the appropriate parameters to the mkinitrd command. For example if I look in the /etc/grub.conf file, or type "ls /boot", I'll see I have the following kernel in use:
vmlinuz-2.4.21-20.EL

In this case I'd create the appropriate RAM disk by typing the following:
mv /boot/initrd-2.4.21-20.EL.img /tmp/
mkinitrd /boot/initrd-2.4.21-20.EL.img 2.4.21-20.EL

Some common errors that you may run into are failure to create the image because you didn't move or delete the old one. Also a message such as "/lib/modules/2.4.21-20.EL is not a directory" indicates that you do not have the kernel installed that you specified, or that you may have made a typo when specifying the kernel version.

If all goes well you should be able to type the shutdown command and boot up to your old operating system on your new machine.

Related Topics & Information None at this time.