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.
Then build a new kernel with "./link_unix -y". Reboot, and you are
done.
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.
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
|
| From the Forum: | | Hackers gettting on our server | We have an in-house server running on a T1, learning as we go, grins :) and double grins and, well you get the the point.
We are being hacked into. Maybe someone puts their music files on our server and has folks downloading from it. Or we might find a porn site trying to deposit it's ugly self on our server and transact business --
Regardless, we need to tighten the ship down. |
 |
By A.P. Lawrence