/etc/lvmtab contains strange entry

[rodney.hee]

Hi, I've been having problems with a EVA RSM job that snapshots a HP-UX drive from one system and mounts to another.

The RSM software complains it can't vgimport the snap volume to the second system.

I ran a "strings /etc/lvmtab" and received the following output -

/dev/vg00
/dev/dsk/c1t0d1
/dev/dsk/c3t0d1
/dev/vg01
Ee2R
/dev/dsk/c1t0d2
/dev/dsk/c1t0d6
/dev/dsk/c1t1d1
/dev/dsk/c3t0d2
/dev/dsk/c3t0d6
/dev/dsk/c3t1d1
/dev/vg02
/dev/dsk/c1t0d3
/dev/dsk/c1t0d7
/dev/dsk/c1t1d2
/dev/dsk/c3t0d3
/dev/dsk/c3t0d7
/dev/dsk/c3t1d2
/dev/vg03
/dev/dsk/c1t0d4
/dev/dsk/c1t0d5
/dev/dsk/c3t0d4
/dev/dsk/c3t0d5
/dev/vg04
/dev/dsk/c1t1d0
/dev/dsk/c3t1d0

It is the entry "Ee2R" I am concerned about. I have never seen this one before and am wondering if this has something to do with my vgimport problem to the other system.

I have attempted to rebuild the lvmtab file but the entry remains after a "vgscan -av".

I welcome any thoughts.

[Dennis Handly]

Instead of strings(1), what does "vgdisplay -v" show?

strings(1) just prints out any old random printable chars and it is not the right tool for formatting /etc/lvmtab but it just may be good enough.

[Johnson Punniyalingam]

try removing the corrupted /etc/lvmtab.

mv /etc/lvmtab -> /etc/lvmtab.corrupted


then issue the

vgscan -v


BEFORE doing this, apart from a valid backup, check if you have any file under /dev/ with minor "64". I remember an old bug, where a cmcluster could create such a file in /dev/ corrupting all.

Thanks,
Johnson

[James R. Ferguson]

Hi Darren:

As Dennis hinted, there is _no_ indication from simply doing 'strings /etc/lvmtab' that it is corrupt!

The '/etc/lvmtab' is a binary file and contains both printable ASCII strings (obviously) but also LVM VGID information. The entry "Ee2R" just _happens_ to be a sequence of bits that map to printable ASCII characters.

Doing a 'vgscan' after remaining your '/etc/lvmtab' file may not change anything. If you elect to try this BE SURE TO READ and follow the 'vgscan' manpages. There are more things to do than just rename '/etc/lvmtab' and perform the 'vgscan'.

Regards!

...JRF...

[Avinash20]

You could ignore this..

for better explanation please refer to

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1234633593769+28353475&threadId=1183100

Please dont forget to assign points :)

[Avinash20]

Also one more

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1234633602484+28353475&threadId=1030478

[sujit kumar singh]

hi


/etc/lvmtab is a binary file.
it simply does not means that it cannit have other alphanumeric characters.

these are some of the alphanumeric strings that are there in the lvmtab.

so no need to worry for that.



this does not at all means in anyway also that the lvmtab is corrupt.

if lvmtab has got any information that seems to be inaccurate about the VGs, try doing a vgchange -a y on that VG, that shall give idea about the VG and its relation with the lvmtab, or you shall get direct messages that lvmtab is corrupt.


regards
sujit

[rodney.hee]

Thanks for all the replies. I have run a vgdisplay -v and the output is all clean.

I tried the vgchange command and again this completed successfully.

The explanations of the characters appearing via the strings command makes sense thanks.

I'll have to investigate further as to why my RSM job is not working correctly. The output from RSM is not very informative unfortuantely and just complains about not being able to complete a vgimport command on the system the job is mounting the snapshots onto.

If anyone has any experience with rsm snapshot jobs I welcome the feedback.

Points assigned for this round.

[rodney.hee]

Here is the output from my RSM job -

create host volume failed; The error from the host is 'parm1=Volume group /dev/vg01_RV3 failed to create: vgimport: Cannot open the control
file "/dev/vg01_RV3/group". No such device.

The RSM job appears to create the directory structure and the group file, but there is no entry from lvol1. When I do a vgdisplay it has no entry for the new group vg01_RV3.

My other two systems that use identical jobs work fine.