lvmtab ascii char ?

[TrustNo1]

Reason for concern here is SAM gave an error while creating the volume groupW/pvg's.
I deleted the vg, recreated manually. I've exported/imported, but I'm still seeing ascii chars in my lvmtab file while using STRINGS. ie:
/dev/vg02
Q?pj}
/dev/dsk/c0t2d0
/dev/dsk/c1t2d0
Clay mentioned "This is almost certainly okay. You have to remember how strings decides that something is a string. If it finds 3 or more consecutive printable ASCII characters, it considers that a string. It appears that you just happened to get lucky and have some binary data that encoded as printable ASCII."

I have done a vgscan -a (after moving lvmtab)
The output from both is attached.

~jdk

[Pete Randall]

jdk,

This should be of no concern, as Clay said. My lvmtab shows a remarkable similar result:

strings /etc/lvmtab
/dev/vg00
~0;TMm
/dev/dsk/c1t6d0
/dev/dsk/c1t5d0

Unless you're experiencing some difficulty, I wouldn't worry about it.


Pete

[Patrick Wallek]

I concur with Pete. My /etc/lvmtabs also show similar behavior when viewed using 'strings'. As Clay said it is normal. If everything is working "Don't Worry, Be Happy!"

[A. Clay Stephenson · Accepted solution]

I still see no reasons for concern with lvmtab, per se. This is almost certainly normal. Of more concern is the error that SAM gave while doing the vgcreate. It would have been far more helpful to post the entries for /var/sam/log or better still go through all the steps manually and note any error messages or non-zero return status values.

[Umapathy S]

jdk,
Same with me also. I am also getting some printable binary data.

-Umapathy

[Kevin Wright]

This is normal when you do a strings on /etc/lvmtab. Inside the lvmtab, there are the disk device files, and also the VGID's, which in some cases will return something when you run strings against it.

[Steven E. Protter]

My /etc/lvmtab file has the same thing.

I'm attaching a script that reads the file and checks the disks in it. This script can be easily modified to provide cleaner output from /etc/lvmtab

SEP

[TrustNo1]

Although I trust you guys with my ca-rear (no typo), I'm a paranoid sort...that's why I gave Clay 10 !

Attached is the sam error..
Thank you, ~jdk

[Pete Randall]

jdk,

I can't see the error that caused the vgextend command to fail. Could you just cut and paste that portion?


Pete

[Jakes Louw]

I bet that if you first do a manual "pvcreate -f" that the vgextend from SAM will work.
If it does, I'll tell u y :->

[TrustNo1]

Pete,
I think it's here but I'll attach more of the log;
Entering Task Manager with task fs_vg_extend.
@!@2@1064331305@0
Performing task "Extend a volume group.": Volume group vg02 is being extende
d with /dev/dsk/c1t2d0.
@!@2@1064331305@0
Executing the following command:\C/sbin/vgextend -g mirror2 /dev/vg02 /dev/ds
k/c1t2d0\C
@!@2@1064331306@0
Command completed with exit status 1.
@!@16@1064331306@0
vgextend failed.

Jakes, I did do a pvcreate but not -f, it worked though. Are you thinking old lvol header info?
~jdk

[Pete Randall]

jdk,

I still don't see the "stderr output from the vgextend command". I was just curious to see if there was an actual error that would tell us why vgextend failed. It's possible that SAM didn't record the error, I guess.


Pete

[TrustNo1]

Thanks for checking that out Pete, I didn't see any reason for it either, but you never know what another set of eyes can see!
I now accept the ascii char answer, and believe everything is OK. (still a little cringing)
Recently we've been moving alot of disk etc. around on different hp boxes with different patch levels for lvm etc. and we occasionaly ran into lvm "disk header error" problems when we failed to "pvcreate" or "pvcreate -f" first.

Thank you to all who replied!!
~jdk

[Jakes Louw]

Yep, old LVM VGDA stuff on the disk.

SAM doesn't know how to handle it (nor does LVM either, I suppose....), and exits.
Would be nice if SAM told you why, though.

Usually happens if you've done a vgexport to get rid of a VG, instead of standard "vgreduce...vgremove" sequence, which cleans up after itself.

[TrustNo1]

Bingo, thanks Jake!!
When ridding some "other" systems of VG's, I've been inclined to vgexport to save time, and with the many disks lying about some still had header info...jeeze I didn't think about that, not directly anyway.
Well that explains the "other" errors.

I am truly greatfull to the forums for the opertunity to learn, even what I already know!!

Have a good one, ~jdk

[A. Clay Stephenson]

Actually, a vgreduce and a new pvcreate/vgcreate will only "fix" you by accident. What actually happens is that purely by chance enough contiguous printable ASCII characters are not clustered together to satisfy the string command's notion of what a 'string' is. Lvmtab is a binary file that happens to have the string data mixed with other data so it is simply "luck of the draw" whether or not you get "clean" strings output or not --- irrespective of vgreduce, vgexport, vgimport, pvcreate, ...

[TrustNo1]

Thanks for taking the time to give a detailed explanation Clay!
I'ts always nice to have a better understanding, so it's not magical in nature.
That's the kind of stuff that keeps me awake at night... wondering..
~jdk