/etc/lvmtab and kernel do not agree

[Rick Garland]

Hi all:

This is one I have not seen before.

Got a K420 with 10.20 HP-UX. In the /etc/lvmtab it shows 4 disks being used. In SAM it shows 6 disks being used. Try to do vgcfgbackup and I get the following message:
/etc/lvmtab is out of date with the running kernel; kernel indicates 6 disks for /dev/vg30; /etc/lvmtab has 4 disks
Not a major problem, haven't seen any issues because of it - yet. It does prevent the addition of addition logical volumes.

What could be the matter and how to fix?

Many thanks!
Rick

[Patrick Wessel]

try to create a new lvmtab. It should contail all disks

# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -v

[Jag_2]

try to create a new lvmtab. It should contail all disks

# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -v

After doing the above step's to verify the lvmconf file and lvmtab file contains same info.

strings /etc/lvmtab
vgcfgrestore -n /dev/vg30 -l

[Rick Garland]

It all agreees but the same error shows up:
/etc/lvmtab out of date with the running kernel; kernel indicates 6 disks for /dev/vg30; /etc/lvmtab has 4

The vgscan only sees 4 disks. Doing the list of vgcfgrestore shows 4 disks as well.

[Robert Gamble]

try using 'vgchange'. It reads in the VGRA from the disks, updates /etc/lvmtab, then updates the kernel memory info.

With no users on the system, try:
vgchange -a n vg01
vgchange -a y vg01
strings /etc/lvmtab
vgdisplay -v

They should now match.

Good Luck!

[Patrick Wessel]

Rick,

Looks like we can't go the easy way?
If lvmtab and kernel disagree there is one important question: who is right? Do you how many disks are really part of the VG?
What does vgdisplay display for Cur PV and Act PV?
Use: vgcfgrestore -n /dev/VG_NAME -l to see the list of physical volumes contained within the last good backup.

Maybe the answer on this question get us closer to the cause of your problem

[Rick Garland]

There are four disks installed as part of the VG.
The vg.conf indicates the right number and the right devices.
strings /etc/lvmtab indicate the right number of disks with the correct devices.
vgcfgrestore -n /dev/vg30 -l indicates the right number of disks and the correct devices.

vgdisplay -v /dev/vg30 shows CUR PV = 6 with ACT PV = 4

There were 6. This was before my time at this job. Apparently, somebody just physically removed them with exporting or anything else. This is where I believe the original problem started.

I have checked out the /dev/vg30 directory and am able to match up all the lvols to the correct devices.

[Patrick Wessel]

OK, this is a case for:
# vgreduce -f /dev/vg00

The manual page for vgreduce has a good explanation what it does to your VG...

good luck

[Patrick Wessel]

OK, this is a case for:

# vgreduce -f /dev/vg_name

The manual page for vgreduce has a good explanation what it does to your VG...

good luck

[James Lynch]

You should run vgreduce -f /dev/vg30. This will remove the 2 missing PV's(disks) from your volume group. See the man page for vgreduce for more info

Jim

[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?

[Rick Garland]

Hi Alan:

You're right! There has to be a better way!

The answers to the questions, lvmtab shows 4 PVs, the vgexport showed 4 PVs, when the vgimport was done, only 4 PVs were specified.

Is there a way to find out what the missing lvols are? I ask because when doing the vgreduce -f /dev/vg30 I get the following:
Not all extents are free, i.e., out of 2170 PEs, only 370 are free. Must free all PEs using the lvreduce/lvremove command before PV can be removed.

As stated earlier, 2 disks were removed without doing the lvremove - vgreduce commands.

So it shows 14 LVs when there are only 10 and 6 PVs when there are only 4.

[Alan Riggs]

It really does seem an ideal case for vgreduce -f. Have you tried doing an lvremove -f on the "phantom" logical volumes and then running vgreduce -f vg30 ?

[Rick Garland]

I agree. Per the man pages on vgreduce, the vgreduce -f /dev/vg30 reads exactly what I am trying to accomplish. I would try the lvremove commands but I am unsure how to find out what the lvols were that were on the disks that were removed. The individual who may have done this is no longer employed with this company and nobody else knows what I am talking about. (Them a bunch a MicroSlop weenies).

[Alan Riggs]

Ah -- I assume, then, that you don't keep the default lvolX nomenclature.

Do you have an old backup (pre disk removal) that might show you the files in /dev/vg30/?

[Rick Garland]

They didn't keep the default nomemclature. As for a backup, I have idea when this was done and the system is some 3 years old. Again, no records/documentation as to what was done.