Imaging
PATA  ~>  SATA

Sometimes it's necessary to move a server onto new hardware (often because the old hardware was "recycled" and is now failing). Often the software has accumulated a substantial number of undocumented configuration changes over the years, so just reinstalling all the software from scratch isn't a good option. The usual method in this case is to use "imaging" (also called "cloning") software to dump the whole hard drive from the old system and restore an exact copy of it onto the new system. The Linux "found new hardware" mechanism will then automatically adjust for most hardware differences.

But transferring software from an older system with parallel data disk interfaces ("PATA") to a newer system with serial data disk interfaces ("SATA") often doesn't quite work. Fortunately the imaging/cloning procedure can usually be "tweaked" so it will work even with the PATA=>SATA difference. Here's how we successfully tweaked the imaging/cloning procedure in a particular case; this tweak may work for you too. (Of course other methods may also work.)

(Parallel disk interfaces use the wide gray ribbon cables many people remember. As computers got faster and faster requiring disks to be faster too, it became harder and harder to keep the signals and clocks on all those wires together in lockstep. Eventually it got to the point where it was actually easier to have just one signal wire loop running extremely fast. Thus newer disks use the different serial interface, with a cable that's less than half an inch wide. Such fast components aren't trivial, but there's only one copy of them, and no synchronization is required. The net difference is that SATA is both simpler and cheaper than PATA.)

Note this method may not work as-is for you. It's specific to Linux; it's probably even specific to a particular version and perhaps even to a particular distribution. I did it on RedHat ES 4.2; it may need to be "translated" to work on other versions and distributions. It will almost certainly not work for software RAID drives, and it assumes the existing system is running the exact same kernel version you want to image/clone. And there are several slightly different versions of SATA, some more equal than others.

Why PATA=>SATA Fails

For a Linux system there are typically two problems with going from PATA to SATA disks:

1. The boot sequence (typically using "GRUB") doesn't have the needed driver for the SATA hardware.
2. All the bootup disk references (mostly in /etc/fstab) incorrectly specify the type of the disk as PATA.

Other Imaging Difficulties

Often imaging/cloning software (Acronis, Ghost, etc.) fails on brand new hardware. This happens because the imaging/cloning software doesn't contain drivers for brand new peripherals (network interfaces, DVD burners, etc.). This confounds the problem of PATA=>SATA imaging/cloning, but isn't actually related and has a different solution.

Usually the solution to imaging/cloning problems other than PATA=>SATA is simply to use the very latest version of the imaging/cloning software. If the first copy of your model of new hardware came off the assembly line at least six months ago, and if you're using the very latest version of your chosen imaging/cloning software, it will probably work.

Providing SATA Drivers To The Bootup Sequence

Generally Linux booting is a multi-multi stage procedure: the master boot record on the disk, one or more stages of the boot program, a pre-kernel halfway between the boot program and the full kernel, and finally the full Linux kernel. The early stages almost always all work regardless of hardware type. And the final full Linux kernel usually has loadable device drivers for every conceivable type of hardware. Commonly the next-to-last stage presents a problem though. It tries to be as small as possible, so it typically contains drivers only for your specific hardware, not including the SATA driver. This stage must be regenerated to contain both PATA and SATA drivers.

The next to last stage in the bootup sequence must be regenerated before you dump the image from the old system. This way drivers for both kinds of disks are already on the image, ready to be used whenever necessary.

So on the old system before you dump its image, follow these steps to regenerate the bootup pre-kernel.

1. Be sure your system has booted to its default version. To say the same thing another way, be sure your system has booted the way it would if its boot sequence were unattended.
2. Make a backup of the current pre-kernel. This file is probably in the /boot directory and probably has a name beginning initrd... and containing the version name of the kernel. Figure out which file is currently used by your default bootup, and make a copy of it with a name you'll recognize. We're going to overwrite the original of this file in a future step, and you should be able to fall back if something goes wrong.
3. Edit file /etc/modprobe.conf to add this line
      alias scsi_hostadapter ata_piix
   This tells the program that uses this file to include the driver for SATA disks even if there don't appear to be any SATA disks in the current hardware.
    This is correct for a RedHat system. On some other distributions edit the file /etc/modinfo.conf instead. Many systems rewrite this file every time they boot to correspond exactly to the actual current hardware configuration, so do not reboot until after the next step.
4. Execute the program that creates pre-kernels, by typing a command line something like this:
      /sbin/mkinitrd  -k  /boot/initrd-`uname -r`.img  `uname -r`
   (Some earlier versions of this document may have given the not quite correct command /sbin/mkinitrd /boot/initrd-`uname -s`.img `uname -s`.) The -k allows overwriting of the existing pre-kernel (you did make a backup, didn't you?). The uname -r constructs provide the long and abstruse kernel version name without requiring a lot of laborious, error-prone typing; it relies on the current version being the same as the default version.
    Note we're using the version identifier of the current running kernel both as part of the filename of the pre-kernel and as an argument to the program that generates it, per the usual Linux naming conventions. The command above is exactly right for a RedHat ES 4.2 system; for other distributions with slightly different naming conventions you will probably need to modify the filename and version name in this command a little bit.
5. Test that the old system still boots up with the regenerated pre-kernel. There's no point in dumping an image/clone of a system that doesn't work.

Now Image As Usual

Now that the system is prepared, dump an image of it as usual. Then restore a copy of that image onto the new hardware as usual. (The image is now on the new system but it won't boot yet.)

Boot Into Maintenance Mode

In Linux there's a maintenance mode for dealing with booting problems. In this mode the root partition is already available, but you may need to enter explicit mount commands to access other partitions. This mode is sometimes called "single user mode", but it's not the same as the mode you'd get to with init S. To enter it:

1. Tell the hardware to boot.
2. When GRUB presents a list of kernel versions and provides the opportunity to interrupt, quickly press e to allow editing of the boot line.
3. Add the word single. Then continue.
4. If asked, enter the root password.
5. Soon you'll be presented with a shell prompt.

Modify The New /etc/fstab

The Linux kernel refers to SATA drives the same way it does to SCSI drives, so you'll need to change each /dev/hdxn to /dev/sdxn. The boot program GRUB, on the other hand, does not use different nomenclature for the different drive types; (hd0,0) for PATA will still be (hd0,0) for SATA.

Most likely all the device nomenclature is confined to just one or two files, /etc/fstab and possibly also /etc/smartd.conf. These files are used during normal bootup, which will fail until /etc/fstab is modified. This seems to be a catch-22 situation: you can't boot until the file is edited, but you can't edit the file until you can boot. Fortunately simple Linux emergency procedures can handle this situation. Enter maintenance mode (as described above), then:

1. Make the root partition writable (rather than just read-only). You'll probably find that although you have a shell prompt and can see the entire root partition, you can't change anything. So execute something like
      mount -o remount rw /dev/sda1
   (use the new SATA nomenclature for the drive).
2. Use your favorite text editor to modify /etc/fstab. Change each hard disk reference /dev/hdxn to /dev/sdxn.
3. Also replace any LABEL=xyz parameters with references to actual disk partitions (/dev/hdxn), of course using the new nomenclature. Even though the LABEL=xyz parameters prevent errors and are convenient, they will likely no longer work on newly imaged/cloned systems (especially when moving from PATA to SATA).

Modify The New /etc/smartd.conf

Some systems are also configured to programmatically monitor their hard drives. In these cases the specifications to the monitoring program will also need to be modified. Those specifications will cause error messages but won't completely prevent bootup, so they could be edited later. But since we're here, it seems the easiest thing is to edit them right now.

Assuming you've already booted single user and can already edit files as above, continue by editing /etc/smartd.conf. Use your favorite text editor to change each hard disk reference from /dev/hdxn to /dev/sdxn.

Reboot

Reboot, typically with the command shutdown -r now. The system should boot all the way up normally without any manual intervention.

Emergency Alternative

You may be able to boot a PATA image on SATA hardware even if the pre-kernel (initrd) does not include a SATA driver. If someone already dumped the image without first regenerating the pre-kernel, try this. Interrupt GRUB where it allows you to edit the boot command, and add the two parameters linux all-generic-ide. This will allow you both to get past the first problem and to go about fixing the second problem. (But a similar kluge will be repeated every time the system boots and you will probably never get maximum performance from the SATA drives.)

Edit /etc/fstab (and /etc/smartd.conf) as above.

To minimize the difficulty of repeating bootup unattended, also edit /boot/grub/grub.conf. (You may need to issue an additional mount command to access the files in the /boot partition.) To each one of the boot command lines add the single parameter all-generic-ide.

Finally, reboot the system.