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.
For a Linux system there are typically two problems with going from PATA to SATA disks:
/etc/fstab) incorrectly specify the type of the disk as PATA.
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.
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.
/bootdirectory 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.
/etc/modprobe.confto add this line
alias scsi_hostadapter ata_piix
/etc/modinfo.confinstead. 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.
/sbin/mkinitrd -k /boot/initrd-`uname -r`.img `uname -r`
/sbin/mkinitrd /boot/initrd-`uname -s`.img `uname -s`.) The
-kallows overwriting of the existing pre-kernel (you did make a backup, didn't you?). The
uname -rconstructs 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.
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.)
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
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
To enter it:
eto allow editing of the boot line.
single. Then continue.
The Linux kernel refers to SATA drives the same way it does to SCSI drives,
so you'll need to change each
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
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:
mount -o remount rw /dev/sda1
/etc/fstab. Change each hard disk reference
LABEL=xyzparameters with references to actual disk partitions (
/dev/hdxn), of course using the new nomenclature. Even though the
LABEL=xyzparameters prevent errors and are convenient, they will likely no longer work on newly imaged/cloned systems (especially when moving from PATA to SATA).
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
Use your favorite text editor to change each hard disk reference
Reboot, typically with the command
shutdown -r now.
The system should boot all the way up normally without any manual intervention.
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,
Interrupt GRUB where it allows you to edit the boot command, and add the two parameters
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.)
/etc/smartd.conf) as above.
To minimize the difficulty of repeating bootup unattended,
(You may need to issue an additional
to access the files in the
To each one of the boot command lines
add the single parameter
Finally, reboot the system.