Transferring to New Hardware With a Supertar

Migrating a SCSI-Based SCO OSR5 System to IDE Hard Drives

When you upgrade to a newer server, the most tempting change is to swap a set of old SCSI drives for a fast, inexpensive IDE array. The idea is simple: the new machine comes with a high‑speed IDE controller, and you can install a 1 TB or larger drive that costs less than a comparable SCSI disk. But the reality of moving a live SCO OSR5 installation can be a little more complex than the hardware alone suggests.

First, remember that the recovery media you’ll use for the Supertar backup contains a kernel that expects to see the same kind of disk it was built for. In most cases, that kernel will be tuned for SCSI, because the original system was SCSI‑only. When you boot the recovery disc on a machine that only knows IDE, the loader will try to treat the IDE drive as if it were a SCSI device. The boot prompt may look something like this:

At this point you can supply a boot string that tells the kernel which hardware to talk to. For an IDE controller that appears as the first IDE host bus adapter (wd0) and uses the first IDE disk (wd(0,0,0,0)), the boot string would be:

Typing that line into the prompt overrides the kernel’s default assumption that it will find SCSI disks. The kernel now believes the system is on the IDE disk, and the Supertar recovery process will write the backed‑up image to that drive. While the recovery console will still print messages about “SCSI” disks, it is actually writing to IDE under the hood.

Once the restoration completes, you must prepare the new boot loader and configuration so that the system starts up correctly when the machine is powered on. The first step is to edit the /etc/conf/cf.d/mscsi file on the new drive. That file lists the SCSI host adapters and target devices that the system should probe at boot time. Because the IDE controller is not a SCSI adapter, you need to remove any references to SCSI hardware. A typical mscsi file might contain lines like:

Replace those lines with the appropriate IDE device names. For a system where the IDE controller is the primary disk and the CDROM is the second device, the updated file would look like:

ide_hostadapter 0

cdrom wdc(0,1,0,0)

If the CDROM itself is also on an IDE controller, you should list it using the same syntax. After editing the file, rebuild the kernel with the new configuration to ensure the loader knows about the IDE devices. Use the make kernel command in the /usr/src directory, then copy the resulting vmlinuz and vmlinux to the boot partition.

Next, you’ll need to update the network configuration. If any of the PCI network cards were moved to different slots, run netconfig to re‑discover the adapters. This command scans the PCI bus, assigns names like net0 and net1, and writes the settings to /etc/conf/cf.d/nic. After that, rebuild the kernel to include the correct network driver modules.

Finally, verify that the /etc/fstab file contains the correct UUIDs or device names for the new drives. If you’re using GUIDs, run fstab -a to regenerate the entries. Once everything is in place, reboot the machine. The loader should find the IDE disk, mount the root file system, and start the operating system. If you encounter a “root device not found” error, use the loader prompt to specify the root disk manually with a line like:

Once the system boots, you can run sysinfo to confirm that the IDE controller is detected and that the CPU, memory, and I/O buses are functioning correctly. At this point your SCO OSR5 installation is running on the new IDE hardware, and you can continue to use it with the same tools, applications, and configuration that existed on the original SCSI machine.

Changing SCSI Controllers on SCO OSR5 with Bootstrings and BTLD

When the new server still uses SCSI but the controller hardware has changed, the migration process is a bit more involved. If the new machine uses a different SCSI host bus adapter (HBA) or a PCI‑based SCSI controller that isn’t in the same slot as the old one, you’ll need to supply the right driver during boot.

The first step is still to boot from the Supertar recovery media. On the boot prompt, you can override the default host adapter list with a boot string that specifies the exact SCSI HBA you want the kernel to probe. For example, if the new controller is a BusLogic PCI card that appears as bd(0,0), you might use:

If the kernel on the recovery media doesn’t already include a driver for the new HBA, you’ll need to build a boot‑time loadable driver (BTLD). A BTLD is simply a kernel module that can be loaded during the boot process before the root file system is mounted. The Supertar recovery disk can be configured to load a BTLD automatically by adding its name to the /etc/conf/cf.d/boot file. After the BTLD is in place, you can boot the system with the same boot string, and the kernel will load the driver, detect the new SCSI controller, and read the backup image from the appropriate device.

Once the system is up, you’ll still need to edit the /etc/conf/cf.d/mscsi file. Because the new controller has a different host adapter number, you must update the file to reflect that change. For example, if the old system used scsi_hostadapter 0 and the new controller is scsi_hostadapter 1, replace the line accordingly. If you used a BTLD, also make sure that the module name appears in /etc/conf/cf.d/modules so that it is automatically loaded on every boot.

Next, rebuild the kernel to include any new drivers or to adjust configuration flags. Use the make kernel command, then copy the new kernel images to the boot partition. If you changed any PCI card slots, re‑run netconfig to re‑identify the network adapters and regenerate the /etc/conf/cf.d/nic file.

With the new configuration in place, update /etc/fstab to point to the correct SCSI targets. If the UUIDs have changed, regenerate the table with fstab -a. Finally, reboot the machine. The loader should load the BTLD, probe the new SCSI HBA, and mount the root file system without issue. A quick sysinfo will confirm that the SCSI controller is detected and functioning.

For reference, several online resources detail how to craft bootstrings and configure BTLDs for SCO OSR5. The “How to build a BOOT string for OSR5” guide on microlite.com provides a clear example of the syntax required, and the Bofcusm archives contain step‑by‑step instructions for specific controllers such as Adaptec and BusLogic. By following these examples, you can ensure that your migration to a new SCSI controller goes smoothly and that your system continues to run with minimal downtime.

Moving a Linux System to New Hardware Using Supertar

Unlike SCO, Linux doesn’t expose a simple defbootstr command, but the underlying concept remains the same: you need to make sure that the kernel used during the restore process has the drivers for the new hardware. Because most modern Linux distributions ship with a broad set of modules built into the initrd, the process is often straightforward. However, if your system uses a unique or proprietary controller, you may need to add the driver to the initrd manually.

Begin by mounting the Supertar recovery media. Most Supertar images for Linux will provide an initrd that contains the modules needed for common SATA, IDE, and SCSI controllers. If your target hardware uses a newer controller that isn’t included, you can copy the driver module from an existing kernel on the new machine. Place the module under /lib/modules/$(uname -r)/kernel/drivers/ on the recovery environment, then add its name to the modules.conf file. For example:

After updating modules.conf, rebuild the initrd with update-initramfs -u or the equivalent command for your distribution. When you run the Supertar restore, the initrd will load the new driver, discover the new disk, and write the backup image to it.

Once the restoration finishes, mount the new root file system and edit the /etc/fstab file. Replace any UUIDs that changed during the migration, or switch to device names if you prefer. For boot configuration, you’ll also need to adjust the boot loader. If you’re using GRUB, edit /boot/grub/grub.cfg or /etc/default/grub to point the linux line to the correct root device. For LILO, update /etc/lilo.conf with the new root directive and run lilo to rewrite the boot sector.

Before rebooting, run modprobe -r to unload any modules that were added only for the restore, then modprobe the modules that the new hardware requires. Once the system starts, verify that the new disk appears with fdisk -l or lsblk. Use dmesg | grep -i scsi or dmesg | grep -i ide to confirm that the kernel detected the correct controller.