Strange LVM error

[Philip Kime]

When any LVM command is run on this 10.20 box, I get:

scp2m # lvlnboot -v
lvlnboot: Couldn't query physical volume "":
The specified path does not correspond to physical volume attached to
this volume group
scp2m #

yes, really nothing between the quotes. I get this error for every LVM command run. Every VG has a ghost disk

Cur PV 3
Act PV 2

There are no dead disks - the error always reports disk "" as being the missing disk. I have recreated /etc/lvmtab to no effect. This is very odd! vgreduce won't fix this because it just gives this error and stops. Any ideas? Looks like a vgexport/import job to me but I'm worried that even that won't work.

[#2]

This message you can get if you have an alternate links to the disk. It is OK. When I boot server I get theese messages.

[Jean-Louis Phelix]

Hi,

I would try a vgreduce -f for each vg, then if not corrected, I would also try a vgscan -p.

Regards.

[Philip Kime]

I have no pvlinks on this box and I've tried a vgscan too and have recreated the lvmtab. No luck.

[Jdamian]

Run
# strings /etc/lvmtab
in order to get the physical volume names.

[Philip Kime]

I have done this - there are no missing volume names (there are no missing volumes - all disks are fine and running).There are, however, some suspicious blank lines in lvmtab for each VG, hence the "" error. I've vgscan'ed a new lvmtab and they just are still there ...

[Armin Feller]

That means that there exist a "ghost disk", a very good cookbook can be found in the HP Knowledge Database in following document:

LVMKBRC00006257
Removing A "Ghost Disk"

You need a software contract to join to the HP Knowledge Database.

[Dietmar Konermann]

Check if you have a /dev/slvmvg device file on your system. If yes, rename it and run vgscan again (maybe this old bug applies to your problem... should be solved with recent LVM command patches).

Best regards...
Dietmar.

[Philip Kime]

Just to confirm, there is no ghost disk. All disks are fine. It *looks* like a ghost disk but the ghost disk reports as being called "". It's not a ghost disk problem because, suddenly, *every* VG has a ghost disk called "". Therefore, it's not a ghost disk but some much nastier problem I think.

[T G Manikandan]

Are you running serviceguard

Sometimes the slvmvg file corrupts the lvmtab file.
Please check whether you have this file.
# ll /dev/slvmvg
If yes
# mv /dev/slvmvg /tmp
# mv /etc/lvmtab /etc/lvmtab.currentdate
# vgscan -v
# strings /etc/lvmtab


Revert

[Philip Kime]

No serviceguard and no /dev/sl*

These are DNCP machine, not HP hardware bit they run 10.20. I've been told that it's possibly PHCO_18563 and all we need to do is reinstall this and then vgreduce -f the VGs. This doesn't sound quite right to me since the LVM patch won't recreate the /etc/lvmtab and vgreduce -f fails currently because of the "" disk.

[Dietmar Konermann]

Philip,

could you please gzip your lvmtab file and attach it to this thread? I would like to have a look at it. I would like to get the file's binary.

Best regards...
Dietmar.

[Philip Kime]

Here it is ... it seems to me that it has an extra blank line in each VG?

[Dietmar Konermann]

Hmm, I'm unable to open the attachement. :( Could you send it to me via EMail, please? (forname.surname@hp.com)

Best regards...
Dietmar.

[Philip Kime]

Strange lines in "strings /etc/lvmtab" ...
/dev/vg00
/dev/dsk/c0t0d0
/dev/dsk/c1t0d0
/dev/vgdata01
49:8k
/dev/dsk/c0t1d0
/dev/dsk/c1t1d0
/dev/vgdata02
49:8
/dev/dsk/c0t2d0
/dev/dsk/c1t2d0
/dev/vgdata03
49:8
/dev/dsk/c0t3d0
/dev/dsk/c1t3d0
/dev/vgTBEbackup
/dev/dsk/c0t4d0
/dev/vgTSCbackup
/dev/dsk/c0t5d0

[Philip Kime]

It seems as though the version of vgreduce on this machine is not the one we expected from recent patching. We intend to reinstall the LVM patch in question and retry vgreduce -f on the VGs. I assume vgreduce should be able to deal with empty PV strings?