Proble with volume group

[Marcelo De Florio]

I up the volume group without quorum and then
I have a following problem:

Volume group "/dev/vgdesadb" has been successfully extended.
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates
5 disks for "/dev/vgdesadb"; /etc/lvmtab has 4 disks.
Cannot proceed with backup.

How can i resolve this problem ?

Also I have a problem with the server, with this messagge:

Apr 4 15:54:09 s2500d cmcld: Service cmlvmd terminated. Unable to get exit stat
us (No such file or directory)
Apr 4 15:54:09 s2500d cmcld: Halting s2500d to preserve data integrity
Apr 4 15:54:09 s2500d cmcld: Reason: LVM daemon failed

Anybody know , what happend ?

thanks
MDF

[Steffi Jones_1]

Hello,

The Kernel somehow still thinks you have one more disk in the group than you really have.

Here are 2 steps you can try:

1) mv /etc/lvmtab to /etc/lvmtab.old and then vgscan -v
or
2) vgreduce -f /dev/vg...

That will take the unnecessary information out

Steffi Jones

[Marcelo De Florio]

I execute mv /etc/lvmtab /etc/lvmtab.old and then vgscan -v,

but i have a same problem:

Logical volume "/dev/vgdesadb/lvora817" has been successfully extended.
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates
5 disks for "/dev/vgdesadb"; /etc/lvmtab has 4 disks.
Cannot proceed with backup.

MDF

[Wieslaw Krajewski]

Hi, As the last resort I'd advice to export and then import volume group, what is not so difficult in the case of non root VG (is also possibleb, more difficult in the case og root VG).
To be more precise do as follows:
1. unmount all file systems in the logical volumes of the volume group to be exported.
2. vgchange -a n VG_name
3. vgexport VG_name
4. mkdir /dev/VG_name
5. mknod /dev/VG_name/group c 64 0x0N0000
where N is properly selected (may be the same as in exported volume group
6. vgimport VG_name /dev/dsk/c#t#d# /dev/dsk/.....

If you use different than default names for logical volumes, must use the so called map file doing export and then import. See man pages.

[Byron Myers]

Try "vgreduce -f vgdesadb" this should reduce out any missing PV's the kernel thinks are in vgdesadb.

[Marcelo De Florio]

Byron:
I can probe with your recomendation but I have the same problem.

Any more ideas about resolve this ?

MDF

[John Waller]

You mentioned that you "up the vg without quorum".
Do you have a logical volume with any extents on a non-existant or faulty disk. Try a vgdisplay -v to see if you have any errors or if you have a lvol with stale partitions if so you need to lvreduce these lvols before running the vgreduce -f command.

[Pedro Sousa]

Before you do something else:
mv /etc/lvmtab /etc/lvmtab.old
vgscan -v (to recreate /etc/lvmtab)

Now it shouldn't give any more errors.
check with "vgdisplay -v" if there is any problem.
good luck.

[Jeff Gyurko]

Marcelo,

I dont know if you've resolved this yet, but here is my take on it.

These guys are right about the lvmtab, vgscan answer, but in order for this to work, I think you have to deactivate the VG first.

vgchange -a n /dev/vgwhatever
mv /etc/lvmtab /etc/lvmtab.something
vgscan -p -v
check this output to ensure that the
correct number of PV's are in that volume
group. If so:
vgscan -v
vgchange -a y /dev/vgwhatever

Let us know the outcome.

[Andrew Galbraith Ryer]

I had this exact problem. I followed the earlier instructions suggesting "vgreduce -f vgxx". I did this, and was then instructed to mv /etc/lvmtab, and run "vgscan -v". This fixed the problem.