unconfigure using cfgadm

Hi,

One of 2 local disks on V480 running solaris 10 and SVM failed.

Now after running metadettach for submirrors on that disk, I want to unconfigure the FAULTY disk using cfgadm -c uncofigure command..and then put new one and configure that.

but surprisingly I don't see local dsk in cfgadm -al output

iostat -En shows the disks

format

c2t1d0 is failed drive.

Do I need to unconfigure drive really ? or I can just shut the machine down, take faulty one out and put the new one and reboot..I wonder if cfgadm configure will be required in this case..

Also there is VXVM and Sun cluster configured on this machine.

This is my plan of action

Any ideas...

I'm not sure what you are asking here.

Both of the local disks that show up in format also show up in cfgadm.

Thank you for reply, question is how to unconfigure disk from solaris 10. ( failed disk was part of SVM mirror)

If you see format closely,

that is not normal and it was clear from metastat output that c2t1d0 had write errors.

It is mentioned somewhere that one has to unconfigure using cfgadm -c faulty disk and then put new one and then do meta attach. if this(cfgadm unconfigure / configure) step is not rquired then I don't care.

I am not able to do this step

In this case

c2::2100000087140f53 is your attachment point ( look at the path on the line after the disk name and compare the identifiers )

correct but then when I try,

You can skip the cfgadm unconfigure step and proceed to pull out the disk. Nothing would happen. just run devfsadm -C after you pull out and after you put in new disk and cont with your steps.
usually cfgadm is used for scsi disks. V480 uses fcal disk if im not wrong.

Also, this is not looking good though
0. c0t5006016041E033A8d0 <drive type unknown>
/pci@8,700000/SUNW,qlc@3/fp@0,0/ssd@w5006016041e033a8,0

Thank you very much Incredible, you sure are incredible :slight_smile:

Your reply filled me with me confidance, I am going to proceed with these 2 steps tomorrow morning. :b:

Yes, you are right but this one being from SAN which I am not intending to use for my storage, I will leave her alone :slight_smile:

Thanks again,

Good day.

Any updates? Was the disk replacement successful?

Will do this replacement in 3 hours. Haven't got the new disk yet. By the way do you think I must run :

while removing this failed disk? and after installing the new one label it using format. Or just go according to my steps mentioned in my first post in this thread with the addition of devfsadm -C command and not using cfgadm..

Thanks!

You can try using luxadm command, the rest of the steps, you can still continue follow your action plan

Command not working,

just pull out the device should be removed from the device tree, offlines it, and possibly even powers the device down.
After executing 'luxadm -e offline <devicename>', verified the disk didn't show in 'luxadm inq c?t?d?s2' or format. We then executed devfsadm -C to clear the devices from the /dev device list. Follow your steps

Thanks for your timely inputs!

I did go ahead and pulled out the drive. I did not try the luxadm -e offline command which I should have probably.

Put the new disk in , ran devfsadm -C

saw the new disk in format, then went ahead with my steps.

following command did not run properly,

wonder why?

Other steps went fine and Sync is now done, checked with metastat too.

iostat -En still shows the old HITACHI DISK :smiley:

but I don't see any error messages on system console and it also showed DISK Okay immediately after putting new disk. I feel the old drive information might go away after rebooting but I do not really want to do this at this time.

luxadm inq /dev/rdsk/c?t?d?s2

INQUIRY:
Physical Path:
/devices/pci@8,700000/ide@6/sd@0,0:c,raw
Vendor: TOSHIBA
Product: DVD-ROM SD-C2612
Revision: 1011
Serial Number Unsupported
Device type: 0x5 (CD-ROM device)
Removable media: yes
ISO version: 0
ECMA version: 0
ANSI version: 0 (Device might or might not comply to an ANSI version)
Response data format: 2
Additional length: 0x5b
VENDOR-SPECIFIC PARAMETERS
Byte# Hex Value ASCII
36 30 34 2f 31 37 2f 30 32 00 00 00 00 00 00 00 00 04/17/02........
00 00 00 00 ....

INQUIRY:
Physical Path:
/devices/pci@9,600000/SUNW,qlc@2/fp@0,0/ssd@w2100000087151713,0:c,raw
Vendor: HITACHI
Product: DK32EJ72FSUN72G
Revision: 2Q09
Serial Number 40W1F62F0045P39M0687
Device type: 0x0 (Disk device)
Removable media: no
Medium Changer Element: no
ISO version: 0
ECMA version: 0
ANSI version: 3 (Device complies to SCSI-3)
Terminate task: no
Response data format: 2
Additional length: 0x8b
Cmd received on port: b
Command queueing: no
VENDOR-SPECIFIC PARAMETERS
Byte# Hex Value ASCII
52 00 00 00 00 ....
96 43 6f 70 79 72 69 67 68 74 20 28 43 29 20 32 30 Copyright (C) 20
30 32 20 48 69 74 61 63 68 69 20 41 6c 6c 20 72 02 Hitachi All r
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

INQUIRY:
Physical Path:
/devices/pci@9,600000/SUNW,qlc@2/fp@0,0/ssd@w500000e019df5171,0:c,raw
Vendor: FUJITSU
Product: MAW3073FCSUN72G
Revision: 1303
Serial Number 000806B0PRMV DGN0P820PRMV
Device type: 0x0 (Disk device)
Removable media: no
Medium Changer Element: no
ISO version: 0
ECMA version: 0
ANSI version: 4Reserved
Terminate task: no
Response data format: 2
Additional length: 0x5b
Cmd received on port: b
Command queueing: no
VENDOR-SPECIFIC PARAMETERS
Byte# Hex Value ASCII
52 00 00 00 00 ....

Another problem I have to solve now is, this node was part of sun cluster (2 node) 'cluster status' still shows a disk fail,

I wonder if there are commands or steps to correct this device group information.

For information I am attaching vxdisk path outout from this system,

cfgadm -al

for Sun cluster, I ran the following commands on node with disk failure

Disk status is Ok now. :slight_smile:

Now I don't care what vxdisk path shows because I did not use VxVM to mirror these local disks.

Only thing bothers me now is old HITACHI in iostat -En

reboot is required to get it off.

Ahh, okay.

Thank you for helping me out. I appreciate your timely help.

Good day.