Character device errors

[Kwahae_1]

Running B.11.11 on an rp5740 with LVM. I cannot do sam disk info on one of my vgs. I have the following outputs frm various commands. What command can I use to fix the incosistences? Thanks

[Kwahae_1]

Sorry, forgot the command outputs:




SAM utility disk output
The Logical Volume Manager shows this device file, /dev/dsk/c18t0d0, ¦ ¦
¦ ¦ with hardware path, , as belonging to Volume Group, vgora. SAM has ¦ ¦
¦+-¦ determined that this hardware path is not currently active because ¦-+ ¦
¦¦ ¦ either the device is disconnected, or this is not the primary path to ¦ ^ ¦
¦¦ ¦ a multiple path physical volume. This results in incorrect disk ¦ ¦
¦¦ ¦ utilization information in the Disk Devices and Volume Group lists.


# ioscan -fnCdisk
Class I H/W Path Driver S/W State H/W Type Description
===========================================================================
disk 0 0/0/1/1.2.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC
/dev/dsk/c1t2d0 /dev/rdsk/c1t2d0
disk 1 0/0/2/0.2.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC
/dev/dsk/c2t2d0 /dev/rdsk/c2t2d0
disk 2 0/0/2/1.2.0 sdisk CLAIMED DEVICE HP DVD-ROM 305
/dev/dsk/c3t2d0 /dev/rdsk/c3t2d0
disk 3 0/1/0/0.3.0.0.0.0.0 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c29t0d0 /dev/rdsk/c29t0d0
disk 7 0/1/0/0.3.0.0.0.0.1 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c29t0d1 /dev/rdsk/c29t0d1
disk 4 0/1/0/0.3.1.0.0.0.0 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c31t0d0 /dev/rdsk/c31t0d0
disk 9 0/1/0/0.3.1.0.0.0.1 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c31t0d1 /dev/rdsk/c31t0d1
disk 5 0/10/0/0.4.0.0.0.0.0 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c33t0d0 /dev/rdsk/c33t0d0
disk 8 0/10/0/0.4.0.0.0.0.1 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c33t0d1 /dev/rdsk/c33t0d1
disk 6 0/10/0/0.4.1.0.0.0.0 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c35t0d0 /dev/rdsk/c35t0d0
disk 10 0/10/0/0.4.1.0.0.0.1 sdisk CLAIMED DEVICE DGC CX700WDR5
/dev/dsk/c35t0d1 /dev/rdsk/c35t0d1
# strings /etc/lvmtab
/dev/vg00
/dev/dsk/c1t2d0
/dev/dsk/c2t2d0
/dev/vgora
/dev/dsk/c18t0d0
/dev/dsk/c19t0d0
/dev/dsk/c26t0d0
/dev/dsk/c27t0d0
# vgscan -v -p
vgscan: The physical volume "/dev/dsk/c1t2d0" is already recorded in the "/etc/lvmtab" file.
vgscan: The physical volume "/dev/dsk/c2t2d0" is already recorded in the "/etc/lvmtab" file.
Couldn't stat physical volume "/dev/dsk/c3t2d0":
Invalid argument
Physical Volume "/dev/dsk/c29t0d1" contains no LVM information
Physical Volume "/dev/dsk/c31t0d1" contains no LVM information
Physical Volume "/dev/dsk/c33t0d1" contains no LVM information
Physical Volume "/dev/dsk/c35t0d1" contains no LVM information


/dev/vg00
/dev/dsk/c1t2d0
/dev/dsk/c2t2d0



/dev/vgora
/dev/dsk/c29t0d0
/dev/dsk/c31t0d0
/dev/dsk/c33t0d0
/dev/dsk/c35t0d0

#vgdisplay â v vgora
.vg other info then
..
--- Physical volumes ---
PV Name /dev/dsk/c18t0d0
PV Name /dev/dsk/c19t0d0 Alternate Link
PV Name /dev/dsk/c26t0d0 Alternate Link
PV Name /dev/dsk/c27t0d0 Alternate Link
PV Status available
Total PE 25596
Free PE 1
Auto
--- Physical volumes ---
PV Name /dev/dsk/c18t0d0
PV Name /dev/dsk/c19t0d0 Alternate Link
PV Name /dev/dsk/c26t0d0 Alternate Link
PV Name /dev/dsk/c27t0d0 Alternate Link
PV Status available
Total PE 25596
Free PE 1
Autoswitch On


--- Physical volume groups ---
PVG Name PVORA0
PV Name /dev/dsk/c18t0d0
PV Name /dev/dsk/c19t0d0switch On


--- Physical volume groups ---
PVG Name PVORA0
PV Name /dev/dsk/c18t0d0
PV Name /dev/dsk/c19t0d0

[Veera.Rao]

try #diskinfo /dev/rdsk/c0t0d0

or # diskinfo /dev/rdisk/disk123

[Aneesh Mohan]

Hi,

diskinfo -v /dev/rsk/c18t0d0

Aneesh

[Matti_Kurkela]

Your "vgscan -v -p" output indicates the PVs of the volume group vgora are now known as disks c29t0d0, c31t0d0, c33t0d0 and c35t0d0.

Has the connection between the server and the disks changed in some way? (For example, this might happen if a SAN switch has been changed and the new switch has not been configured *exactly* the same as the old one.)

Running vgscan without the -p option could be used to fix this, but rebooting to single-user mode would be required to do that safely... also it's a bit overkill.

This can be fixed by the standard VG export/import procedure while other VGs are being used normally:

1.) Identify the VG minor number:

ll /dev/vgora/group

The response should be like:

crw-r----- 1 root sys 64 0xNN0000 /dev/vgora/group

where NN is two hex digits. These digits can be different depending on your LVM configuration: remember them for now.

2.) Export the VG, creating a map file:

vgexport -v -s -m /tmp/vgora.map vgora

This can be done even if the VG is not accessible at the moment. Because the -s option is used, the command reads the binary VGID from /etc/lvmtab and writes it in readable form to the vgora.map file before deleting the VG configuration from /etc/lvmtab. The data on the disks is not harmed.

3.) Exporting the VG caused LVM to delete the /dev/vgora directory and the group device file. Re-create them:

mkdir /dev/vgora
mknod /dev/vgora/group c 64 0xNN0000

Use the same digits for NN as you discovered in step 1.

4.) Re-import the VG:

vgimport -v -s -m /tmp/vgora.map vgora

5.) Activate the VG and verify it's OK:

vgchange -a y vgora
(or if it's a Serviceguard cluster VG, use "vgchange -a e vgora" instead... but then, you probably would know this.)

vgdisplay -v vgora

6.) If the VG contains filesystems, mount them; if it contains raw databases, adjust the /dev/vgora/lvol* and rlvol* device ownerships and permissions appropriately to allow the database engine to access them directly.

7.) You're done!

MK

[Kwahae_1]

Thanks for the detailed /vgexport/vgimport procedure. Will try it after hours as this is a production machine:

The vg is available but with the wrong devices
/dev/vgora
/dev/dsk/c18t0d0
/dev/dsk/c19t0d0
/dev/dsk/c26t0d0
/dev/dsk/c27t0d0

Could you confirm that the vgexport/import procedure will replace above with

/dev/vgora
/dev/dsk/c29t0d0
/dev/dsk/c31t0d0
/dev/dsk/c33t0d0
/dev/dsk/c35t0d0 and that data will still be accessble on new devices. Jittery about losing data. New to LVM.

[Matti_Kurkela · Accepted solution]

Yes, that is exactly what the procedure will do.

"vgimport -s" makes the system search for components of the volume group identified by the map file, on all disks the system can access. Your "vgscan -v -p" has already done the same search, and produced the expected results. But the "-p" means "preview", so nothing was changed.

The vgscan command searches for *all* VGs the system knows about. Its man page recommends running vgscan (in non-preview mode) only when you have a catastrophic error. The vgexport/vgimport procedure is a way to do essentially the same thing restricted to one VG only, so it's safer.

Since you know what the device names will be, you can recover even if you happened to lose the map file mid-procedure: just change the vgimport command in step 4) to omit the '-s' option and list all the PV paths.

vgimport -v vgora /dev/dsk/c29t0d0 /dev/dsk/c31t0d0 /dev/dsk/c33t0d0 /dev/dsk/35t0d0

However, it's easier and more reliable to do it with the map file if you have a large number of disks in your VG.

This procedure is very well-known to administrators of HP-UX systems connected to SANs. A very slight variation of it is the standard procedure in setting up cluster volume groups for Serviceguard.

MK

[Kwahae_1]

Thanks MK for the explanation. Will carry out the procedure after a backup.