/etc/lvmtab is out of date with the running kernel

[DHINESHBABU]

# vgreduce -f vg00
Not all extents are free. i.e. Out of 4340 PEs, only 4339 are free.
You must free all PEs using lvreduce/lvremove before the PV can be removed.
Example: lvreduce -A n -m 0 /dev/vg01/lvol1.
lvremove -A n /dev/vg01/lvol1
Here's the map of used PEs

--- Logical extents ---
LE LV PE Status 1
0000 . 3265 stale






# lvlnboot -R /dev/vg00
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates 3 disks for "/dev/vg00"; /etc/lvmtab has 2 disks.
Cannot proceed with backup.

[TTr]

What do these commands show?
vgdisplay -v /dev/vg00
strings /etc/lvmtab
ioscan -fnC disk

Is there an LVM command dettached and still running?

[Raj D.]

Dineshbabu,

Check this out:
Seems to be you have 1 ghost disk in vg00, or the disk is missing or failed. vg00 has 3 disk now it can scan only 2.

Check out this doc for disk replacement procedure and rebuilding lvmtab after removing the ghost disk from lvmtab:
Doc attached: When_Good_Disks_Go_Bad.pdf


HTH,
Raj.

[SoorajCleris]

HI,

vgcfgbackup: /etc/lvmtab is out of date with the running kernel:
Kernel indicates # disks for "/dev/vgname"; /etc/lvmtab has # disks.
Cannot proceed with backup.
Cause:
The number of current and active physical volumes, printed by vgdisplay as Cur PV and Act PV, are not the same. Cur PV and Act PV must always agree for the volume group. This error also indicates that the /etc/lvmtab file, which is used to match physical volumes to a volume group, is out of date with the LVM data structures in memory and on disk.
Recommended Action:
Try to locate any missing disks. For each of the disk in the volume group, use ioscan and diskinfo to confirm that the disk is functioning properly.

Regards,
Sooraj

[Steven E. Protter]

Shalom,

The way to go here is to locate the disk and then take action.

vgreduce can be used to fix the problem if a disk has gone missing.

vgchange can be used.

Sometimes this:

cd /etc
mv lvmtab lvmtab.save
vgscan -a

The action depends on the cause of the problem.

SEP

[DHINESHBABU]

#Vgdisplay
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 13
Open LV 12
Max PV 16
Cur PV 3
Act PV 2
Max PE per PV 4350
VGDA 4
PE Size (Mbytes) 8
Total PE 8680
Alloc PE 8680
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0




#pvdisplay for c1t2d0

---

03265 current ??? 00000
03266 current /dev/vg00/lvol13 00000
03267 current /dev/vg00/lvol13 00001
03268 current /dev/vg00/lvol13 00002
03269 current /dev/vg00/lvol13 00003
03270 current /dev/vg00/lvol13 00004
03271 current /dev/vg00/lvol13 00005
03272 current /dev/vg00/lvol13 00006
03273 current /dev/vg00/lvol13 00007

How to clear this PE?

[DHINESHBABU]

Vgscan failed to create new lvmtab, we have only two disks running hpux 11.23 on rp5405.

[Kanagaraj]

Hi Dinesh,

vgdisplay logs says..

current PV 3
and A.PV 2 --> one PV may bad.


vgdisplay -v vg00
strings /etc/lvmtab
ioscan -fnC disk

[Kanagaraj]

just paste above given command output

[DHINESHBABU]

Hi Knag,

find rar file attachhed

[atul2701]

pls provide the output of below command also.

strings /etc/lvmtab
ioscan -fnC disk

atul

[raghu_14]

The one stale extent indicates the problem is either with the disk or IO card or cable fault.

Do the disk in question has multiple paths (PVlinks)? If in case one link has failed, then we can make this problem correct by configuring the VG with pvlinks. (vgextend vg pvlink1 pvlink2 etc)

what is the o/p of below :
lvdisplay -v /dev/vgxx/lvolxx
diskinfo
ioscan -fnC disk
pvdisplay disk_name | grep "PV status"
dd if=disk_name of=/dev/null bs=1024 count=64

May be you need to try reading the contents of the stale extent with the dd command specifically (by first finding the Physical Extent 0th location, and then skipping all the PE's till you reach the correct extent where it is showing stale). If the dd is successful then there is some issue with LVM. If there is some error, then you may need to go back check the IO card/ cable/disk. If the disk has gone bad, then you may need to follow the procedure to replace the bad disk http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c01911837/c01911837.pdf

Hope this helps,
Raghu

Regards,
Raghu

[dsausers]

Sorry to revive such an old thread, but I came across this same problem, and it doesn't seem that the thread completely resolved it.  So I thought I'd put my solution in here for future folks searching the webs for this issue.  I found that running the following command cleaned up the erroneous disk the kernel thought was in the volume group:

# vgreduce -f {volumegroup}

I then recieved the following message:

PV with key 0 successfully deleted from vg {volumegroup}
Repair completed, please perform the following steps..:
1. vgscan -k -f {volumegroup}
2. vgcfgbackup {volumegroup}

I ran the commands and it resolved the issue.  My vgdisplay now shows 2 current PVs, and 2 active PVs.  However, be careful as a vgscan, I think prior to 11.31 would not scan in inactive VG's.  I'm running 11.31, so this was not a problem, but just beware.