Bug 443728 - Problems with vgimport if you specify 'vgnamePV_EXP' instead of just 'vgname'
Problems with vgimport if you specify 'vgnamePV_EXP' instead of just 'vgname'
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: lvm (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: LVM and device-mapper development team
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2008-04-22 22:13 EDT by Mark Huth
Modified: 2009-06-19 09:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-19 09:44:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Huth 2008-04-22 22:13:29 EDT
It seems there is a bug with vgimport if you import the volume group with the
'vgnamePV_EXP' name instead of just the original 'vgname' name.  I was able to
replicate this bug like so:

Create a volume group called, say, vgname.  Then ...
vgchange -an vgname
vgexport vgname
- displays vgnamePV_EXP
vgimport vgnamePV_EXP <physical_volume>   <---- this is where the bug is
- displays vgnamePV_EXP instead of vgname
- still reports that the PVs are 'in EXPORTED VG "vgname"'

However if I use:
vgimport vgname <physical_volume>
- displays vgname
- shows normal/expected vgname information

Solution to the mess created:
vgrename vgnamePV_EXP vgname
... vgscan and pvscan show consistent information again.

Lesson learnt:
There is a bug in RHEL3 lvm if you use 'vgimport vgnamePV_EXP <physical_volume>'
instead of 'vgimport vgname <physical_volume>'
Comment 1 Dave Wysochanski 2009-06-19 09:44:35 EDT
Rhel3 is in maintenance phase and only security bugs will be fixed.

Upstream LVM does not have this bug, neither does RHEL4 or RHEL5.

Note You need to log in before you can comment on or make changes to this bug.