Kernel info inconsistent with /etc/lvmtab

[albert_hua]

Hi,
I encountered one question about LVM configuration inconsistency. The error message is listed as following:
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.
Could you be so kindly to give me some valuable advises?
Thanks.

[S.K. Chan]

What you got is missing PVs in vg00 which disagree with the kernel. Do this ..

# vgreduce -f /dev/vg00
==> force reduction of missing PVs
# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -v
==> recreate lvmtab
# vgcfgbackup /dev/vg00

[S.K. Chan]

Check this also, to further reinforce your understanding ..

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x909e8b55dfd6d4118fef0090279cd0f9,00.html

[albert_hua]

Hi, Chan
Thank you very much for your sincere help.
I tried as what you told me.
But there is no reponse of "vgreduce" at all.
The system gave me the prompt signal "#" as soon as I executed "vgreduce". No messages at all. Then I tried to recreate /etc/lvmtab. But after it was regenerated, the question was still the same as before. My real circumstance is that there is no additional PV of VG00 at all except for two disks. So perhaps the system could not find the missing PV. But how to update the information of Kernel?
I am really confused by such situation.

[pap]

Hi Albert ,
I understood your problem.

Please find below the resolution to your problem.

1. Force reduction of missing PVs from volume group: vg01
# vgreduce -f /dev/vg01
If the above command doesnot work, then follow the next point.Don't give any physical volume name in above command.It will automatically scans all PVs and removes which is not physically available.



2.Follow the point if the problem not solved from point No.1.

Removes the physical volume from the volume group when it is still in the lvmtab file, but it is currently marked as missing from the volume group: vg01

# vgreduce -l /dev/vg01

The following messages will appear after missing PVS has been removed successfully:

PV with key 0 successfully deleted from vg /dev/vg01

Repair done, please do the following steps.....:

1. Save /etc/lvmtab to another file.

2. Remove /etc/lvmtab.

3. Use vgscan -v to recreate
/etc/lvmtab.

I think you are all set now.

Let me know if you have any questions.
-pap

[Krishna Prasad]

It sounds like one of your disk is bad or can not be accessed.

Check /etc/dmesg and syslog and look for any errors. It usally will tell you if a drive could not be added to a volume group.

[S.K. Chan · Accepted solution]

Can you do one thing .. I want to determine if your /etc/lvmconf/vg00.conf file is still good (updated) or not) .. post the output of these .. then we'll work on getting the kernel updated ..

# vgcfgrestore -n /dev/vg00 -l
# strings /etc/lvmtab
# lvlnboot -v
# vgdisplay -v vg00

[albert_hua]

Thanks for everyone.
I think the current vg00.conf is still as good as we want.
# vgcfgrestore -n /dev/vg00 -l
Volume Group Configuration information in "/etc/lvmconf/vg00.conf"
VG Name /dev/vg00
---- Physical volumes : 2 ----
/dev/rdsk/c1t6d0 (Bootable)
/dev/rdsk/c2t6d0 (Bootable)

# strings /etc/lvmtab
/dev/vg00
/dev/dsk/c1t6d0
/dev/dsk/c2t6d0
/dev/p7e34a2
/dev/dsk/c4t2d0
/dev/dsk/c4t2d1
/dev/dsk/c4t2d2
/dev/dsk/c4t2d3
/dev/dsk/c4t2d4
.........

This info is also right.
# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t6d0 (0/0/2/0.6.0) -- Boot Disk
/dev/dsk/c2t6d0 (0/0/2/1.6.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Root: lvol3 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Swap: lvol2 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Dump: lvol2 on: /dev/dsk/c1t6d0, 0


But there is something wrong with the cur PV of vg00 which actually should be 2 but not 3.
# vgdisplay -v vg00
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 10
Open LV 10
Max PV 16
Cur PV 3
Act PV 2

[albert_hua]

Thanks for everyone.
I think the current vg00.conf is still as good as we want.
# vgcfgrestore -n /dev/vg00 -l
Volume Group Configuration information in "/etc/lvmconf/vg00.conf"
VG Name /dev/vg00
---- Physical volumes : 2 ----
/dev/rdsk/c1t6d0 (Bootable)
/dev/rdsk/c2t6d0 (Bootable)

# strings /etc/lvmtab
/dev/vg00
/dev/dsk/c1t6d0
/dev/dsk/c2t6d0
/dev/p7e34a2
/dev/dsk/c4t2d0
/dev/dsk/c4t2d1
/dev/dsk/c4t2d2
/dev/dsk/c4t2d3
/dev/dsk/c4t2d4
.........

This info is also right.
# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t6d0 (0/0/2/0.6.0) -- Boot Disk
/dev/dsk/c2t6d0 (0/0/2/1.6.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Root: lvol3 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Swap: lvol2 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Dump: lvol2 on: /dev/dsk/c1t6d0, 0


But there is something wrong with the cur PV of vg00 which actually should be 2 but not 3.
# vgdisplay -v vg00
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 10
Open LV 10
Max PV 16
Cur PV 3
Act PV 2


BTW,pap. There seems to be something wrong with "# vgreduce -l /dev/vg01" in the vgreduce manual. This command can not be executed because PV path should follow '-l'.

[albert_hua]

Hi, Chan:
In fact, I did such an action towards the PVs of VG00. Initially, I found I can't reduce the disk whose data was destroyed partially from VG00. The system always told me that the PV was included in the /etc/lvmtab. After I recreated /etc/lvmtab, it still resided in the /etc/lvmtab. I deleted the device file of this disk and then ran vgscan again. Then the /etc/lvmtab did not include the disk again. So I could pvcreate this disk and add it into VG00 again. Finally I did mirror between the primary root disk and this disk. But I think the system still store the original information of this disk although I pvcreated it so that the Kernel indicates 3 disks for "/dev/vg00" while /etc/lvmtab indicates 2 disks.

[S.K. Chan]

mmm.. so we can't use vgcfgrestore, the vg00.conf file must have been updated already. I was hoping the missing PV can be seen in vg00.conf file , that way we still have some hope. Bottom line .. is there a way to find out what was the missing PV ? Do you have old copies of vg00.conf or lvmtab file which you can use to find out the PV which is missing.

[Sandip Ghosh]

Do a vgdisplay -v /dev/vg00 to find out which are the disks belong to vg00.
Find out which two physical disk you areusing by lvlnboot -v
then removed the extra disk by doing vgreduce /dev/vg00 /dev/rdsk/c?t?d?

Sandip

[Krishna Prasad]

I attached a program I recieved from the HP response center that will read the lvm header of disk and report back various information.

Do an ioscan -f or ioscan -funC disk and run this program for any drive that you are not sure what volume group it is in. It might help.
I use the program to find out what machine was the last one to use it. It was helpful for me in raid configurations were one machine may have overwritten a drive used by another. I don't think you are using raid drives but it has other options then just finding what host a drive belongs to.

Also, did anyone remove a drive from your machine?

[Krishna Prasad]

I attached a program I recieved from the HP response center that will read the lvm header of disk and report back various information.

Do an ioscan -f or ioscan -funC disk and run this program for any drive that you are not sure what volume group it is in. It might help.
I use the program to find out what machine was the last one to use it. It was helpful for me in raid configurations were one machine may have overwritten a drive used by another. I don't think you are using raid drives but it has other options then just finding what host a drive belongs to.

Also, did anyone remove a drive from your machine?

[albert_hua]

Thks a lot.
In the above message, I have told you that the real process and obviously there was no actual missing physical disk. And the vg00.conf is old because the system can not backup LVM configuration due to the mismatch of the kernel and /etc/lvmtab. Just as the following:

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.

And I have already restored configuration file with "vgcfgrestore -R VG PV ".
But where is the place the kernel stores the missing PV info?

[S.K. Chan]

During bootup and activation of the VG is when the kernel picks up the LVM information. If everything else failed, there is a way to fix this (make the kernel happy) ..

# ll /dev/vg00/group
==> take note of the minor number 0x000000
(I'm assuming it is 0x000000)
# vgdisplay -v /dev/vg00
==> take note of the PVs path (c1t6d0 & c2t6d0)

Boot the system up in LVM maintenance mode.

ISL > hpux -lm

Then do this ..

# vgexport -m /map /dev/vg00
==> blow away vg00 but save config in "map"
# mkdir /dev/vg00
# mknod /dev/vg00/group c 64 0x000000
==> reuse the minor number
# vgimport -m /map /dev/vg00 /dev/dsk/c1t6d0 /dev/dsk/c2t6d0

# shutdown -hy now

Interrupt the boot up, boot in LVM maintenance mode.

ISL> hpux -lm
or
ISL> hpux -lm (;0)/stand/vmunix

# vgreduce -f /dev/vg00
==> now do the vgreduce
# move /etc/lvmtab /etc/lvmtab.bak
# vgscan -v
==> recreate lvmtab
# vgcfgbackup
# vgdisplay -v /dev/vg00
==> hopefully now Act PV and Cur PV is the same.

good luck ..