Bug 476582 - Anaconda incapable of clearing data from drives with duplicate VG names
Anaconda incapable of clearing data from drives with duplicate VG names
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.3
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks: AnacondaStorage
  Show dependency treegraph
 
Reported: 2008-12-15 17:11 EST by Gary Case
Modified: 2009-08-03 04:11 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-03 04:11:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dump from anaconda crash during installation (628.74 KB, text/plain)
2008-12-15 17:11 EST, Gary Case
no flags Details

  None (edit)
Description Gary Case 2008-12-15 17:11:41 EST
Created attachment 327030 [details]
dump from anaconda crash during installation

Description of problem:
If you pull drives from systems installed with RHEL and install them all into one system, Anaconda cannot handle the duplicate VolGroup names it finds and will bomb out when it attempts to install.

Version-Release number of selected component (if applicable):
RHEL5.3 Snap6
anaconda-11.1.2.163-1

How reproducible:
Every time

Steps to Reproduce:
1. Install multiple disks with identical VG names in a single system
2. Begin installation of RHEL5, using default partition options during a graphical install
3. Anaconda traceback when it begins modification of disks
  
Actual results:
Traceback and reboot

Expected results:
Blanked disks, then functional and installed system.

Additional info:
Attaching the traceback file from the aborted install
Comment 1 Gary Case 2008-12-15 17:18:03 EST
For the record, I know you can dd over the first part of the disks to get around this, but it's not the kind of error we should be encountering during install.
Comment 3 Radek Vykydal 2008-12-16 09:12:52 EST
The thing we hit here is that we are trying to revmove PV
of existing VG. In lvm.py:vgremove we remove only one
of VGs with given name (chosen by lvm) with vgremove,
but then we try to pvremove all PVs of VGs with given
name. Hence the traceback.

Another problem is duplicate LV names. Before removing
all VGs of given name, we remove only one LV of given
name (chosen by lvm) in doMetaDeletes, so some VGs to
be removed have LVs and lvm asks for user confirmation
(it is new feature of lvm and can be supressed with --force).

This fix won't be easy, I feel high break-lvm-things potential.
Comment 4 Chris Lumens 2009-05-19 13:17:52 EDT
I'd like to reiterate Radek's concerns about the potential for breaking other things attempting to fix this bug.

In Fedora we have mitigated this problem somewhat by using the hostname in volume group names and the mountpoint in logical volume names, and also by being more thorough in wiping volume metadata.  I don't suppose it would be possible for you to give F11 when released and see if that fixes this problem for you, would it?  If so I'd like to handle this one as NEXTRELEASE instead of attempting to do something in an update release that could really impact us in other ways.
Comment 5 Radek Vykydal 2009-05-21 08:02:02 EDT
There is a pretty good chance the issue will be fixed with
https://bugzilla.redhat.com/show_bug.cgi?id=462615 in 5.4.
Comment 6 Denise Dumas 2009-06-30 16:37:28 EDT
Moving to RHEL 5.5 so it doesn't get mistakenly closed by the bot. But it needs a retest given the fix for 462615.
Comment 7 Alexander Todorov 2009-07-31 08:21:48 EDT
QA results with 5.3 GA:

1) Install Xen, PV guest with default partitioning into a file (disk1.img)
2) Copy the image to create a second one (cp disk1.img disk2.img)
3) Both disk images contain identical volume groups and logical volumes (names are default)
4) Using virt-install start another installation using both disk images
5) Select default partitioning in anaconda GUI
6) Installation completes.
7) Using virt-install install again, but only using disk1.img
8) system installs without problems


Steps 1-6 describe installation on 2 identical disks with the same volume group and logical volume names. 

Steps 4-8 describe installation on 2 disks and the installation over 1 of them only. 

Gary,
can you provide exact steps to reproduce? Anaconda doesn't throw an exception for me.
Comment 8 Gary Case 2009-07-31 15:16:08 EDT
I did this with two separate systems with real disks. Perhaps that's why you didn't see the error?

1. Install RHEL5.3 x86_64 on two similar systems, each with one hard drive. 
2. Choose to "remove all partitions and create default layouts" on both systems during the install.
3. When both installs complete, move both hard drives into the same machine and try another install of RHEL5.3
4. When you reach the end of the installer, you will receive the error.

(I just verified this again with RHEL5.3)

Let me see what happens with RHEL5.4 snap 5 (160 kernel). It'll take a bit to install the new pxe components and install the OS on the systems. I'll report back as soon as the installs complete.
Comment 9 Gary Case 2009-07-31 16:41:57 EDT
W00t! The error doesn't occur in RHEL5.4 Snap 5. I was able to perform the exact same steps as above and end up with a usable system with two disks LVM'd together.
Comment 10 Chris Lumens 2009-07-31 17:04:38 EDT
Great, if this result is reproducable, we should go ahead and close this one out.  Thanks for retesting.
Comment 11 Alexander Todorov 2009-08-03 04:11:35 EDT
Closing this one as per comment #9

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