OT: redhat

[Bill Vermillion]

When asked his whereabouts on Sun, Nov 14 17:18 , Brian K. White took the 
fifth, drank it, and then slurred: 

> 
> ----- Original Message ----- 
> From: "Bill Vermillion" <fp at wjv.com>

....

> >I was looking at the Novell manual a friend had for taking her
> >Novell certification.  It mentioned how SCSI booting from drive 0
> >except for IBM which did it the wrong way.

> >In actuallity IBM was the only one who did it correctly.  As much as
> >anyone decries the IBM ways they do adhere to design specs and
> >implementations to the letter.  And most of the HD improvements
> >that have been made - going back for 50 years - have been from IBM.

> >The only other problems I've read that others have had are the
> >ordering of the SCSI controllers if you have more than one.

> That's what I just ran into on my sco box. It didn't slow me
> down for longer than it takes to do one reboot - kernel link
> - reboot because I just happen to be familiar enough with the
> process, but given what exactly I had to do I can imagine this
> being a real nightmare for someone hitting it and not already
> knowing what to do.

> I have 2 raid cards that use the same driver, but they are not
> identical and one specifically must be the boot drive because
> one is a one-channel and one is a two-channel and the main
> (booting) raid array spans both channels of the two-channel.

> So, I discover recently that the vendor had not installed the
> cards into the slots I wanted (to make the best use of the
> single 133mhz 64bit slot) and I had to move the two cards into
> different slots, and sure enough adapter0 and adapter1 swapped
> places and the kernel can't find it's root fs on "adapter0,
> bus0, id0, lun0" and halts.

> The fix is: at the "boot:" prompt, where you normally type
> nothing, tell it that the root is on adapter 1 boot: defbootstr
> Sdsk=amird(1,0,0,0) then it boots up normally except that it
> fails to mount the extra fs that used to be on adapter1 that
> is now on adapter0 of course, and it's a temporary change only
> lasting the duration of this boot. (you can make boot: options
> permanent by adding them to a certain file but that is not the
> best fix here)

Having to use boot strings and having to relink kernels to add
SCSI devies like yoy had to do that shows how creaky the OSR5 has
become.  That part of what you get with an SvR3, while all the SvR4
systems I've used all dynamically found the SCSI devices when you
added them.  That's why I liked Unixware when I first came to it.

As as to the boot string - in one instance where the device for
ID 0 could be turned on or off so that the first drive seen would
be the boot drive, I'd put the SCO on ID 1.  I've seen mention so
often that SCO >must< boot form ID0 - but if you set the boot
string properly at installation time - there is no problem.  What
is misleading is if there is no drive 0, and you install on the
first drive the controller sees, it will install, but it will not
boot because the default wants to find drive 0.  You have to set
that up at install time.   

You shouldn't have to know so much to install on OS - but that's
how things used to be done.  

> cd /etc/conf/cf.d
> vi mscsi and swapped the order of these two lines:
> amird   Sdsk    0       0       0       0
> amird   Sdsk    1       0       0       0
> so that they say this
> amird   Sdsk    1       0       0       0
> amird   Sdsk    0       0       0       0
> then ./link_unix,
> reboot and now it's all working again.

And how many SCO users would have looked at the system and not had
a clue on how to fix this.  I've seen 'authorized dealers' who 
didn't undestand this.

> Only took a few seconds but it's only because I just _happen_
> to have played with this a lot. I don't beleive that is very
> directly documented anywhere and I beleive if I had to search
> for the answer fresh right now It'd take a long time and I'd
> probably do a lot of things along the way that don't help,
> possibly hurt. I can easily imagne this being a restore from
> tape and let a supertar do the black-magic.

It may have been in the release notes. I do know that Bela has
covered this in the c.u.s.m group - but it is obscure. Your
clients are lucky to have you. I've had to go and fix things
as I'm sure you have also. At one former SCO client = moving
to a specialty app on NT - I lost out on getting the job at
first because another person had recommended some 'pros from
Jacksonville'. They came down and spent two days and gave up.
All of the answers to their problems was in the documentation - but
maybe they couldn't read. ;-)

Bill

-- 
Bill Vermillion - bv @ wjv . com