/etc/lvmtab out of date with running kernel

[Adam Noble]

Hi,

We have an issue on one of our servers. We are getting the error message below whenever we attempt any volume group config:-

vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates 16 disks for "/dev/vg01"; /etc/lvmtab has 32 disks.
Cannot proceed with backup.

I think I know why this happened the server was re-booted however one path to the disks was not in place. The /etc/lvmtab still reference those disk paths (quite rightly). I assume a re-boot may fix this but do I have any other option? A vgscan is not really going to help as far as I can see.

Cheers

[Luk Vandenbussche]

try if it helps to recreate /etc/lvmtab

mv /etc/lvmtab /tmp
vgscan -a
vgcfgbackup vg01

[Pete Randall]

Running vgscan at this point would update /etc/lvmtab to show just the 16 disks, which would stop the error message. You would just need to re-run vgscan to get all 32 disks back after the next re-boot.


Pete

[Adam Noble]

Pete,

I totally agree and this is what I expected to see however this is not the case. This is because the path to those disks is now in place. The scan picks up on them!!

Cheers

[Rita C Workman]

A reboot is one option.

Another option is to blow out your vg and rebuild it with vgimport, but using the -f option so you define the c-t-d- enries exactly as you want them in that input file.
[Not uncommon to use this option if you do BCV mirrors for remounting disks elsewhere]

Option one - whole box down
Option two - vg down

Rgrds,
Rita

[charlie_bulosan]

Hi,

If your storage is from a SAN disk array, just connect the path that was taken out, and do ioscan. this should be able to detect the old path and still re-use the old device files (If still the same switch port/fabric/domain are used)


Regards,
Charlie

[Sandman! · Accepted solution]

Instead of rebooting try activating the VGs that lost the path with vgchange i.e.

# vgchange -a y vg??

Above cmd when issued on an already active VG will restore PV links that went missing but have been restored since. See excerpt from vgchange manpage.

"...If the -a y or -a e option is executed on a currently active volume group, without the -x option, vgchange attempts to include any physical volumes that were previously listed as missing. This is useful if a physical volume has come back online."

[Adam Noble]

Sandman legendary work thanks for that!!! resolved our issue.