Professional Documents
Culture Documents
1) vgscan ( many people suggested this one, but seeing the man
page
it has so many warnings and "this is a last resort
command"
stuff that I 'll try to avoid it. Anyone who really
used it?)
The problem comes from incorrect count of PVs between lvmtab and the kernel.
And now that the physical volume was truly empty, I run vgreduce -f
and that made the trick.
Regards,
Martin
-----Original Message-----
Today, I 've tried to lvremove a logical volume and got an error
The same that I paste here from a vgcfgbackup:
sid02_en_06#vgcfgbackup vg03
PROBLEM
When doing any LVM command for a particular volume group it errors with:
RESOLUTION
The above error indicates a serious problem with the volume group. No changes
should be made to the volume group configuration prior to repairing the volume
group.
Each physical volume of each a volume group has a counter indicating the number
of physical volumes currently within the volume group. This information is
contained within the disk's volume group reserve area (VGRA). The above error
indicates the information within the VGRA shows a different number of physical
volumes than the system currently sees attached to this volume group. At
volume
group activation time the /etc/lvmtab file is used by the system to know what
physical volumes belong to each volume group.
This document will explain what to look at and how to repair this situation.
Use the following steps to isolate and repair the problem:
Isolating what happened to the volume group to get it into this state can
be very difficult. Here are some suggestions:
a. Use the command strings /etc/lvmtab or
vgdisplay -v /dev/vg_name to see what disk devices are
currently attached to the volume group.
b. Check the date of and physical volumes contained in the last good
vgcfgbackup.
NOTE: If the volume group has been modified since the time of the
last good vgcfgbackup, then there is the potential that the backup file
is out of date with the LVM data structures on the disk(s) attached to
this volume group. If this is the case then vgcfgrestore(1m)
may no longer work for this volume group.
A common reason for the system to be in this state is that the lvmtab
has been recreated while unable to communicate with one or more of the
physical volumes belonging the the volume group. If the lvmtab is
recreated while the system is unable to query a physical volume, that
physical volume will not be added to the lvmtab file. One can see how
this can cause the lvmtab to mismatched with kernel memory.
2. If possible, restore the missing physical volume into the volume group.
b. If missing physical volume(s) and alternate path(s) are not in use then
use vgcfgrestore(1m) to restore the physical volume(s) to the
volume group.
If the /etc/lvmtab does not contain the physical volume(s) that were
vgcfgrestored to, then this file must be updated. If the lvmtab shows
the correct physical volumes then skip this step.
If the /etc/lvmtab does not show the correct physical volumes and you
were able to find an old /etc/lvmtab file in the previous step then save
the current version of /etc/lvmtab and copy the old lvmtab backup file
into place. Use the strings(1) command to insure all volume
groups show the correct physical volume before changing the lvmtab file.
NOTE: For the root volume group, typically vg00, you must first
boot into lvm maintenance mode. See below for details
Overview:
1. vgchange -a n /dev/vg_name
2. vgexport -m /tmp/mapfile /dev/vg_name
3. mkdir /dev/vg_name
4. mknod /dev/vg_name/group c 64 0x0X0000
NOTE: The minor number (0x0X0000) must be unique for each volume
group. Substitute X for a number not in use on the system.
Use: ll /dev/*/group to see existing group files on the
system.
3. If you cannot locate the missing disk device or cannot restore that
device back into the volume group, then use vgreduce(1m) to forcibly
reduce out the missing physical volume.
Since logical volumes that show ??? have missing or unavailable data
they will have to removed. In order for vgreduce -f to succeed
all logical volumes with extents on the physical volume to be reduced
must first be removed. Once the volume group is in the correct state,
Cur PV = Act PV, the logical volumes can be recreated and any lost data
restored.
NOTE: The above command does not require a physical volume argument. It
must be run on a active volume group.
e. If the vgreduce -f command does not work or does not give any
error and vgdisplay(1m) still shows that Cur PV and Act PV
disagree then use the following steps to vgexport and vgimport the
volume group prior to trying Step 3d again.
2. vgchange -a n /dev/vg_name
NOTE: Skip this step if booting maintanence mode for root volume
group.
4. mkdir /dev/vg_name
NOTE: Specify all the physical volumes obtained from step 1. Do not
include the physical volume that you are trying to remove or
that couldn't be queried.
NOTE: Procedure used for steps 2 and 3 may very slightly depending
on machine model.
This time the vgreduce should succeed and give you a message
similar to: "PV with key # sucessfully deleted from vg /dev/vg_name".
It should also display: