special files screw up

[Martin Johnson]

I recently recovered a system from an ignite tape and a frecover. I noticed that SAM does not display any logical volumes from /dev/vg00. A vgdisplay gives the following errors:

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c3t2d0":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.

A ioscan -fn shows:

disk 1 0/0/1/1.2.0 sdisk CLAIMED DEVICE SEAGATE ST318404LC
disk 2 0/0/2/0.2.0 sdisk CLAIMED DEVICE SEAGATE ST318404LC
/dev/dsk/c1t2d0 /dev/rdsk/c1t2d0
/dev/dsk/c3t2d0 /dev/rdsk/c3t2d0

Now, as I see it, I have 2 options. I can try to do "rmsf -H 0/0/2/0.2.0", followed by "insf -H 0/0/1/1.20;insf -H 0/0/2/0.2.0" or I can do a vgexport/vgimport of /dev/vg00. In the past, if I had problems with the vgexport/vgimport I lost all my data. So I am reluctant to do the export/import. Especially, I not sure of the validity of my backups.

Any suggestions?

Marty

[Pete Randall]

Hi Marty,

So all four disks were originally part of vg00? It looks like you have a problem with one of them. Can you do a diskinfo on /dev/rdsk/c3t2d0?

Pete

[Martin Johnson]

Pete,

diskinfo /dev/rdsk/c3t2d0
SCSI describe of /dev/rdsk/c3t2d0:
vendor: SEAGATE
product id: ST318404LC
type: direct access
size: 17783240 Kbytes
bytes per sector: 512
ttfux015# diskinfo /dev/rdsk/c1t2d0
SCSI describe of /dev/rdsk/c1t2d0:
vendor: SEAGATE
product id: ST318404LC
type: direct access
size: 17783240 Kbytes
bytes per sector: 512

NOTE: Disk 0/0/1/1.2.0 does not have any /dev/dsk/c?t?d? special files assigned to it. It is suppose to look like:

disk 1 0/0/1/1.2.0 sdisk CLAIMED DEVICE SEAGATE ST318404LC
/dev/dsk/c3t2d0 /dev/rdsk/c3t2d0
disk 2 0/0/2/0.2.0 sdisk CLAIMED DEVICE SEAGATE ST318404LC
/dev/dsk/c1t2d0 /dev/rdsk/c1t2d0

Marty

[Sridhar Bhaskarla]

Hi Marty,

Did you try vgcfgrestore on c3t2d0?. It's a matter of restoring vgID so that the system will recognize it back under vg00.

vgcfgrestore -n /dev/vg00 /dev/rdsk/c3t2d0
vgchange -a y vg00
vgsync
lvlnboot -v
(other lvlnboot commands if needed)

-Sri

[Pete Randall]

Marty,

OK, I was focusing on the "couldn't query physical volume " message. If it's a case of missing device files, why not try insf -e before you start removing any and see what that gives you?

Pete

[Sridhar Bhaskarla]

Hi,

I see your point now.

You could do a rmsf on the device file itself instead of the path to be safe.

rmsf /dev/dsk/c3t2d0
rmsf /dev/rdsk/c3t2d0

insf -e

vgchange -a y vg00

-Sri

[Martin Johnson]

Sridhar,

/dev/dsk/c3t2d0 is suppose to be assigned to 0/0/1/1.2.0. It is assigned to 0/0/2/0.2.0, which already has /dev/dsk/c1t2d0 assigned. I don't see how the vgcfgrestore will fix the incorrect special file assignments.

I am leary of just trying things, I don't want to end up with an unbootable system.

Marty

[Martin Johnson]

I'm cautious about using "insf -e" as it will modify some nonstandard special files on the system.

I'm considering the hardware path instead of "rmsf /dev/dsk/c3t2d0" to wipe the slate clean and start over manually with the insf.

Marty

[Sridhar Bhaskarla]

Marty,

What are the minor numbers of these two device files?.

ll /dev/dsk/c1t2d0
ll /dev/dsk/c3t2d0

Once you get rid of c3t2d0 device file, and recreate (either by mknod or insf -e)then your ioscan may find it good.

"The specified path..." sentence looked very familiar and I missed to notice your ioscan abnormality.

-Sri

[Martin Johnson]

The man page for rmsf states:

"Note that most drivers do not support the ability to be removed from
the system."

Is this true for the /dev/dsk/c?t?d? special files?

Marty

[Martin Johnson]

brw-r----- 1 bin sys 31 0x012000 Mar 6 17:54 c1t2d0
brw-r----- 1 bin sys 31 0x012000 Apr 8 2001 c3t2d0

[Sridhar Bhaskarla]

Hi Marty,

Another query that I missed. How are the instance numbers looking?.

ioscan -fnC ext_bus

If you see them as supposed to, then I would remove the device file for c3t2d0 and recreate it probably by hand with the correct instance number for 0/0/1/1 path since you have other non-standard device files. If 0/0/1/1 is not showing up the instance of 3, then it will be little more mess in which case you will have to change the instance or export/import the VG through LVM maintenance mode.

My feeling is that the device file somehow got mis-created. Recreating it may fix the problem provided the instances match the previous configuration.

-Sri

[Martin Johnson]

The rmsf worked, but the insf did not. Had to use mknod to create the special files.

Everything appears OK for now.

Marty