Will these ancient SCO systems ever go away? Yes, they will, but more than a few are still hanging around, so I still get involved with them. Understand I'm not particularly anti-sco but I do think the handwriting on the wall is not going to be washed away very easily and it says that folks running SCO need to at least make alternative plans just in case. If that's you, you might find these links helpful.
Anyway: a few weeks back I was contracted by another consultant to upgrade Microlite BackupEdge and help him configure a "backup spare" that they could have ready to press into service in the event of the primary machine failing.
That's a good idea, and there are two ways to approach it. One is to install SCO and Microlite on another box and then selectively restore applications etc. and the other is to use the bare metal restore features of Microlite BackupEdge to bring the new machine up exactly as it exists now. The second method has the advantage of not being concerned about accidentally overwriting something that shouldn't be overwritten; it's an exact duplicate of the other system.
So we took door number two and I made recovery floppies (the machine has no writable CD and the tape isn't bootable). I took those and a recent backup to the other consultants office to bring up the spare box.
Normally, that's very simple: boot from the recovery disks, follow the directions, restore the tape, done, reboot, voila: working system. Easy stuff.
Not this time.
The system couldn't find the tape drive, and therefore couldn't restore anything. I peeked at it and thought I saw the problem instantly: it was not set at the expected SCSI id. So I powered everything off, scrounged a jumper, and started over.
But no luck this time either. No tape drive. What the heck?
I looked closer and smiled. The original machine had the tape attached to an LSI card. This machine had the tape cabled off an Adaptec card. Different hardware, and that's why it saw no tape.
The consultant immediately asked "Can't we use this?"
Well, yeah, we could, but wasn't the point here to have an identical machine that could be bare metal restored at any time with no caveats and no special handling? Weren't we looking for a "blind and stupid" restore that wouldn't involve the slightest bit of thinking?
Yes, I do believe that was the original game plan.
If you are change hardware, you can't directly restore the tape - there would be more work necessary after the restore to create a working system, and of course you couldn't keep the machine up to date with new tapes without being selective in the restore.
So he went looking for identical hardware. I had shown him how the Microlite disks worked so he didn't need me any more. But I heard back weeks later that he still had no luck. The original controller is dual channel: the hard drive is configured on channel 0, the tape on 1. He couldn't seem to find that model, or maybe it was bios revision issues: whatever, he couldn't make it work. So we were back to the Adaptec for the tape drive.
Given that, why not just do a base install of the OS and work from there?
That's what I'd do, but he still wanted to try it from the recovery floppies. I pointed him at my Transferring to new hardware with a Supertar article and he tried it. Initial results were not good. The first attempt was to assume the kernel had built in support for the Adaptec and just give a "defbootstr Stp=alad(0,02,0)" string. He said that didn't work, which surprised me - I think it should have, but he went ahead and downloaded a driver from Adaptec. I pointed him at Handling floppy Disk Images and we tried it with a "link" added. He reported back
"I typed 'link' and I am getting 'Unix not found'".
Huh? It took me a bit before I realized that he must have been pulling out the boot disk and inserting the BTLD before being told to do so. I wrote back and explained that the link code would tell him when and what to insert: he'd get hand-held the whole way. I'm not sure I was clear enough on that because the next morning his email exclaimed
"I think I have tried every possible 'timing' sequence with this issue"
There is no "timing" - you get told when to swap diskettes.
I'm also not sure that he doesn't need to give a more complete boot string. The Microlite PDF implies that if you start down the road of defining tape devices, you need to be complete and include the hard drive info also. I'm not sure that's correct, but it wouldn't hurt, so he might as well try it.
I don't know what the final result of this will be. It's entirely possible that I had to disable BTLD support when I made the original recovery disks - I just don't remember and I certainly wasn't expecting to need BTLD support at that time. I don't know what the symptoms would be if you tried to use a BTLD with a recovery disk made without that support, so I suggested that he take that question to Microlite directly. I also again suggested that it might make sense to forget this and just do a base install: it's going to require special handling anyway, so why struggle with this?
The customer has every intention of replacing the application running on that server. They don't know yet what platform the replacement will be running on, but whatever it is, it will be new hardware. The spare for this SCO box is just a very temporary extra disaster prevention plan, so if it cannot be done as originally intended (with identical hardware), so what? It isn't the method that's important here, it's the final result - or at least that's how I see it.
Should he be able to do this from the recovery disks? Yes, assuming that I was originally able to create them with BTLD support. But he should have been able to do this with the right LSI controller also.
If I were doing this, I'd do a base install on the spare hardware and then selectively restore from tape. Actually in this case I could just do a complete overwrite and reconfigure the tape drive afterwards; that might be quicker. I'd then make a restore script that the customer could use to keep this machine up to date from the working machine's backups. This gives the customer what he wants. I think too much time has been spent already on the original plan - it's time to move on.
Actually, if it were entirely my call, I'd setup two identical machines, transfer the current system to one of them, and then go with the original plan of identical twins - that's still the ideal, I think.
But it's not my call, and I don't know what will happen next. I'll keep this updated, though.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2011-03-18 Anthony Lawrence