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.
See http://wdb1.sco.com/kb/showta?taid=105356 also. If that's gone (SCO may not last much longer), 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
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.
These links give examples of using bootstrings and changing scsi
controllers:
ftp://ftp.microlite.com/demos/docs/howto_btld_osr5.pdf
http://aplawrence.com/Bofcusm/119.html
http://aplawrence.com/cgi-bin/ta.pl?104062
http://aplawrence.com/Bofcusm/929.html
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.
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.

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. We appreciate comments and article submissions.
Publish your articles, comments, book reviews or opinions here!
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.
--BigDumbDinosaur
"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.
--BigDumbDinosaur
Thu Jan 1 00:00:00 1970:
Thu Jan 1 00:00:00 1970:
Fri Aug 18 21:08:03 2006: Subject: TonyLawrence
Be aware that older versions of sco aren't going to run on modern hardware..
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar