OT: redhat

[Brian K. White]

----- Original Message ----- 
From: "Bill Vermillion" <fp at wjv.com>
To: "filePro List" <filepro-list at seaslug.org>
Sent: Sunday, November 14, 2004 9:16 AM
Subject: Re: OT: redhat


> When asked his whereabouts on Sun, Nov 14 05:11 , Fairlight took the
> fifth, drank it, and then slurred:
>
>> When asked his whereabouts on Sun, Nov 14, 2004 at 12:19:46AM -0800,
>> Bill Campbell took the fifth, drank it, and then slurred:
>
>> > >That makes sense.  Does Linux still change the numbers if you
>> > >remove a drive in the middle - say you had 4 drives and removed one
>> > >- do the drives above the middle one get renumbered.  That used to
>> > >be a problem but I'm not that deep into Linux at the moment.
>
>> > I'm not sure what Linux does when a partition is removed, and
>> > I really didn't want to find out the hard way which is why I
>> > use LVM.
>
>> He said -drives- though. I think he's asking if it will change
>> /dev/sdd to /dev/sdc if you remove the original drive that was
>> found at /dev/sdc.
>
> At one time it did that.  And of course it's hda and hdb for the
> primary and secondary on the primary controller and hdc and hdd for
> the same on the secondary controller.
>
> When you add-in another controller those will typically be the next
> in line.  In one of my beasties the only HD is at ad4s - that is
> because the primary IDE controllers automatically ad0 through ad3.
>
>> I don't even know the answer to that. I haven't had occasion to
>> try. I don't think IDE will downshift, partly because I've seen
>> the primary on the secondary bus show up as /dev/hdc when there
>> were no HD's at hda and hdb. That's relatively flimsy evidence
>> though.
>
>> My guess is that they -will- downshift in SCSI. The only thing
>> it has to go by is ID and LUN. The devices aren't mapped
>> to those, but rather the lowest ID for a particular device
>> (sd*, scd*, st*, etc.). I'm thinking they'll probably shift
>> downwards. But then, so does Win9x. If I delete my (unused) D
>> partition on the middle drive, all my drive letter assignments
>> go to hell in Win95. I keep it there to make things sane. I ran
>> into issues with re-mapping the drives in win95, so I had to go
>> with this for some obscure reasons.
>
> The MS world has had problems with this since day one.  At least in
> XP you can lock the letter to the hardware, and you can re-order
> the cds, dvds, etc., to your liking so they don't come up in the
> order that MS seem to think is best.  That was one of the poorer
> design decisions by MS. {I use he word 'design' tounge-in-cheek'}
>
> And in the SCSI world you can specify which device you will boot
> from.  The problem with the early SCSI controllers is that they
> mimiced the MS world to boot from drive 0.
>
> Your boot device should realy be ID 6 as priority maps downward
> from 7 [the controller] to 0, then from 15 to 8, and 23 to to 16,
> and finally 31 to 24.   The saving grace as that none of the
> popular OSes had implemented SCSI properly so that's not a problem
> in the Intel based world.
>
> 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)

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.

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.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani