This turned out to be deceptively simple in the end!
After raising a call with Sun and then applying all the patches
(probably a good thing :) it turned out to be a kernel driver problem.
I noticed that the E5000 had ssd drivers (SSA) set to force load,
and that these were used later when SDS database parameters were set.
I then checked another system and found the sd (SCSI disk) driver
was set to forceload. I put this to the Sun engineer and he agreed that was
most likley! He advised to put it in before the SSA driver.
eg, from /etc/system
forceload: drv/sd
forceload: drv/ssd
All fixed!
I of course have *no idea* why the driver didn't install when the
diskboard was first commisioned. But all is well that ends...;-)
Thanks to everyone who offered advice.
>Date: Tue, 09 Jun 1998 20:44:09 +0900
>To: sun-managers@sunmanagers.ececs.uc.edu
>From: David Robson <robbo@box.net.au.>
>Subject: SUMMARY:Corrupting SDS replicas on reboot
>
>Disappointingly few replies. :-(
>
>My only reply was from shobhit@mindless.com. Shobhit mentioned that SSA
drivers need to load before SDS drivers, which makes sense, but doesn't
seem relevant since we have no problems with the SSAs.....
>
>My mention of diskboards may have confused the issue. The diskboards are
essentialy just a means of mounting normal FW SCSI disks in a system that
has no other way of mounting normal SCSI disks.
>The placement of additional replicas is the most important use of these
disks.
>
>I have rebuilt these slices, this time selecting 2MB (2 cylinders). It
didn't fix
>the problem, and Sun now say to have at least 3 cylinders. This seems odd as
>a replica only needs about 600KB (I'm told).
>
>Since we can't reboot "willy-nilly" it would be nice to know the specific
requirement. I will try Sun's latest suggestion and let you know how it
turns out.
>Meanwhile any futher info would be appreciated... ;-)
>
>My post:
>We have two E5000's configured almost identical:
>Solaris 2.5.1
>2 x SSA
>1 x 4GB diskboard
>Solstice DiskSuite 4.1
>Patched to recomended set as of January this year.
>
>The issue is with replica databases on the diskboard.
>For those not familiar, the diskboard has 2 x 2.1GB disks. This slides
into the
>chassis like a CPU board and then plugs into one of the FW SCSI ports. The
>only reason we have this board is so that we have a third controller with
>additional replicas to break the "stalemate" should a SSA be down and the
>system is rebooted.
>I partioned these drives with a 1mb on slice 6 and the rest on slice 0.
>I then used metadb -a to add a replica to each disk on slice 6. That worked
>fine until the system rebooted.
>I found that the new replicas had gone into maintenace. So, I recreated them
>this time I noticed from metadb -i that these replicas were not patched
into the
>kernel.
>With some repeated attempts I got the patch to occur. However on the next
>reboot the replicas were in maintenance again, this time with a "M"
signifying
>start block problems! :-(
>Sun have not given me a answer for this and have suggested allocating more
>cylinders to slice 6.
>Can anyone help?
>
-- David Robson robbo@box.net.au Davtin Systech Pty Ltd
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:43 CDT