disk replacment, SUN M3000

we have a SUN M3000 server.
setup as only 1 domain.

disk c0t0d0 and c0t1d0 and setup as SVM mirrors.

a few days ago disk T1 failed.
new we have replaced the disk, but can's see the disk in format.

have done cfgadm and devfsadm.
still can't access the new disk in format.

the output of some command that maybe of help...

# uname -a
SunOS server_name 5.10 Generic_144488-08 sun4u sparc SUNW,SPARC-Enterprise

# cfgadm -al
Ap_Id                          Type         Receptacle   Occupant     Condition
SB0                            System_Brd   connected    configured   ok
SB0::cpu0                      cpu          connected    configured   ok
SB0::memory                    memory       connected    configured   ok
SB0::pci0                      io           connected    configured   ok
SB0::pci1                      io           connected    configured   ok
SB0::pci8                      io           connected    configured   ok
c0                             scsi-sata    connected    configured   unknown
c0::dsk/c0t0d0                 disk         connected    configured   unknown
c0::dsk/c0t1d0                 disk         connected    configured   unknown
c0::dsk/c0t2d0                 disk         connected    configured   unknown
c0::dsk/c0t3d0                 disk         connected    configured   unknown
c0::dsk/c0t4d0                 CD-ROM       connected    configured   unknown
c1                             fc-fabric    connected    configured   unknown
c1::50001fe1500d1f78           array-ctrl   connected    configured   unknown
c1::50001fe1500d1f7c           array-ctrl   connected    configured   unknown

# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c0t0d0 <FUJITSU-MBD2147RC-3701 cyl 14087 alt 2 hd 24 sec 848>
          /pci@0,600000/pci@0/pci@0/scsi@0/sd@0,0
       1. c0t2d0 <FUJITSU-MBD2300RC-3701-279.40GB>
          /pci@0,600000/pci@0/pci@0/scsi@0/sd@2,0
       2. c0t3d0 <FUJITSU-MBD2300RC-3701-279.40GB>
          /pci@0,600000/pci@0/pci@0/scsi@0/sd@3,0
       3. c1t50001FE1500D1F7Cd1 <HP-HSV200-6240-25.00GB>
          /pci@1,700000/pci@0/pci@9/SUNW,qlc@0/fp@0,0/ssd@w50001fe1500d1f7c,1
       4. c1t50001FE1500D1F78d1 <HP-HSV200-6240-25.00GB>
          /pci@1,700000/pci@0/pci@9/SUNW,qlc@0/fp@0,0/ssd@w50001fe1500d1f78,1
Specify disk (enter its number): ^D

what magic is needed to make Solaris access the disk?

50K bits to anyone who can solve this problem.

what is the output of:

raidctl -l

?

# raidctl -l
Controller: 0
        Disk: 0.0.0
        Disk: 0.1.0
        Disk: 0.2.0
        Disk: 0.3.0
# 

the disk on target 1 is visible... have you tried a

# devfsadm -Cv
# devfsadm -v

?
if this won't work, you might need a reconfigure boot...

# touch /reconfigure
# init 6

the devfsadm dident help.

need 24 hours to arrange a reboot....

strange... are there entries in /dev/dsk/... for the disk?

1 Like

yep, that all looks good.

$ pwd
/dev/dsk
$ ls
c0t0d0s0                 c0t1d0s6                 c0t3d0s3                 c1t50001FE1500D1F78d1s1
c0t0d0s1                 c0t1d0s7                 c0t3d0s4                 c1t50001FE1500D1F78d1s2
c0t0d0s2                 c0t2d0                   c0t3d0s5                 c1t50001FE1500D1F78d1s3
c0t0d0s3                 c0t2d0s0                 c0t3d0s6                 c1t50001FE1500D1F78d1s4
c0t0d0s4                 c0t2d0s1                 c0t4d0s0                 c1t50001FE1500D1F78d1s5
c0t0d0s5                 c0t2d0s2                 c0t4d0s1                 c1t50001FE1500D1F78d1s6
c0t0d0s6                 c0t2d0s3                 c0t4d0s2                 c1t50001FE1500D1F7Cd1
c0t0d0s7                 c0t2d0s4                 c0t4d0s3                 c1t50001FE1500D1F7Cd1s0
c0t1d0s0                 c0t2d0s5                 c0t4d0s4                 c1t50001FE1500D1F7Cd1s1
c0t1d0s1                 c0t2d0s6                 c0t4d0s5                 c1t50001FE1500D1F7Cd1s2
c0t1d0s2                 c0t3d0                   c0t4d0s6                 c1t50001FE1500D1F7Cd1s3
c0t1d0s3                 c0t3d0s0                 c0t4d0s7                 c1t50001FE1500D1F7Cd1s4
c0t1d0s4                 c0t3d0s1                 c1t50001FE1500D1F78d1    c1t50001FE1500D1F7Cd1s5
c0t1d0s5                 c0t3d0s2                 c1t50001FE1500D1F78d1s0  c1t50001FE1500D1F7Cd1s6

$ cd ../rdsk
$ ls
c0t0d0s0                 c0t1d0s6                 c0t3d0s3                 c1t50001FE1500D1F78d1s1
c0t0d0s1                 c0t1d0s7                 c0t3d0s4                 c1t50001FE1500D1F78d1s2
c0t0d0s2                 c0t2d0                   c0t3d0s5                 c1t50001FE1500D1F78d1s3
c0t0d0s3                 c0t2d0s0                 c0t3d0s6                 c1t50001FE1500D1F78d1s4
c0t0d0s4                 c0t2d0s1                 c0t4d0s0                 c1t50001FE1500D1F78d1s5
c0t0d0s5                 c0t2d0s2                 c0t4d0s1                 c1t50001FE1500D1F78d1s6
c0t0d0s6                 c0t2d0s3                 c0t4d0s2                 c1t50001FE1500D1F7Cd1
c0t0d0s7                 c0t2d0s4                 c0t4d0s3                 c1t50001FE1500D1F7Cd1s0
c0t1d0s0                 c0t2d0s5                 c0t4d0s4                 c1t50001FE1500D1F7Cd1s1
c0t1d0s1                 c0t2d0s6                 c0t4d0s5                 c1t50001FE1500D1F7Cd1s2
c0t1d0s2                 c0t3d0                   c0t4d0s6                 c1t50001FE1500D1F7Cd1s3
c0t1d0s3                 c0t3d0s0                 c0t4d0s7                 c1t50001FE1500D1F7Cd1s4
c0t1d0s4                 c0t3d0s1                 c1t50001FE1500D1F78d1    c1t50001FE1500D1F7Cd1s5
c0t1d0s5                 c0t3d0s2                 c1t50001FE1500D1F78d1s0  c1t50001FE1500D1F7Cd1s6

---------- Post updated at 02:03 PM ---------- Previous update was at 01:51 PM ----------

so we opened a call with Oracle/SUN.

they asked for an explorer.
we ran that, and now it works.

note that the dev listing I gave a few minutes ago, was AFTER we run the explorer.

it was Oracle that noticed that we dident have the dev/dsk.
but a few seconds into the run of the explorer the /dev/dsk magically turned up.

one of the strangest bugs I have seen....