[OmniOS-discuss] 3ware LSI 9750-16i4e

[Jim Klimov]

17 февраля 2015 г. 0:44:59 CET, CJ Keist <cj.keist at colostate.edu> пишет:
>Hello,
>    Looking for anyone that might have used this raid controller card? 
>LSI web page states the raid controller is supported for OpenSolaris, 
>but I'm not having any luck getting OmniOS 151012 to see any defined 
>drives from the raid card.
>
>I've tried to install driver from LSI but get the following error:
>root at projects1:/root/install/intel/Solaris11# pkgadd -d .
>
>The following packages are available:
>   1  mrsas     LSI MegaRAID SAS 2.0 HBA driver
>                (i386) 6.602.03.00
>
>Select package(s) you wish to process (or 'all' to process
>all packages). (default: all) [?,??,q]:
>
>Processing package instance <mrsas> from
></root/install/intel/Solaris11>
>
>LSI MegaRAID SAS 2.0 HBA driver(i386) 6.602.03.00
>Copyright (c) 2008-2009, LSI Logic Corporation.
>All rights reserved.
>
>## Executing checkinstall script.
>pkgparam: ERROR: unable to locate parameter information for "mrsas"
>A previous instance of mrsas driver  found in the system.
>Use 'pkgrm mrsas' to remove the previous mrsas package and then do a
>pkgadd.
>checkinstall script suspends
>
>Installation of <mrsas> was suspended (administration).
>No changes were made to the system.
>
>Try to remove the SUNWmrsas package gets me this:
>
>root at projects1:/root# pkgrm SUNWmrsas
>
>The following package is currently installed:
>    SUNWmrsas  LSI MegaRAID SAS2.0 HBA Driver
>               (i386) 11.11,REV=2009.11.11
>
>Do you want to remove this package? [y,n,?,q] y
>pkgrm: ERROR: unable to change current working directory to 
></var/sadm/pkg/SUNWmrsas/install>
>
>Removal of <SUNWmrsas> failed (internal error).
>No changes were made to the system.
>
>
>Anything I'm missing here?

A couple of things pop out. 

One is that failures are usually programmatic, i.e. due to tests or other actions in a pre- or post- install/remove scripts. You can inspect those (an SVR4 package is a glorified cpio archive containing the metadata files and ultimate packaged contents - maybe inlaid in a none.(gz,7z,...) archive. More scientifically, you can use pkgtrans to pack\unpack the package delivery formats, such as a single file, a directory, etc. With some handywork (also fixing pkginfo with its cksum-based checksums), you can instrument the pre\post scripts with set -x to trace and repackage, to see what does not work why during an actual installation. 

It may be that uninstallation fails due to poor legacy dependencies, e.g. if SUNWcs (~kernel) 'depends' on some driver packages like this storage, so you can't remove the old one, and a new driver package may consider itself to be in conflict with the old one. I'm enroute away from a computer now so can't say if this is still the case with illumos metadata. But if this is indeed the roadblock, you might need some pointier surgical tools or a larger hammer to add/remove the driver files and/or the packagjng system's perception of the package.

Also look in dmesg - probably some driver modules fail to attach or detach, although generally installation of a dormant driver into an OS image should not depend on actual presence of a device.

Oh, also you can clone and mount an alternate BE and use the pkgadd/pkgrm with -R to manipulate this other OS image, maybe then the hardware related checks would be more relaxed.

Finally, the 3wares i knew (before they were bought by lsi) were using a chip and firmware of their own. I did not use the later products, but if they are not just a rebrand of mainstream lsi with another known brand - double-check that you need an lsi/megaraid driver or some other after all.

HTH,
Jim Klimov
--
Typos courtesy of K-9 Mail on my Samsung Android