Replacing SCO 5.05 older machine with new server

Sooner or later, you will be faced with having to replace a failed SCO Unix server or updating to a newer server. Hopefully the latter. I have outlined some of the procedures I used (with the aid of article in this forum) to replace our SCO 5,05 running Adaptec alad, 128m 350 mhz server to a brand new Athlon 1.83 GHz server with 512K memory, Adaptec 29160 controller, and 18 gig LVD drive.

The first problem encountered is the Intel system board and Intel P4 processor. The new system simply would not boot from floppy or CD Rom. After many hours of frustration, and with the aid of the SCO newsgroup personnel (Thanks Bela Lubkin), it was determined that Intel has decided to enforce the Boot string requirements. Also after reviewing some other posts in the newsgroups, it was also noted that version 5.05 does not run very well on a P4 processor. I decided to just replace the system board and use an Athlon processor. I got a MSI board and Athlon 1.83 Mhz processor. To use the Intel, it would have been necessary to upgrade to version 5.07.

The next step is to load the base OS from floppy and CDROM, hopefully you have the keys and software. This can always be a major problem in that usually these systems have been running for years, and this information is not available.

It is possible to get the information from SCO, but you will at least need your purchase invoice, and the Serial number.

Editor's note: Note entirely true. See How can I find my Activation Key? and How do I find out serial numbers of my various components?

I purchased an Adaptec 19160 SCSI adapter, because the hard drive was a U160 LVD. The next problem is that that particular model does not support SCO, and I had to trade for the 29160 model which did. This is really strange in that one of these does not support Windows NT and vice versa. So you have to be careful in getting the proper card.

Installed the card and drive, added the SCSI CDROM and proceeded to install the base operating system. The next step is to install the Tape Drive.

All this stuff is backwards compatible, right. It pretty much has been, and I never have had any problems before. But this particular card simply would not recognize the Tape Drive. So I had to find an older PCI SCSI card from one of my other systems.

The very first and most important step is to get a backup of the old system. I use CPIO and have for years. It works much easier if you use separate tapes for each your file systems. Backup /stand and / on one tape, /u on another, and in my case /hd4 on another.

Of course if you have the luxury of having both machines offline, there are several other options like installing the old drive in new machine, or using DD with CPIO piped to simply copy the files over a network. These procedures apply to doing this remotely or when the existing machine cannot be taken offline.

1. Backup the old system with cpio

2. Install base operating system on the new system, and apply the new driver.

Use the Option to execute divvy so that you can size your partitions. I expanded my swap, made the / and /u filesystem larger, and allocated the rest to /hd4. Run mkdev tape to install the tape unit.

3. Make an boot floppy and root filesystem. Make sure they work. Probably good idea to make two sets

NOTE: I wasted a lot of time trying to install the driver with an emergency boot floppy from the old system. The Adaptec driver would load up, and then abort because of not enough memory. So it is imperative to get a base OS running from the install disks.

4. Boot with emergency floppy from the new system.

   mount /dev/hd0root /mnt 
   cd /mnt 
   rm -r *           // get rid of cur system 
   cpio               // restore the old system

   cd /                   // save boot stuff 
   mkdir b 
   mount /dev/boot /b 
   mkdir /mnt/bootstand 
   cp -r /b /mnt/bootstand

   cd / 
   umount /mnt 
   mount /dev/boot /mnt 
   cd /mnt 
   rm -r * 
   cpio // restore /stand

   cd / 
   umount /mnt 
   mount /dev/u /mnt 
   cd /mnt 
   rm -r * 
   cpio // restore /u

   cd / 
   umount /mnt 
   mount /dev/hd4 /mnt 
   cd /mnt 
   rm -r * 
   cpio // restore /hd4
 

5. Chroot to hard drive

cd /
umount /mnt 
mkdir rootmount 
mount /dev/hd0root /rootmount 
chroot /rootmount /bin/sh    // see man chroot

NOTE: The following is from article posted How can I install a new disk controller that requires a different driver?

   mount /dev/fd0 /mnt 
   btldinstall /mnt
 

That lets you install the driver, but hasn't told the system to USE that driver.

Identify the current disk driver by

 grep Sdsk /etc/conf/cf.d/mscsi
 

Your current driver will in column 2- examples "alad", "arad", "blad"

Identify what driver you need by examining /etc/default/scsihas (if you used a btld, it's whatever you installed)

 cd /etc/conf/sdevice.d
 

Edit the current driver file and change the "Y"'s to "N" in the first column. For example, if your current driver is alad, you edit /etc/conf/sdevice.d/alad. Edit the NEW driver file and change "N" to Y. Example, your new driver is "blad", you edit /etc/conf/sdevice.d/blad.

Next, cd /etc/conf/cf.d and edit mscsi. Change the driver column to match your NEW controller. For example, changing from alad to blad with vi:

 :1,$s/alad/blad/ :wq
 

Finally,

The following gave me a warning so I just made a copy of /stand early in process.

btmnt -w 
cp /stand/unix /stand/unix.good 
btmnt -d

cd /etc/conf/cf.d

 ./link_unix

Everything linked but did not get the chance to install as default.

So copied

cp unix /stand 
 

and reboot from harddisk, TCP will fail because of the drivers for your netcard, The video and mouse will have to be reconfigured.

I also got the INCORRECT ISAM version error. Simple fix is to execute isverify from a root prompt.

The system was shipped to the remote location for the final test. The old machine was removed, and replaced with the new server. System was powered on, and Everything Works.



Got something to add? Send me email.





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

Printer Friendly Version

-> -> Replacing SCO Unix 5.05 older machine with new server


1 comment



Increase ad revenue 50-250% with Ezoic


More Articles by © Leroy Janda



Some comments on this article:

" The first problem encountered is the Intel system board and Intel P4 processor. The new system simply would not boot from floppy or CD Rom."

The P4 is generally a poor choice for a server, Windows or otherwise, as its ridiculously deep pipeline substantially hurts throughput in a server application. The reasons have to do with the tendency for branch predictions to frequently fail in server use, which results in frequent flushing of the pipeline. When this happens numerous CPU cycles are wasted. The Athlons in all versions tend to readily outperform the P4 in this case (the Barton and MP cores are best for server applications).

"The next step is to load the base OS from floppy and CDROM, hopefully you have the keys and software. This can always be a major problem in that usually these systems have been running for years, and this information is not available."

The serial number, etc., can be found in iqm_file, which is located in the /var/adm/ISL subdirectory. You should always consult that information before attempting an IPU or fresh install. In fact, it is wise to print that file and store the page somewhere off-site, just in case!

"I purchased an Adaptec 19160 SCSI adapter, because the hard drive was a U160 LVD. The next problem is that that particular model does not support SCO, and I had to trade for the 29160 model which did. This is really strange in that one of these does not support Windows NT and vice versa. So you have to be careful in getting the proper card."

Not strange at all. If you check the 19160 product info on Adaptec's website you'll see that this is a lightweight U160 implementation. The 29160(n)'s hardware was intended for entry to mid-level server use, whereas the 19160 is a cost-reduced device that lacks some low-level hardware features needed in a true multitasking environment. Adaptec was wise to not make a SCO driver available for the 19160. Incidentally, the 29160N is a bit less expensive than the 29160, as it does not include the 16 bit single-ended port, just the U160 and 8 bit ports. If you are not using any ultra-40 hardware, you can live with the 29160N and save some bucks.

"All this stuff is backwards compatible, right. It pretty much has been, and I never have had any problems before. But this particular card simply would not recognize the Tape Drive. So I had to find an older PCI SCSI card from one of my other systems"

Huh??? Assuming the tape drive has been daisy-chained onto the narrow host adapter port, it should show up just like the CD-ROM. Are you sure you didn't have a SCSI ID conflict and are you sure the termination is correct? Also, you didn't try to attach the tape drive to the U160 port, did you? Try using the SCSI-Select utilities built into the host adapter firmware to analyze your connections.

"The following gave me a warning so I just made a copy of /stand early in process.

btmnt -w
cp /stand/unix /stand/unix.good
btmnt -d
That should be:

cp -p /stand/unix /stand/unix.good
btmnt -r
to assure that the file attributes are preserved and that /stand is returned to its normal read-only mode (no telling what the mount configuration is in /etc/default/boot -- it could be wrong).

--BigDumbDinosaur


BTW, it's usually a lot easier to do this kind of thing with one of the Supertars - download a demo version and use that..

--TonyLawrence





Tue Nov 27 02:28:08 2012: 11441   thelastSCOzombiedealerinamerica

gravatar


Your site has helped me so much over the years! Here's a tip:

Quick Recipe for duplicating ancient single hard-disk pre-5.0.4 SCO systems, or those with hardware RAID that present a single image from a SCSI drive:
A. Boot SCO system with modern rescue disk (ubuntu, etc)
B. Determine drive appearance (ie /dev/sda or /dev/sdx or /dev/hda/) and write it down. It helps to pull the drives and ID the hardware, but mostly you want the size of the device or image.
C. Using a USB drive adapter, plug in a SATA drive of a different (larger) size and make sure you can see it using dmesg, or whatever filesystem manager is in the rescue disk.
D. Write the following sentences 100 times on a white board:
"I am not dumb enough to blow away my original drive by using the wrong parameters in dd or dd_rescue. I will not forget that this utility will blindly copy from one drive to another, and it doesn't care that I swapped the device names. I will carefully identify the devices using fdisk, and write out the arguments and get someone else to check them before I run the command. I will make sure I understand what if= and of= are used for."

I haven't screwed this up yet, but a guy who worked for me once blew away the ONLY copy of an ERP system by being an idiot. Luckily I had made a backup by mistake before I gave the system to him. I had visions of $125,000 lawsuits wrecking my day.

E: If you understand what you are doing, then use dd or ddrescue to copy the image to the new drive from the old drive, keeping in mind that "high-performance" SCSI drives of yesteryear are pretty weak by today's standards. Don't set a 16M block size, it's useless. ddrscue is better than dd.

F: The payoff: A sata drive on reasonably modern hardware will emulate the SCSI hardware just fine. I prefer IBM/Early Lenovo boxes, and once you copy the drive (it can take hours and hours with slow SCSI hardware) you can generally (or often) simply boot the new system.

Once you have a bootable SATA copy, you might use dd to make a backup image for future use. Use gzip or tar with the -z option to shrink it down. I hear these run OK in VMs, your mileage may vary.

G: I haven't finished sorting it out, but running divvy on the new system can often show you what file systems to try mounting so you can extract the data. Print out or copy down the output, and don't make any changes. If you're lucky, unused space on the drive might be usable as a dos partition, but I haven't ever had that kind of luck and resizing a SCO partition... well, maybe getting a newer version of sco running would be easier.

SCO uses an old and non-standard way of setting up partitions. It is what it is. You might be able to install a second drive, format it as something manageable and mount it using sysV semantics, or doing the mkdev monkey dance, but that's outside of my scope.

Anyway, I've gotten several "lost/forgotten/hopeless" systems up and running like this.
Hope it helps. Digi boards are often drop in as well.

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

privacy policy