I am working on a system that uses SCO Unix 5. I started later in this troubleshooting process so I have had to play catch up on some of the earlier mistakes that were made.
The HD was formatted using the SCSI controller cards bios.
I have 2 recovery floppies the boot and the root.
After the root is mounted on the floppy and it shows the device list the system becomes unresponsive. I am unable to use the keyboard, at the # command line, the cursor is still flashing. (see picture)
I have isolated the SCSI controller card now down to just the HD. Removing the CD-ROM, and tape backup. I am at a loss at how to proceed
Any guidance?
the boot and root floppies are from a different identical system, there are 4 of these system running on site. they were all purchased at the same time, I have been told all parts are identical in them. I cannot take the tools down to do a component level check on these to verify so I have to take their word on this. But the original vendor for these historically did use all the same parts until there was a different version to eliminate hardware issues.
Sorry if the pic is bad quality, It looked good when I took it. I cannot get a better picture at this point.
I take it that you are booting from the diskettes.
Lets define the hardware.
Adaptec 2940 host adapter, 2gb scsi disk, scsi tape, and scsi cdrom.
130k of memory, intel 100pro network card, digiboard PCIXr 8 port serial card.
I think that this is 5.0.5 based on the kernel date of 97/09/03, and probably a P3 cpu.
I would install a fresh hard drive, install the operating system from scratch.
Add the original disk in as scsi id 1, and put a jumper on the readonly pins.
Then attempt to mount the second (original) drive.
So I have swapped the HD with a different HD and still get the same response.
It feels like at this point it is not recognizing the keyboard. Especially since the curser is still flashing so I know they system has not actually locked up.
While this seems simplistic and maybe I have missed this is there a specific driver needed for a keyboard? or does SCO use a generic driver to all keyboards.
Yes PS2 keyboard.
This is a controller attached to a tool, the controller was removed from the tool, after a week of other techs, working on it. It was handed to me, after multiple rounds of troubleshooting and making some progress I am now at this point.
By the time I got the controller the HD had already been wiped so I do not know if this was a miss diagnosed original problem.
Yes the plan is to restore from the tape backup.
My initial thought was the SCSI controller card was the problem, because even though it lists the CD as bootable I was unable to boot anything from it. Even after assigning the cards bios to boot from CD first. But I removed that as a issue when I was able to through the card bios able to format and then do a media verification on the HD.
I can do this with both of the drives I have used in the controller.
I can not progress beyond this point. After 2 days I am beginning to hit my head against the wall here. I have resolved several other unrelated issues to this, Just am uncertain how to resolve this.
Can you confirm that the motherboard CMOS will allow booting from the CD.
Is there an onboard IDE controller, and if so, is it/they disabled?
Since the HD is blank, and you have extra drives, why not try installing the OS again. This at least will confirm that there is nothing wrong with the keyboard controller.
The Adaptec driver is included on the original cd, so there are no BTLD (boot time loadable drivers) required.
No it does not seem to allow it, regardless the software from the manufacture is not bootable, and requires the use of the boot/ root floppies.
To prove to the initial guys the keyboard was fine I used a generic NT IDE drive I have and while NT did not love it at all. The controller was running fine using the keyboard for over a half a hour before I shut it down.
I have now tried all four sets of boot/root disks I have and same results with all.
I have another SCSI adapter that is identical coming in tomorrow to completely eliminate this as the root cause.
At this point it no longer feels it is the SCSI controller. I really feel like I am missing something simple and am just being stupid. Ill be honest its been 7 years since I touched SCO unix to say I am rusty is a understatement.
Do all 4 machines have the same serial number?
Is the output from 'uname -X' the same for all of them.
I am beginning to think that the software supplier built one system at their site, then produced 4 machines for sale, and provided you with an emergency boot floppy, and a backup tape that you can restore; meaning that you never received a copy of the operating system, or probably any instructions on how to upgrade the hardware.
Is it possible to pull one of the other machines out of production, and install a blank drive in it as scsi id 1, then boot a standalone product like hdclone and duplicate one of the other systems. If you were to do this are there different data files on each machine?
I seem to remember from a previous time I had to go through a much less painful version. it was not the case each had diff serial numbers.
but I don't think you are far off from the overall mark.
There are significant other unique files on each system that will not play nice if i try that. If this was a different platform I would do just that.
thanks alot for taking the time on this, I really appreciate the help.
I have spent days researching this out with no solution at this point. If anyone can think of anything else I am willing to try it.
Rather than work with diskettes and cartridge tapes:
Build a machine to replicate hard drives. Use a socket 478 or 775 motherboard with support for SATA drives in compatible mode, with a SATA disk and DVD-RW, and at least one PCI slot (for the 2940 controller.) Install SCO 5.0.6 on this machine to the SATA drive.
Add the tape drive as SCSI id 2, and add the target SCSI disk as ID 0. By default the system will boot from the IDE controller.
Restore the tape to the target disk drive. Confirm that the new drive will work in the production environment. Restore the tape to an image file on the SATA drive. Use this image file to create another target drive and test in production.
Assuming all this works, create image files for the other machines. Copy the image files to DVD for archive/backup.
I think they will pull the plug before I get a chance to go into that level and send it back to the vendor. Who I think does not even have a legacy department for these toolsets anymore.
This means they would just send us a new controller at a expense that I could most likely buy a sport car.
So going backwards, can we think of any reason why it would bomb out after creating the kernel. I cannot find a single reason in my research, everything I have found shows some form of error code. This has no error code displayed.
Alexander
I think I would try making a new boot and root set on one of the other 3 machines, verify operation on it, then try it on the machine that is failing. That would eliminate bad boot and root, just in case the supplier duplicated them from a bad original.
More likely, in my experience, that the CD is bad by a factor of at least 20 to 1. Can you swap a CD across.
To answer the previous question, keyboard is generic and shows up as it is booting up.
Assume that the SCSI bios reports all devices correctly on BIOS attachment.
So after pulling the replacement controller out of stores it was DOA. vendor would not honor warranty So I was allowed to do more work, also I found a bevy of old PC parts I could use to start isolating the problem.
After swapping everything out then returning all to normal. I decided to build a frankenstien out of the spare parts, and attempt to restore the HD which had been formatted to try to see if I could get some better error codes.
moved original D into frankenstien then restored original image back onto it.
after having to make a minor mkdev graphics change. the system booted right up with no problems, until it tried to find boards required to run the system software.
moved HD back into original controller booted up then gave the following code
Open event driver failed.
Fatal server error:
Check mouse configuration.
turns out PS2 mouse had enough uph to limp in windows but failed in SCO unix.
The lock up occurs when the PS2 mouse fails.
ordering new P2 motherboard. just wanted to update on the root cause of all this and close this thread out.
thanks again for all your help.
