Fixing an old SCO Unix 5.0.4 machine
The other morning I got up early and drove to Chelsea, a suburb of Boston. That's not the most pleasant trip most mornings, but traffic was light and although I had not visited this customer in the past seven years, I remembered the way and only had it in the GPS in case I was wrong about that memory.
I wasn't happy about the visit, though. Yes, I like the people and looked forward to seeing them again, but I was not looking forward to seeing their SCO Unix server, which was the reason I was in my car that morning.
I knew that the server was old - probably circa 2005 and running SCO Unix 5.0.4. Ordinarily I would flatly refuse to have anything to do with something that old, but as I said, I like these people, so there I was. As I pulled into the parking lot and got out of my car, I sighed. Oh, well, maybe this would be easy.
After saying "Hi" to the faces I remembered, I went into the server room. There was the beast, an old Gateway. Not the best hardware even when it was new and seeing it now gave me chills. The front cover was loose and I could easily see dust even from there; I cannot imagine what the inside must have looked like.
I noticed a DVD drive and a tape. Could it be that they were trying to boot from one of those? No, the DVD was empty and when I ejected the tape, I saw that a loop of tape remained inside the drive, firmly stuck. So much for any backups, I thought to myself.
The screen was showing "Enter run level (0-6, s or S)". I knew from the previous day's phone conversation that was as far as it would go. I hoped that S would work, and indeed it brought me to the "Enter root password for single user mode" prompt. I entered the password and was happy to see a "#" appear. Good - not excessively broken, anyway!
The most likely reason for inability to get beyond single user mode is a missing or broken inittab. Newer versions may even tell you that's the problem; this just hangs trying to go multiuser, but that's still the likely culprit. Indeed, that was the case: /etc/inittab was an empty file. That can happen on these old systems; I wasn't overly surprised. It's easy to fix: the inittab can be quickly reconstructed from /etc/conf/cf.d/init.base and any other paets found in /etc/conf/init.d, assuming those havent' been damaged or lost.
Those files were present, so I just did:
cat /etc/conf/cf.d/init.base /etc/conf/init.d/* > /etc/inittab
I could have used "idmkinit" also, but I couldn't remember its path, so the "cat" was quicker. I then rebooted and watched as it succesfully passed by where it was hung previously. It wanted to run fsck; of course I let it do so - not running it upon request might well have caused this very problem!.
That fsck ran a LONG time. I had forgotten how slow these old wheezers can be; it ran so long that even I was getting nervous. Eventually it did finish up and the system booted to normal multiuser mode. I asked the users to log in and confirm that they could access their data; everything seemed to be fine. I don't know what I would have done if it were not: someone had written a crontab script to do a cpio backup, but the latest run of that had failed due to insufficient disk space. I spent the time to clean up enough space that it would be able to run and showed the manager how to copy that backup to her Windows machine.
So that was that. Hopefully the last time I ever see THAT machine. It's only running for historical data; they replaced it with a Windows system a year ago, so it's not absolutely critical. I wonder if it will survive until they do not need it at all?
It was nice to see those folks again. I was happy that the fix was easy; it might not have been. I got in my car, called in the billing to my wife, and headed back home.
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic