Bug 139058 (IT_54714:IT_55916) - Partially deleted volume groups cause inability to detect or remove or create a new one
Summary: Partially deleted volume groups cause inability to detect or remove or create...
Alias: IT_54714:IT_55916
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2   
(Show other bugs)
Version: 4.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Jeremy Katz
QA Contact:
: 138224 (view as bug list)
Depends On:
Blocks: 140583
TreeView+ depends on / blocked
Reported: 2004-11-12 19:12 UTC by Jeremy Katz
Modified: 2007-11-30 22:07 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-10 14:53:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jeremy Katz 2004-11-12 19:12:04 UTC
If you have a volume group with two physical volumes called VolGroup00 and then
you reformat one of the volumes as something else leaving only part of the
volume group present, you can end up in a state where
a) vgdisplay doesn't show that VolGroup00 exists (without parsing stderr anyway,
which kind of defeats the purpose of having a well-formed output mode)
sh-3.00# lvm vgdisplay
  Couldn't find device with uuid 'hM7BId-KfUk-IaA3-5Rgr-XOHP-U5Xu-DLrfDu'.
  Couldn't find all physical volumes for volume group VolGroup00.
  Volume group "VolGroup00" doesn't exist
b) vgremove won't let you remove it even if it was detectable
sh-3.00# lvm vgremove VolGroup00
  Couldn't find device with uuid 'hM7BId-KfUk-IaA3-5Rgr-XOHP-U5Xu-DLrfDu'.
  Couldn't find all physical volumes for volume group VolGroup00.
  Volume group "VolGroup00" doesn't exist
c) vgcreate won't let you create a new VolGroup00
sh-3.00# lvm vgcreate -v -An -s 32768k VolGroup00 /dev/sda2
  Couldn't find device with uuid 'hM7BId-KfUk-IaA3-5Rgr-XOHP-U5Xu-DLrfDu'.
  A volume group called 'VolGroup00' already exists.

This puts the installer in a position where there is *nothing* that I can do to
get the user created with volume groups aside from switching the volgroup naming
to be random (which is absurd).

Yet another case where a --force option would be very useful.

Comment 3 Alasdair Kergon 2004-11-15 15:39:45 UTC
But where does the pvcreate fit into that?

lvm2 works on the principle that tools will not automatically change
any metadata if they find serious inconsistencies - otherwise they
might destroy data that needed recovering not destroying.  Metadata
must be made consistent again using recovery tools or --force options

The tools can't be allowed to vgcreate a VG if there's a PV already
present that thinks it's in a VG together with another PV that has
gone missing in an uncontrolled way (e.g. by removing the disk or
overwriting it or changing lvm filters or by using a --force option).

All the remnants of the old VG must be removed first, e.g. with
pvremove or pvcreate -ff (followed by a vgscan for good measure).

Also, in lvm2, parsing of XXdisplay output should be avoided as the
format is meant to be user-readable and is liable to be changed - vgs,
lvs & pvs provide a stable format that should be used instead.

Let's make time to walk through the anaconda/lvm2 interactions in
Boston and see what needs to change on both side to make them even
more robust.

Comment 4 Jeremy Katz 2004-11-15 15:52:19 UTC
*** Bug 138224 has been marked as a duplicate of this bug. ***

Comment 5 Jeremy Katz 2004-11-15 22:26:05 UTC
*** Bug 139418 has been marked as a duplicate of this bug. ***

Comment 6 Larry Troan 2004-11-24 18:52:07 UTC
Bug 139418 was on rc1 BLOCKER list. This bug is SHOULDFIX. 

Per RH Engineering meeting last Tuesday, Jeremy feels this is a
SHOULDFIX rather than a ship blocker and that a knowledgebase entry
should be sufficient if the fix does not make rc1.

Comment 8 Brian Baker 2004-12-01 20:01:38 UTC
We are seeing this as well.  Why is this a shouldfix instead of a 
blocker?  This means if a customer tries to install RH EL 4 over a 
drive that's been used before, the install may fail.  

Comment 9 Glen A. Foster 2004-12-02 16:41:32 UTC
Another precint heard from: customers could ultimately see a brand-new
system with a completely new, shiny set of CDs barf on the first
install.  Not a good first impression.  I agree with Brian (and with
my initial recommendation) that this is a MUST-fix.

Please consider re-prioritizing this higher.

Comment 10 Alasdair Kergon 2004-12-08 15:33:16 UTC
Discussed in Westford last week: there's a --partial flag anaconda can
pass to the lvm2 tools to detect incomplete VGs and then it can know
to use a different vg name that doesn't conflict.

Comment 11 Jeremy Katz 2004-12-08 15:59:15 UTC
And added the implementation to use --partial

Comment 12 Brian Baker 2004-12-08 18:07:47 UTC
Is there a way we can test this before pre-rc2?  I'm looking at the 
holiday schedule and noticing there's not much time then...I've also 
got another issue that I think is a duplicate of this but not sure 
and would like to try this fix for it as well.

Comment 13 Larry Troan 2005-01-05 21:43:39 UTC
From Rick Hester at HP in Issue Tracker:
 ------- Additional Comment #6 From Rick Hester (rick.hester@hp.com) on
2004-12-23 12:56 -------

Installed with rhel4prerc2 on a system where all the partition
tables had been removed with parted.  No traceback occurred.

------- Additional Comment #7 From Rick Hester (rick.hester@hp.com) on
2004-12-24 15:20 -------

I spoke too soon.

Comment 6 was with an install onto an rx8620.

But an install to an rx1600 with blank disks does create
a traceback - using rhel4 pre-RC2 bits.

Installation was to sda with partitioning defaults supplied
by Autopartition.  sdb, sdd - sdp were all free space.

I will attach console output in case it is helpful.

Comment 14 Larry Troan 2005-01-05 21:48:43 UTC
See Bug 139418

Comment 15 Jeremy Katz 2005-01-05 21:49:53 UTC
... all tracebacks are not created equal.  You could be hitting a completely
different traceback, but without it attached, it's impossible to say.

Comment 16 Jeremy Katz 2005-01-05 21:51:04 UTC
Larry, this is something *COMPLETELY DIFFERENT*.

Comment 17 Jay Turner 2005-02-10 13:32:15 UTC
Can we close this one out?  I think we can, but just checking.

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