Do You Know SCO? (clarification)

Thu Oct 9 15:58:33 PDT 2003

I'm seeing a lot of good answers, but it's also clear pretty much 
everyone thus far has about as much SCO experience as I do, and so the 
suggestions are fairly common-sense but lacking in those gritty details.

(format.dat's a good guess, though; tip of the hat to Maureen Woodward, 
she's in the lead, such as it is.)

It might help if I clarify matters by saying that it is -not- the boot 
disk which was replaced.

Let's see, I think I have some error messages scribbled down here ... 
haven't Google'd 'em yet.

G hd_config
WARNING: hd: no root disk controller was found
H init ime Loadable Driver may be required
G drain8042
PANIC: srmountfun Error 19 mounting rootdev (1/42)
Error 19 opening dumpdev (1/41)
Dump not completed
*** Safe to Power Off ***

I also note that the devices were all visible to the SCSI controller's 
BIOS, so that shoots my hardware incompatibility theory down ...

(Gee ... I could see how printing a cryptic error message on the 
whiteboard, and then challenging the crowd to diagnose the problem, one 
question at a time, with a prize for whoever gets it first, could be a 
real crowd-pleaser ... at a meeting of systems administrators.)

-- richard

richard childers / kg6hac wrote:

> Do you know SCO?
>
> Santa Cruz Operations' UNIX, that is?
>
> I don't know the version of SCO; but I know someone, who has a 
> customer, whose SCO installation had a hard drive die. They need help.
>
> It would be fair to charge $80 an hour - but it would also be fair to 
> say that you would be expected to provide expertise, in exchange for 
> the privilege of charging money, for sitting on your butt, restoring 
> their data.
>
> Before I can provide interested parties with the contact information, 
> you must convince -me- that you know more than I do about this problem 
> ... so that I can hand it off to you, in good faith.
>
> Here's the history.
>
> I was brought in to diagnose the problem; hardware or software? After 
> some poking around, I found SCO's equivalent of /usr/adm/messages, and 
> in it, hard error messages naming a device and the bad blocks. I 
> extracted the device name, translated the UNIX nomenclature into a 
> SCSI device for the benefit of the service provider, and also provided 
> a list of bad blocks.
>
> Several weeks later, I was called and asked to come down ASAP; the 
> service provider was returning the computer to the customer, the drive 
> had been swapped, but it wasn't booting with the new drive, only when 
> they put the old drive in. He was hoping I could help.
>
> The old drive was a once-widely recognized 9 GB SCSI of, I'd guess, 
> late 1990s vintage. He was unable to replace it, he said, and so had 
> installed a larger 30 GB drive, but it didn't work.
>
> Although I won't go into the physical hardware here, it's not unlikely 
> that there was a mismatch in the SCSI controller, cable, and drive; I 
> have recommended that he get an identical drive simply because 
> although it is very intellectually satisfying to puzzle out what is 
> not working, it also takes many hours, is rarely cost-effective, and 
> requires technicians with at least a two-year degree from a junior 
> college in electronics or computer hardware, which, I judge, may be 
> lacking here (and for this reason, diplomacy is required, as well as 
> technical expertise).
>
> To make matters worse, throughout this sequence of events he had 
> insisted that Norton Ghost would be sufficient unto all his 
> requirements. Having recently dealt with a Linux server that had been 
> Ghosted (and it was one un-bootable, un-filesystem-checkable piece of 
> silicon, too), I had my doubts; I know too much about how filesystems 
> and hard drives and bad block mapping works to assume that you can buy 
> a one-size-fits-all solution, shrinkwrapped, at CompUSA.
>
> But I have not said so explicitly; I hate to argue with a customer. 
> (Again, diplomacy is indicated.)
>
> My intuition is that there are a combination of problems here; a 
> hardware mismatch combined with an operating system gotcha.
>
> (I'm not against working on this directly, if there's someone out 
> there who wants to answer questions and permit me to do the dirty work 
> in exchange for a small honorarium for their wisdom and guidance, by 
> the way, if they're reading this, are knowledgeable, but are feeling 
> undermotivated ... contact me.)
>
> My intuition is that the solution involves negotiating the hardware 
> mismatch ... reconciling the operating system gotcha ... building a 
> new filesystem ... and reloading the data from backups, made either 
> immediately before the disk is exchanged, or from a stack of tapes 
> whose contents and dates of creation would probably need to be audited 
> and verified beforehand (IE, more hours of work).
>
> If you are reading this, have detailed expertise with SCO, and can 
> provide objective references to materials which corroborate your 
> diagnosis, analysis, or terminology (IE, URLs), I'd like to discuss 
> either leveraging off of your expertise, or handing this off to you, 
> entirely, so that the customer - poor wretches, they are underpaid, 
> overeducated financial and statistical analysts trapped in a world of 
> high finance but receiving only crumbs for their economic labors ... 
> they have more in common with systems administrators then they do with 
> financiers - can have their computer back, working reliably, their 
> faith in UNIX (dare I say it?) restore(8)'d.
>
> (-:
>
> Thanks in advance,
>
>
> -- richard
>
> Richard Childers / Senor Engineer
> Daemonized Networking Systems
> https://www.daemonized.com
> (415) 759-5571
>
>
>
> ---------------------------------------------------------------------------- 
>
> You have received this message via the baylisa-jobs at baylisa.org 
> mailing list.
> For questions or comments regarding list admin, email 
> postmaster at baylisa.org.
>