/etc/lvmtab and kernel do not agree

[Rick Garland]

Have done asking of those who have been here awhile. Seems that 2 4GB disks were removed from the system before my time. This was done without doing the vgresuce command. Seems that this solution matches what I am seeing. I will be doing the task over this weekend and confirm.

Many thanks.

[Ric Bradley]

If vgdisplay showsCur PV is greater than Act PV then ghost disks are present. All who said to use:
vgchange -f vgxx
are right. This can be done online without making the vg unavailable.

[Rick Garland]

Hi all:

Did the vgreduce -f /dev/vg30 and it did not work. Still have the CUR PV=6 and ACT PV=4. Still have the other problems as well.

I have read the docs for vgreduce and with the -f option, it describes exactly what I am looking to do but doesn't do it.

Any ideas why it did't work?

Thanks -- Rick

[David DeMartini]

Rick,

What do you mean by other problems? Perhaps a hardware issue is masquerading as a config issue. You might have to crack the case and see 'how' the 2 drives where removed.

Are the drives sleds that auto-select some SCSI ID? Something sounds very odd here. Have you tried to rebuild the kernel?

[Patrick Wessel]

Rick,

Why can't the real live not be that easy as a manual page?
Have you tried to export and re-import the VG?
1) Use: ll /dev/vg30/group to get 0x###### minor number.
2) vgdisplay -v /dev/vg30 to get physical volumes
3) vgchange -a n /dev/vg30
4) vgexport -m /mapfile /dev/vg30
5) mkdir /dev/vg30
6) mknod /dev/vg_name/group c 64 0x0#0000
Re-use minor number obtained from step 1.
7) vgimport -m /mapfile /dev/vg30 pv_name pv_name pv_name pv_name

Activate the vg30 and verify if the CUR PV and ACT PV have the same value. If not, try again the vgreduce -f

I hope this will make it. Otherwise I run out of ideas

[Rick Garland]

My next step is to try the vgexport/vgimport. I am thinking that if the mapfile comes out with six devices, I will modify to only have the four. Then import back in.

I am at a loss as well. The man pages state, almost exactly, what I want to do and it is with the vgreduce -f command.

Go figure?

[Cheryl Griffin]

Rick,

I have seen some cases, that you have to vgreduce twice in succession and follow it up by using vgscan -v to recreate the /etc/lvmtab.
# vgreduce -f /dev/vg04
# vgreduce -f /dev/vg04
# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -v

[Victor BERRIDGE]

Hi Rick,
Solved your problem?
How many disks have you in this vg? I mean does it match with what you know of, like ioscan results. I once had something of the sort going thru sam, also on a K with 10.20, and in fact it was a misconfiguration to do with in my case of alternate paths not matching properly...(almost like AIX ghost disks).
If I remember right I had to remove all the disks of th volume group:
vgreduce /dev/vgXX /dev/dsk/cYd0s2..
vgremove /dev/vgXX
and start again

Hope It will help
Regards
Victor

[Rick Garland]

Problem still exists. Been through the vgreduce, vgscan, vgexport/vgimport, etc.
Still exists. The kernel is still seeing CUR PV=6 and ACT PV=4. There are only 4 disks in the PV so the ACT is correct. Also in vgdisplay, shows CUR LV=14 and the Open LV=10. The 10 figure is correct. Somehow I need to find out what the lvols were on the disks that were removed, do the lvremove command, then I believe I can do the vgreduce -f command.

You are correct in that removing the VG and starting over again will solve the problem but I find it hard to believe that thisd would be the only cure.

[Alan Riggs]

There has to be a better way. Did your vgexport map show 4 devices or 6?

If you do a strings on /etc/lvmtab how many devices and lvols are shown?

Did you specify all four disks when issuing the vgimport?

Did you try doing a vgscan while the vg was exported?