RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1113539 - Always reevaluate filters before creating a PV - do not rely on a persistent filter which may contain old info
Summary: Always reevaluate filters before creating a PV - do not rely on a persistent ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.6
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Peter Rajnoha
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-26 11:32 UTC by Peter Rajnoha
Modified: 2014-10-14 08:25 UTC (History)
9 users (show)

Fixed In Version: lvm2-2.02.108-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: If persistent filter was used (/etc/lvm/cache/.cache) and if we created a new PV, filters were not reevaluated to pick up any changes that may have correctly prevented the PV create process to succeed. Consequence: LVM saw the state of the device as it was during last time LVM evaluated filters and wrote out the persistent filter. However, the device may have changed since then outside LVM which caused LVM to not take into account these changes while creating a new PV - these are changes like adding a partition table to disk or device having a new signature that prevents the device to be used as LVM PV. Without up-to-date information, LVM may end up overwriting existing foreign signatures. Fix: Filters are now always reevaluated before PV creation. Result: If there was any change done outside LVM after last filter evaluation in LVM, these changes are now properly considered before PV creation. This can prevent LVM overwriting existing foreign signatures.
Clone Of:
Environment:
Last Closed: 2014-10-14 08:25:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1387 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2014-10-14 01:39:47 UTC

Description Peter Rajnoha 2014-06-26 11:32:39 UTC 
RHEL6 version of lvm2 uses devices/obtain_device_list_from_udev=0 by default. As such, the persistent filter is used if it exists - this is the /etc/lvm/cache/.cache.  This file contains list of devices which passed filtering before and the state is saved for next lvm commands to speedup filtering part.

However, in case of pvcreate, we should wipe any existing persistent filter and reevaluate filters again. Otherwise there's a possibility that someone changed the device and it's partitioned now or it's used as part of other block subsystems (mpath or md). In this case, if the persistent filter is not updated, we could overwrite any existing signatures or use improper device for a PV - pvcreate should stop us from doing that.

See also bug #1094162 comment #6.

This should be patched now with:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=e80884cd080cad7e10be4588e3493b9000649426
Comment 4 Peter Rajnoha 2014-08-01 11:01:09 UTC 
There is one regression that the patch mentioned in comment #0 caused. There's a bug #1120564 to cover that (it's about wrong .cache file generated after vgcreate VG PV where the PV is created together with the VG and obtain_device_list_from_udev=0 and so the .cache is used).
Comment 5 Peter Rajnoha 2014-08-01 11:27:49 UTC 
To QA:

A simple reproducer may be:

- make sure you have obtain_device_list_from_udev=0 in lvm.conf

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "fedora" using metadata type lvm2

# grep sda /etc/lvm/cache/.cache 
		"/dev/sda",

# parted /dev/sda mklabel gpt         
Information: You may need to update /etc/fstab.



Before the fix:

(/dev/sda still in .cache as usable device!)
# grep sda /etc/lvm/cache/.cache 
		"/dev/sda",

(pvcreate not noticing /dev/sda is parted!)
# pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created



With the fix:

(/dev/sda still in .cache as usable device - .cache is not update until lvm command is run!)
# grep sda /etc/lvm/cache/.cache 
		"/dev/sda",

# pvcreate /dev/sda
  Device /dev/sda not found (or ignored by filtering).

# pvcreate /dev/sda -vvvv 2>&1 | grep sda | grep signature
#filters/filter-partitioned.c:45         /dev/sda: Skipping: Partition table signature found
Comment 6 Nenad Peric 2014-08-04 11:21:37 UTC 
Changed the partitioning on an already partitioned device, which caused the LVM to ignore the PV as expected (since 'obtain_device_list_from_udev' was off)

[root@tardis-01 ~]# grep sd /etc/lvm/cache/.cache 
		"/dev/sda1",
		"/dev/sdb1",
		"/dev/sdc1",
		"/dev/sdg1",
		"/dev/sdd1",
		"/dev/sde1",
		"/dev/sdf1",
		"/dev/sdh1",
		"/dev/sdi1",
		"/dev/sdj1",
		"/dev/sdk1",
		"/dev/sda2",
[root@tardis-01 ~]# parted /dev/sdc mklabel gpt
Warning: The existing disk label on /dev/sdc will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
Information: You may need to update /etc/fstab.    

[root@tardis-01 ~]# grep sd /etc/lvm/cache/.cache 
		"/dev/sda1",
		"/dev/sdb1",
		"/dev/sdc1",
		"/dev/sdg1",
		"/dev/sdd1",
		"/dev/sde1",
		"/dev/sdf1",
		"/dev/sdh1",
		"/dev/sdi1",
		"/dev/sdj1",
		"/dev/sdk1",
		"/dev/sda2",
[root@tardis-01 ~]# pvcreate /dev/sdc
  Physical volume /dev/sdc not found
  Device /dev/sdc not found (or ignored by filtering).


marking VERIFIED with:

lvm2-2.02.108-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
lvm2-libs-2.02.108-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
lvm2-cluster-2.02.108-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
udev-147-2.56.el6    BUILT: Fri Jul 11 16:53:07 CEST 2014
device-mapper-1.02.87-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
device-mapper-libs-1.02.87-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
device-mapper-event-1.02.87-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
device-mapper-event-libs-1.02.87-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
device-mapper-persistent-data-0.3.2-1.el6    BUILT: Fri Apr  4 15:43:06 CEST 2014
cmirror-2.02.108-1.el6    BUILT: Thu Jul 24 17:29:50 CEST 2014
Comment 7 errata-xmlrpc 2014-10-14 08:25:19 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1387.html
Note You need to log in before you can comment on or make changes to this bug.