I had a call yesterday from a consultant with a crashed SCO 5.0.7 system. A decade ago or more that would have been something I could fix while half awake, but now my memory of SCO has truly faded. I already refuse to assist with anything prior to 5.0.6 in these cases as those memories are long gone, but I have felt that I could still handle the 5.0.7 systems.
Well, that feeling might be a bit too enthusiastic. Yes, we got it up and running, but it was a trial for both of us!
The consultant had actually got pretty far on his own. The original hard drive was making coffee grinder noises, but he had successfully installed 5.0.7 on a new drive and had mounted the old and successfully copied data. It was at that point that he ran into a problem and had quit for the day. Upon returning the next morning, he found that he could not remember the password he had assigned on the new drive!
Yes, you can laugh if you must, but imagine how he felt. He was "almost there" and now he was thwarted. He told me that he had found Lost Root Password SCO Unix but that the "chroot" had failed. I couldn't understand that because I was certain that I and many others had succesfully used those instructions. However, when I had him try again under my direction, that failed.
Right here is where I made a mistake. He and I made the same mistake, actually: neither of us bothered to read the comments at that "Lost Root Password SCO Unix" page. If we had, we would have seen other ways to fix this rather than "chroot". Instead, I had him do yet another 5.0.7 install on yet another drive and mount his "lost password" drive on that. We then tried the "chroot" again and again it failed. I still don't understand why, but I had him edit /mnt/etc/shadow and /mnt/tcb/files/auth/r/root to remove the passwords and of course made yet another mistake! I forgot about the annoying symbolic links of SCO: if you "vi /mnt/etc/shadow", you'll actually be editing the true file down in /var on your booted system because that's where the symlink points, duh!. I realized that when he rebooted with the disk he had made and it still had a password. We had to repeat the procedure and this time follow the symlink path to the right places.
Do I feel guilty about this bumbling? No, I do not: it's been at least fifteen years since I have had to do things like this. I've forgotten and I don't feel any shame for that!
So, now we had a working system, except that the application software didn't work. When I had him read me the .profile of a user, I realized it referred to variables that didn't exist, so of course these had been set in /etc/profile. We remounted the crashed drive and were able to get that from the symlink down in /mnt. Now the program did work correctly for some users, though not for all.
Back for another look at the original files, we noticed that a number of its files had hard links elsewhere. I had him use "find" with -inum and that file was in the terminfo directory, which would explain why some users had a messed up screen. But it was more than just terminfo; there were some files with four links. These would all need fixing, but chasing them down manually would be a pain. I could write a script, but the consultant said he still had the install media for the app. He could move the recovered files aside, do the install, and copy them back. I hope that all works as honestly I do NOT want to write that script. On the face of it that wouldn't be too hard, but I'd have to watch out for symlinks in addition to the hard links and account for missing files - it could be messy and it might not be able to fix everything - I'd rather not be involverd.
That's where we left it - I wish him luck!
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2015-01-08 Anthony Lawrence