SUMMARY: probe-scsi-all sees LUNs but Solaris doesn't and no it's

Hello All,

     First off, thanks to all who took the time to reply to my post:  "sunsa_tx", Neezam Haniff, Darren Dunham, Anthony D`Atri, Matthew Stier, Zion Huang, Jeremy Ahl, and Kermit Nix.

     The problem was that the Eonstor storage arrays were connected to the 420R via UltraSCSI 3 cards and neither Solaris 8 or 9 includes the appropriate drivers by default in the base OS install.  They must be downloaded from Sun's web site.  I must confess to feeling a bit stupid right now, as I have many times added drivers for external storage arrays.  However, they were always for Fibre Channel arrays.  This is the first time I've encountered a plain vanilla SCSI array for which I had to add drivers.

     Special thanks to Jeremy for not only recognizing that I needed to add the drivers, but specifying which drivers (SUNWqus*) I needed.

Kevin

Original Post:
>
> 
> Hello All,
> 
>      Short version of my question first:  I have a 420R with 3 Eonstor storage arrays connected via dual-channel PCI SCSI cards.  I can see them at the "ok>" prompt via probe-scsi-all.  However, I cannot get Solaris to see them or create device files for them, *EVEN AFTER* I have done multiple "boot -r", "devfsadm", "drvconfig; disks", verified /kernel/drv/sd.conf, etc., etc., etc.,
> 
>      More details (very long):  we actually have 2 identical 420R's.  One is our production NFS home directory server, the other is a cold standby machine.  Yesterday morning the production 420R died (we think motherboard).  We swapped 420R's, attached the 3 Eonstor storage arrays (which were working great on the production 420R), restored the appropriate files from backup (i.e. /etc/system, /kernel/drv/sd.conf, /etc/vfstab, /etc/dfs/dfstab, etc.), changed the hostnames appropriately (we've got a quad gig-ethernet card both of them), and rebooted (with -srv).
> 
>      The standby machine didn't see the LUNs on the Eonstor's.  A quick "probe-scsi-all" at the "ok>" prompt showed all the appropriate LUNs.  We booted again (with "-r" - every single time we booted we used "-r").  No luck.  Ran "drvconfig; devlinks", no luck.  Ran "devfsadm", no luck.
> 
>      Then we took a look at /etc/path_to_inst.  It does not contain the appropriate entries for the Eonstor LUNs.  I found Sun InfoDoc 15019 on deleting and recreating path_to_inst.  Followed the instructions exactly (except for step #1, which is wrong - you must rename the existing path_to_inst to something that doesn't *begin* with path_to_inst, and step #2, which was unnecessary since the device files weren't there anyway) and it created a new /etc/path_to_inst identical to my old one.
> 
>      We also tried numerous variations of "cfgadm", again, all with no luck.
> 
>      I have never in 14 years of working with Sun hardware seen a box that could see SCSI disks via probe-scsi-all but wouldn't see them at the Solaris level after doing what we've done.
> 
>      We ended up pulling the internal disks from the (dead) production 420R and put them in the standby machine and everything came up and we could see the Eonstor LUNs.  However, this is not an optimal solution, since those disks are not mirrored (and cannot be due to the way the original admin partitioned them).  The disks in the standby 420R were mirrored.
> 
>      The only other difference between the two systems is that the standby machine has a slightly later "recommended patch cluster" installed (by about 2 months).
> 
>      We are up and running.  I have downtime next week when I can try out any suggestions you all might have for getting the other disks to see the Eonstor LUNs.
> 
>      If the answer is somewhere I should have already found it, please feel free to beat me up, as I have searched the archives, Sunsolve, Google, etc., without finding it and therefore must have missed it.
> 
>      Thanks all...
> 
> Kevin Buterbaugh
> 
> "Unix is the worst operating system in the whole world, except for all the rest."
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers