From: Kevin Buterbaugh (kevin_buterbaugh@bellsouth.net)
Date: Thu Dec 02 2004 - 15:40:45 EST
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
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:29:49 EDT