With any of the Supertars, transferring to new hardware is easy. If the new hardware uses the same disk controller (or the same driver) as the old, you can just boot from your recovery media and proceed to recover the system. But what about when the new hardware is different?
Well, it’s not much different. The general procedure is still that you boot from the media and that you restore the system as usual; it’s just that you may have to do some prep work or (SCO) use boot strings to assist the process. Let’s take the case of transferring a SCSI system to IDE as an example. To make it more interesting, we’ll assume that the SCSI tape controller gets transplanted to the new machine also.
SCSI to IDE SCO OSR5
IDE is certainly attractive. You can get very large drives for cheap money, and they are much faster than they used to be. However, keep in mind that your system may be slower than you think. Drive RPM and even seek time do not tell the entire story of performance under a multi-user system. If you want ultimate performance, you still want SCSI, not IDE. That said, a new, high performance IDE drive may very well outperform an older SCSI system even under the demands of a multi-user system, so it’s not unusual to see people make this migration.
In this case, you don’t havev any problem with the recovery media not knowing how to use the drive: IDE is built into the kernel. But both the media and the restored kernel think that they are supposed to be looking at SCSI disks, so you have to give them some help. With a SCO system, at the boot media prompt, you’d do:
defbootstr Sdsk=wd(0,0,0,0) hd=wd
and then proceed with the restore, The recovery programs may show you that they are recovering the SCSI system, but they will really be writing to the IDE drive. After the recovery is done, you need to boot the hard drive with the same “defbootstr Sdsk=wd(0,0,0,0) hd=wd”. Cd over to /etc/conf/cf.d and edit mscsi. Remove hard drive references, leaving cdrom and tape. For example, you might have this:
You’d need to change that to be:
and if the new CD were also IDE (master on secondary controller) you’d use this:
You may have to redo drivers for PCI cards that aren’t in the same slot that they were in on the old machine: netconfig for nic cards, for example.
SCSI to SCSI OSR5
If you don’t need a BTLD, then the bootstring method is exactly the same, just different strings. Even with a BTLD (needed if the kernel doesn’t have support for your new controller), you are just linking in the driver you do need. Again, after booting the new hard drive, you need to fix up /etc/conf/cf.d/mscsi and build a new kernel.
These links give examples of using bootstrings and changing scsi controllers:
ftp://ftp.microlite.com/demos/docs/howto_btld_osr5.htm
http://aplawrence.com/Bofcusm/119.html
http://stage.caldera.com/cgi-bin/ssl_reference?104062
http://aplawrence.com/Bofcusm/929.html
Linux
You’d expect Linux to be easier, but actually it doesn’t seem to be There’s no “defbootstr” with Linux. However, all is not lost. The easiest (and maybe the only) method is to get any modules you need installed on the existing system and included in the modules that your reccovery media has (the exact procedure for doing that will vary with the specific Supertar). After restoring, use the recovery disks utility menus to mount the hard drive and edit /etc/modules.conf. You need to change the “alias scsi_hostadapter” line to reflect what you actally now have. Possibly you need to change /etc/fstab also, and you’ll need to reconfigure /etc/lilo.conf or grub.conf.
When you reboot, you might need to help the kernel find its root. You’d change that permanently with “rdev”.
I haven’t had to do this yet. I think my approach would be just to install Linux on the new hardware, and selectively restore after the fact. It just seems easier to me, but I may be over-reacting. I’ll give this a try sometime soon.
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
