LVM commands not working

[pravin bas]

Hi Gurus ,


I am having a hpux 11.00 box running on a L2000 sever .

I am facing issues on lvm commads . I am not getting any out put on any lvm commands
like

root:/>vgdisplay vg00
root:/>lvlnboot -v
root:/>vgscan -v
root:/

My Ignite bakup is failing for few months with the below error
save_config: Error - The command "lvlnboot" returns a non-zero value. You may use "vgscan -v " command to recreate the "/etc/lvmtab" file.

when I tried to check the VG details in sam it throws the below error
"No volume groups are currently defined on the system. You can create
a volume group by selecting "Create" from the "Actions" menu. "

The server is up and running . bdf is working fine and lvmtab shows the vg and disk details ..

Any Idea whats the issue here ?

[Torsten.]

Sure it is LVM?

Last time I saw strange behaviour while I'm attempt to display vg00 I found out it was configured to use VxVM - wow!

# vxdisk list

Just an idea ...

Otherwise run vgscan and watch the results

# vgscan -v -p
(preview mode first)

[melvyn burnard · Accepted solution]

Wel as VxVM was not supplied by HP fo rHP-UX 11.00,. I doubt it is that.
Also, there was no boot support for it.

So I would be woried that here is NO output, as in nothing at all.

What do you see if ypu do:
ll /usr/sbin/vg*
if they are 0 (zero) in size, then check /sbin/vg*
or try doing /sbin/vgdisplay vg00

[HGN]

Hi

I agree with what Melvyn indicated, you might want to check the size of the lv commands in sbin and amke sure they are non-zero.

Rgds

HGN

[Torsten.]

I missed the 11.00 fact but believe me it was strange ...

;-)

OK, it is strange too to get no output result or error.

Try this:

# whence vgdisplay
/usr/sbin/vgdisplay

Same result?

# what /usr/sbin/vgdisplay
/usr/sbin/vgdisplay:
$Revision: @(#) lvm R11.11_BL2007_0320_1 PATCH_11.11 PHCO_35955

At least similar result?

If the first commands returns something other, this may be the problem.

[pravin bas]

Hi Gurus,

Thanks for the prompt response. I have pasted all the outputs below and could find /sbin/vgdisplay showing results but vgdisplay isn't.

root:/>ll /sbin/vg*
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgcfgbackup
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgcfgrestore
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgchange
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgchgid
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgcreate
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgdisplay
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgexport
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgextend
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgimport
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgreduce
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgremove
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgscan
-r-sr-xr-x 31 root sys 835584 Dec 16 2004 /sbin/vgsync
root:/>/sbin/vgdisplay
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 14
Open LV 14
Max PV 16
Cur PV 4
Act PV 4
Max PE per PV 4350
VGDA 8
PE Size (Mbytes) 4
Total PE 17360
Alloc PE 14792
Free PE 2568
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

root:/>vgdisplay
root:/>whence vgdisplay
/usr/sbin/vgdisplay
root:/>what /usr/sbin/vgdisplay
/usr/sbin/vgdisplay:

[Torsten.]

What gives

# ll /usr/sbin/vg*

[pravin bas]

This is the output
root:/>ll /usr/sbin/vg*
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgcfgbackup
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgcfgrestore
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgchange
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgchgid
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgcreate
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgdisplay
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgexport
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgextend
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgimport
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgreduce
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgremove
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgscan
-r-sr-xr-x 31 root sys 0 Aug 7 09:14 /usr/sbin/vgsync

[Torsten.]

This is the problem, your files are deleted!

Consider to restore the backup.

[HGN]

Hi

You files are not delelted but zeroed out, you can try and get the files copied over from a similar or a server runnign same verison of the OS or try to restore from the backup.

Rgds

HGN

[Torsten.]

zeroed out or deleted - almost the same in this case.

I would restore the files from backup, because if you get them from another system, you may end in an inconsistant state because of different patch levels.

[James R. Ferguson]

Hi Pravin:

I would run a 'swverify' before you restore. This will find any other problems you may have on your server:

# swverify \*

Regards!

...JRF...

[melvyn burnard]

As I suspected and mentioned, you have the files in /usr/sbin all of size 0 (zero), hence they return nothing when you run them.
As for the commentr:
"zeroed out or deleted - almost the same in this case."

No it is NOT almost teh same.
If they were deleted you would get an error : file not found, which would immediately be clearer than just getting a prompt back because the file WAS there, and WAS executale, but due to it having nothing in it you basically ran a "no-op" command.

See what else is zero in size in /usr/sbin, and recover from a good backup

[James R. Ferguson]

Hi (again):

> Melvyn: See what else is zero in size in /usr/sbin, and recover from a good backup

That's exactly why I suggested you run 'swverify \*'. While this will take some time (be patient), it will verify permissions and checksums for all files represented by your IPD (Installed Product Database). Missing or zero-length files will clearly show up!

You may have more damage then you know about.

Regards!

...JRF...

[Torsten.]

Of course I know the difference between an existing and a non-existing file ;-)
but the final result is probably the same - you get nothing useful out of an empty binary application.

The most interesting question is - why did you get into this?
And: what else is affected?

I would prefer to get an idea of the root cause and get back a consistent system soon.

[pravin bas]

Thanks for all your responses. This is the first time I have used this forum and it has been a good experience for me already.
:) Now coming to the issue. We did not have proper backup when I checked and had no other option but to check copying the files from /sbin to /usr/sbin. The vgdisplay command seems to be working now. We have scheduled the ignite backup for tonight. Will keep you updated once it is over.
Thanks all once again.

[pravin bas]

Looks like I have got a consistent system...But finding Root cause might be different since it seems to be the changes were caused some 4 months back. I could see the ignite backups failing for more than 4 months with this error.

Also will run the swverify and will check all the files.

[Bill Hassell]

It should be noted that all LVM commands are just a single executable. You can see this in the ll listings: the link count is 31 meaning that one executable has 31 different names. This is actually a very clever way to maintain a lot of dependent code -- put it all in one big file. So you only need to restore one file, any one of the 31 files will do. Once restored, all the other filenames will start working.