No. of PVs mismatch between kernel and LVM

[Ralph Grothe]

Hi,

I've just upgraded a server from HP-UX 11.00 to 11i.
Because the upgrade procedure as outlined in the "hp-ux 11i installation and upgrade guide" failed (I had it run during the night, where I wasn't able to supply it with the 2nd CD when prompted so that the installation left in an indefinite state, commands such as ps etc. weren't executable, and after a reboot and insertion of CD2 I couldn't get a getty to login, respawned too quickly),
Thus I finally did a cold install from CD over my current 11.00 OS with prior backup of /etc, /home, and vgdisplay -v dump.

When I mirrored the boot disk of vg00 after successfull installation of 11i I accidentilly mixed up the PVs so that I wrote boot and LIF on a PV from vg06 (a data volume).

Well, that shouldn't be a problem since all PVs were mirrored.

So far I reintegrated all data VGs successfully through vgimport thanks to my saved vgdisplay dump and the copy of fstab from /etc.

But for the vg06 whose second PV accidentally got an mkboot entry.
So I vgimported it by only specifying the first PV from it, and activated it by frocing it to ignore any quorum by the "-q n" flag.

I then pvcreated the mkboot-overwritten PV anew and vgextended it into vg06.
I also lvextended -m 1 some of the LVs in it, but now get always warnings/errors that I have a discrepancy between the kernel records and my current vg06.

How to overcome?

[Ralph Grothe]

I forgot to provide you with the error message.
After lvreducing, and vgreducing here is what I get when I vgextend again:


# vgextend /dev/vg06 /dev/dsk/c1t14d0
Volume group "/dev/vg06" has been successfully extended.
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates
3 disks for "/dev/vg06"; /etc/lvmtab has 2 disks.
Cannot proceed with backup.


But it appears in vg06 anyway:

# vgdisplay -v vg06|tail -15

--- Physical volumes ---
PV Name /dev/dsk/c0t14d0
PV Status available
Total PE 1023
Free PE 0
Autoswitch On

PV Name /dev/dsk/c1t14d0
PV Status available
Total PE 1023
Free PE 1023
Autoswitch On


# strings /etc/lvmtab|tail -3
/dev/vg06
/dev/dsk/c0t14d0
/dev/dsk/c1t14d0

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

[Stefan Farrelly]

Try this;

1. make a backup of /etc/lvmtab in case this doesnt work
2. rm /etc/lvmtab
3. vgscan (this recreates the lvmtab file by scanning each disk to confirm which vg its in
4. strings lvmtab - is it fixed ? if not restore from 1.

[Stefan Farrelly · Accepted solution]

I think before you rebuild the lvmtab file you should try;

vgreduce -f vg00

This should try to remove any physical disks which are not 'really' in the VG. See man page on it.

[unixdaddy]

You may also have to run vgimport on any unmatched physical volumes, if there are disk you want in put vgscan does put them into a volume group.

[Ashwani Kashyap]

You could have used rmboot to remove the boot area from that PV .
Do you have any alternate link that is missing . maybe that is what is causing you all the problems .

Otherwise try using vgscan after making a copy of your existing lvmtab file .

If you have a previous copy of a vgcfgbackup of VG06 and you are absolutely sure that its a valid copy , then you can try restoring the configs back with the -R option with vgcfgrestore . Use this with caution . see man pages for more details .

[unixdaddy]

When this happened to me I had to do the following:-

vgreduce -f vg??
remove lvmtab
vgscan
then you should be able to do your vgcfgbackup.

[S.K. Chan]

First lets try to recreate lvmtab file ..
# cd /etc
# mv lvmtab lvmtab.old
# vgscan -v
Now run the "vgcfgbackup" again to see if it still complains. If that doesn't help I'm almost certain vgexport and vgimport vg06 would solve the descrepency.
# vgchange -a n /dev/vg06
# vgexport -m /tmp/vg06map /dev/vg06
# mkdir /dev/vg06
# mknod /dev/vg06/group c 64 0x060000
==> minor number has to be unique
# vgimport -m /tmp/vg06map /dev/vg06 /dev/dsk/c0t14d0 /dev/dsk/c1t14d0

[Ralph Grothe]

Stefan,

vgreduce -f vg06

did the trick :-)

[S.K. Chan]

I found this that may be of further help ..
DOCID=KBRC00000632
http://support2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063218440

[Ralph Grothe]

Outch, was a bit premature,
strangely there's only *one* stale PE when I lvextended again:

00060 /dev/dsk/c0t14d0 00060 current /dev/dsk/c1t14d0 00060 current
00061 /dev/dsk/c0t14d0 00061 current /dev/dsk/c1t14d0 00061 stale
00062 /dev/dsk/c0t14d0 00062 current /dev/dsk/c1t14d0 00062 current


Will I have to do an rmboot subsequetly?
I thought my 2nd pvcreate had erased anything on the PV...

[Ralph Grothe]

Thanks Chan, for the link.

[S.K. Chan]

No need to run "rmboot" coz "pvcreate" has done it's job there when you run it. With regards to the stale extent, try running ..
# lvsync /dev/vg06/
If stale still shows, I believe this could be early indication of c1t14d0 going bad. Watch out for any hardware error log from this point onwards.