Bug 231187 - vgrename unable to rename a VG with the same name as an active one
vgrename unable to rename a VG with the same name as an active one
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Corey Marthaler
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-06 13:28 EST by Rogan Lynch
Modified: 2007-11-16 20:14 EST (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0753
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 10:58:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rogan Lynch 2007-03-06 13:28:01 EST
Description of problem:
Bugzilla Bug 147361: Fix duplicate VG name handling.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147361

Common scenario:
Upgrading HD -- 
 1. Install new HD and OS
 2. Connect old HD using USB case
 3. Recover/Import data from old HD

This scenario fails miserably when LVM with system install defaults. 
Reason: Volume Group names are identical on new (/dev/hda) and old
(/dev/sda) drives.  "/dev/mapper" will only read/access one of those
volume groups while ignoring the other.  No LVM tool was able to
access the old HD's group for the purpose of renaming.  Any reference
to the group name was confused with the live group name which could
not be changed while in use. (System cannot be used without active
volumes)

Now prompts for UUID and realizes there are 2 identical "VolGroup00" entities, 
but when UUID is substituted for Volume Group Name , vgrename fails with "group
still contains active logical volumes" --- which belong to the new active
system, not the old (/dev/sda?) system.


Version-Release number of selected component (if applicable):
lvm2-2.02.06-6.0.RHEL4 

How reproducible:
Always


Steps to Reproduce:
1. Install new HD and OS
2. Connect old HD using USB case
3. Attempt recover/import data from old HD


Actual Results:  Unable to access old data from drive due to LVM's
confusion as to which media to access based on identical VolGroup00 name.

Expected Results:  Should be able to mount old drive and recover data.
Comment 1 Alasdair Kergon 2007-03-06 13:44:59 EST
as a workaround, try setting global/activation to 0 (instead of 1) in lvm.conf
*only* while running that command - that tells lvm to skip all its activation logic
Comment 2 Rogan Lynch 2007-03-06 13:50:05 EST
Thanks...Alasdair, but I don't need a workaround, I need a fix. I have many
workarounds...namely KNOPPIX 5.1. Just please actually fix the problem this time.
Comment 3 Rogan Lynch 2007-03-06 16:18:50 EST
same issue described here:
http://www.linuxquestions.org/questions/showthread.php?t=375928
Comment 4 Alasdair Kergon 2007-03-08 16:20:15 EST
vgrename patched upstream for 2.02.23 (and RHEL4.6).  The check now takes the
VG's uuid into account.
Comment 5 RHEL Product and Program Management 2007-05-09 01:53:39 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 9 errata-xmlrpc 2007-11-15 10:58:21 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0753.html

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