Transferring to new hardware with a Supertar

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.

The basic idea is that you may be able to just enable the driver you want (btldinstall if necessary, edit /etc/conf/sdevice.d/whatever, disable old driver same place, and edit /etc/conf/cf.d/mscsi, relink, reboot with new controller).


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 have 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:

#ha     attach  number  ID      lun     bus

alad    Sdsk    0       0       0       0
alad    Srom    0       5       0       0
alad    Stp     0       2       0       1

You'd need to change that to be:

alad    Srom    0       5       0       0
alad    Stp     0       2       0       1
and if the new CD were also IDE (master on secondary controller) you'd use this:
wd      Srom    1       0       0       0
alad    Stp     0       2       0       1

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.

Then build a new kernel with "./link_unix -y". Reboot, and you are done.


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.

See also How do I change my SCSI host adapter on older SCO Unix?


You'd expect Linux to be easier, but actually it doesn't seem to be. There's no "defbootstr" with Linux (Linux can use Driver Disks, which are the same as SCO's BTLD's and are read with the boot command "linux dd"). 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.

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Transferring to new hardware with a Supertar


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Tony Lawrence

"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."

It is possible on many higher end motherboards to assign IRQ's to specific PCI slots. It might be worth the time to examine the PCI configuration on the old machine and note the IRQ's assigned to specific devices. After installing the devices into the new MB, use the BIOS to permanently map each device to the IRQ it had before. In some cases, it may be necessary to shift things around to achieve the desired results.


Fri Aug 18 21:08:03 2006: 2415   TonyLawrence

Be aware that older versions of sco aren't going to run on modern hardware..

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

UNIX is simple. It just takes a genius to understand its simplicity. (Dennis Ritchie)

Thunder is good, thunder is impressive; but it is lightning that does the work. (Mark Twain)

This post tagged: