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).
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 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
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
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
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
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.
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
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. We appreciate comments and article submissions.
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.