topic Re: /etc/lvmtab and kernel do not agree in Operating System - HP-UX

/etc/lvmtab and kernel do not agree

Rick Garland — Tue, 06 Jun 2000 14:26:23 GMT

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

Re: /etc/lvmtab and kernel do not agree

Patrick Wessel — Tue, 06 Jun 2000 14:29:23 GMT

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

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

Re: /etc/lvmtab and kernel do not agree

Jag_2 — Tue, 06 Jun 2000 18:40:28 GMT

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

Re: /etc/lvmtab and kernel do not agree

Rick Garland — Tue, 06 Jun 2000 19:03:57 GMT

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.

Re: /etc/lvmtab and kernel do not agree

Robert Gamble — Tue, 06 Jun 2000 19:12:14 GMT

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!

Re: /etc/lvmtab and kernel do not agree

Patrick Wessel — Wed, 07 Jun 2000 07:56:58 GMT

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

Re: /etc/lvmtab and kernel do not agree

Rick Garland — Wed, 07 Jun 2000 13:05:04 GMT

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.

Re: /etc/lvmtab and kernel do not agree

Patrick Wessel — Wed, 07 Jun 2000 13:14:40 GMT

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

Re: /etc/lvmtab and kernel do not agree

Patrick Wessel — Wed, 07 Jun 2000 13:20:00 GMT

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

Re: /etc/lvmtab and kernel do not agree

James Lynch — Wed, 07 Jun 2000 13:24:10 GMT

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

Re: /etc/lvmtab and kernel do not agree

Rick Garland — Wed, 07 Jun 2000 13:55:20 GMT

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.

Re: /etc/lvmtab and kernel do not agree

Ric Bradley — Wed, 07 Jun 2000 20:19:35 GMT

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.

Re: /etc/lvmtab and kernel do not agree

Rick Garland — Mon, 12 Jun 2000 17:16:34 GMT

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

Re: /etc/lvmtab and kernel do not agree

David DeMartini — Mon, 12 Jun 2000 18:26:36 GMT

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?

Re: /etc/lvmtab and kernel do not agree

Patrick Wessel — Tue, 13 Jun 2000 06:24:23 GMT

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

Re: /etc/lvmtab and kernel do not agree

Rick Garland — Tue, 13 Jun 2000 13:04:03 GMT

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?

Re: /etc/lvmtab and kernel do not agree

Cheryl Griffin — Wed, 12 Jul 2000 15:24:48 GMT

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

Re: /etc/lvmtab and kernel do not agree

Victor BERRIDGE — Wed, 12 Jul 2000 18:00:29 GMT

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

Re: /etc/lvmtab and kernel do not agree

Rick Garland — Wed, 12 Jul 2000 18:09:32 GMT

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.

Re: /etc/lvmtab and kernel do not agree

Alan Riggs — Wed, 12 Jul 2000 18:26:35 GMT

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?