[plug] Re: new kernels don't like scsi controller

Paul Antoine pma-la at milleng.com.au
Tue Apr 1 18:02:33 WST 2008

I remember having several similar issues with RAID cards a while back. 
In the end I discovered that Mandriva's install disks seemed to be the 
most forgiving for an HP server.

In other instances I have had cards play badly with various 
motherboards.  In particular some cards seem very slot-position 
dependent or unhappy with other cards installed at all! In such cases I 
have found upgrading the BIOS on the RAID/SATA etc. card in question 
works wonders.  Most recent of these was a SATA card that hated my HDTV 
tuner card and/or some motherboards. It would work better, though not 
reliably in some slots... sigh. After much searching a new BIOS forcibly 
flashed made it play nice :-)

You're on the right path re persistent storage names.  I also find that 
using UUID's for both software RAID devices in mdadm.conf and filesystem 
partitions in /etc/fstab gets around much heartache when you forget 
which sata/scsi positions you used on setup :-)


Gavin Chester wrote:
> On Tue, 2008-04-01 at 16:38 +0800, Gavin Chester wrote:
>> On Tue, 2008-04-01 at 15:52 +0800, Gavin Chester wrote:
>>> What I'm hoping from you good people is some leads as to why this
>>> might
>>> be happening, and confirmation that swapping back in the lsi scsi
>> card
>>> after os install will work. 
>> Ok, I've answered that 2nd part: the system won't boot after replacing
>> the scsi card - despite a successful os install with the slower,
>> alternative card :-( The card recognises and allocates addresses to
>> the
>> two u320 drives at boot, but then suse reports "waiting for
>> device /dev/disk/by-id/scsi-yadayada-part3 to appear .... not found -
>> exiting to /bin/sh"  
>> Now that's a big bummer - I want/need the u320 speeds, rather than the
>> u160 offered by the older card :-( 
> Ok, I am in danger of making too much noise here ;-) After posting off
> the last message I googled and found reference to this support issue to
> do with the use of persistent storage device names (beware wrap):
> http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3048119&sliceId=SAL_Public 
> If I can manage to follow the process maybe, maybe I'll be in action.
> Fingers crossed.
> Gavin
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au

More information about the plug mailing list