Bug 112082

Summary:	lvm2 finds old raid/pvs in swap partition
Product:	[Retired] Red Hat Raw Hide	Reporter:	Alexandre Oliva <aoliva>
Component:	lvm2	Assignee:	Alasdair Kergon <agk>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	heinzm, k.georgiou, sct
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-03-15 15:32:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	143501

Description Alexandre Oliva 2003-12-14 10:15:31 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202

Description of problem:
At some point, I used /dev/hda2 and /dev/hde2 as members of a raid
device containing a physical volume.  They are now swap partitions,
and are marked as such in the partition types in the partition table.

However, lvm vgscan apparently brought md0 up and then attempted to
scan it for physical volume information, and failed.

I don't think it should disregard the partition type, and I'm not sure
it should attempt to bring up raid devices on its own.

As a work around, I zeroed-out and then re-mkswaped the affected
devices, and now it boots successfully.

Version-Release number of selected component (if applicable):
lvm2-2.00.08-2

How reproducible:
Always

Steps to Reproduce:
1.Create a lvm1 volume group
2.Create a raid device out of a few additional devices
3.Create a physical volume in it
4.Add the physical volume to the volume group
5.Remove it, and stop the raid device.
6.Change the partition types of the former raid members to swap, and
mkswap them
7.Reboot into kernel 2.6

Actual Results:  It fails to boot due to inconsistent information in
the physical volumes.  When you reboot after it fails, it says it's
stopping the raid device that no longer existed.

Expected Results:  It shouldn't bring the device up, and it shouldn't
scan it.

Additional info:

I'm marking this a high priority because random garbage in swap (and
maybe other) devices could cause the system to not boot.  lvm should
use information from the partition table to decide which devices to
bring up/scan.

Comment 1 Alasdair Kergon 2004-03-17 21:16:59 UTC

First point: pvremove was added to LVM2 as the approved way to remove
a PV - this wipes LVM signature from it.

We don't want to include complex partition-handling code in LVM2, nor
do we want to include checks for all the different signatures that
could be on the device.

If there's an external library available to link against which tells
us the partition type of a given device we could optionally use that.
(does libparted offer that?)

Oughtn't the code that interprets the partition table for real record
the partition type for later use?  (/proc/partitions or some replacement?)

Comment 2 Alexandre Oliva 2004-03-21 05:42:07 UTC

It would be sort-of ok for it to scan arbitrary partitions if it
didn't crash because of inconsistent data it found.  But ideally it
shouldn't go scanning partitions that are explicitly marked as of some
other type.  Just consider the disaster if my random data raw block
device happens to contain data that matches exactly whatever lvm
vgscan looks for in order to decide it device looks like a physical
volume?  Or plug a USB key drive with such a partition into the back
USB ports of a server and leave it there, just to confuse the
sysadmins.  Heck, even if it's actually marked as a physical volume,
lvm shouldn't crash.  It should ideally perform some consistency check
of the data it gets before being driven crazy but junk that's in
there, and keep on looking for other physical volumes instead of
crashing.  IMHO :-)

Comment 3 Alasdair Kergon 2004-04-16 21:50:56 UTC

I agree something needs doing about his - treating it as an
enhancement request.

Comment 4 Alasdair Kergon 2004-12-03 15:56:45 UTC

Some improvements to md/partition table handling included in 2.00.29.
Not sure whether or not they address this issue.

Comment 6 Alasdair Kergon 2006-03-15 15:32:11 UTC


*** This bug has been marked as a duplicate of 174700 ***