APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Microlite BTLD

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.



2 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Wed Jun 14 20:17:33 2006: 2116   anonymous


The symptom of not using the BTLD option when creating recovery diskettes is that there is insufficient room in the recovery kernel to link in any new drivers. You'd get the same result if you try to use link on any non-trivial, non-installation 5.0.x kernel. Try it sometime, you won't screw up anything whether it succeeds or fails.

Please note that BTLD support is often not possible on BackupEdge recovery CDs because the larger recovery kernel no longer fits on the 2.88MB CD floppy image. When using the 3-floppy disk option, the kernel usually always fits on the first floppy after compression.

You don't have to have absolutely identical SCSI hardware on your backup system just as long as you remember to link in the drivers for *both* hard disk controllers into the kernel on the primary system, thus avoiding the need to ever use the BTLD feature. To make things even simpler, there's a useful feature in the /etc/conf/cf.d/mscsi file that lets you use 'auto' instead of the actual driver name for the first hard disk, tape and cdrom defined in the file. With 'auto', the kernel will use the first available host adapter it finds to assign to the hd, tape & cd. See the mscsi(F) page for details. Thus you can restore the root filesystem on the new machine, boot it up and tweak the configuration to recognize the remaining drives before restoring the remaining filesystems.

The one thing I'm not clear about is whether this is an actual emergency situation or just a test run of the spare machine? If it's the latter, then the simplest solution would be to go back to the original system and link in the proper driver for the spare machine's host adapter, reboot, and then re-create the floppies.

--Bob



Wed Jun 14 20:30:38 2006: 2117   TonyLawrence

gravatar
Right: we could go back and put the Alad drivers into the original kernel and remake diskettes.

But my point is that we've already lost the original intent of identical systems, so we might as well just do a base install and stop screwing with it. The horses are out of the barn already..

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





We made the buttons on the screen look so good you'll want to lick them. (Steve Jobs)

May you live long enough to regret your opinions - (Tony Lawrence)












This post tagged: