Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 997223

Summary: lvm2 doesn't clean signatures it can find on newly created LVs (md, swap,crypt-luks)
Product: Red Hat Enterprise Linux 6 Reporter: Mikuláš Patočka <mpatocka>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
lvm2 sub component: Devices, Filtering and Stacking (RHEL6) QA Contact: Cluster QE <mspqa-list>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: agk, dwysocha, heinzm, jbrassow, msnitzer, nperic, prajnoha, prockai, thornber, zkabelac
Version: 6.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: lvm2-2.02.107-1.el6 Doc Type: Enhancement
Doc Text:
Feature: Add support for erasing detected signatures on newly created LVs. Reason: When creating a new LV, it's possible that the new LV will contain signatures from any previous use of this data area. If such signature is positioned within LV in a way that it makes it detectable for any tools scanning the LV (e.g. an automatic blkid scan run within udev for each new LV), we may end up with incorrect assumption that the signature found within LV data area is intended while in real it's not. Result: When creating a new LV and if there's any signature detected (in this LVM2 version it's MD, swap and LUKS signature), LVM tries to erase the signature first before properly activating the new LV. There's also an additional question for the user: "WARNING: <signature name> signature detected on <device name>. Wipe it? [y/n]" to confirm this signature wiping. Also, there's a new lvm.conf option "allocation/wipe_signatures_when_zeroing_new_lvs" (enabled by default) to enable or disable this feature.
 Story Points: ---
Clone Of:
: 1056452 (view as bug list) Environment:
Last Closed: 2014-10-14 08:24:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mikuláš Patočka 2013-08-15 01:17:55 UTC 
Description of problem:
lvm2 doesn't clean md superblocks when creating a new logical volume.

Version-Release number of selected component (if applicable):
LVM 2.02.98(2)-RHEL6

How reproducible:
always

Steps to Reproduce:
1. download files from http://people.redhat.com/mpatocka/testcases/insufficient-cleaning/
2. change the "vg" variable in "insufficient-cleaning-bug" to some your real vg
3. run the script "bash ./insufficient-cleaning-bug"

Actual results:
The script created a logical volume /dev/vg1/clean-test . This logical volume is unusable. It is open and thus we can't create a filesystem there and mount it. It can't be deleted. There is no indication of what keeps the logical volume open.

Expected results:
The logical volume create with lvcreate should not be open and it should be useable.

Additional info:
The bug is caused by the fact that lvm didn't clear the logical volume. lvm clears only the first 8 sectors, however there is md superblock at sector 8 left from previous use. Some script in RHEL6 detects that the newly created logical volume has a md superblock and assigns it to md subsystem (you can see it if you do cat /proc/mdstats).

However, there is no indication to the sysadmin that the newly created logical volume is assigned to md. To the sysadmin, the bug looks quite serious - the newly create volume is unusable and undeletable and it couldn't be easily find what keeps it open.

LVM should use something like wipefs on new logical volumes to prevent this case.
Comment 1 Peter Rajnoha 2013-08-15 12:16:38 UTC 
Just for the record: even if wiping, there's still a possibility of a race with udev - bug #796200. So yes, we need to handle this somehow better...
Comment 3 Zdenek Kabelac 2013-08-19 14:29:53 UTC 
I guess every new created LV must be first activated with those udev invisible flags and just after clearing the flags could be changed to visible if needed.
(DM_UDEV_DISABLE_DISK/OTHER_RULES_FLAG)

Question is if there is chance to make this without  deactivate()/activate().

Other way around is to implement direct PV clearing - which seems to be the best - but hard...
Comment 4 Peter Rajnoha 2013-11-27 15:03:37 UTC 
I've committed the patchset that reuses existing signature wiping known from pvcreate and uses it for lvcreate as well. Also, I've added an optional/configurable blkid wiping (that has richer support for more signatures). I'll post some examples/tests soon...

The patchset:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=03c941a4caf411f21045670e205ccdd975be27c7

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=5b7e543cae5be52e1dcd79c7f6876acc89138cf1

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=169b4c15864330e3fe47efee7b0def06581b8f08

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=b6dab4e0598df7b6a44a32749fdb846c03aa692d

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=9bfc0be493192958f5dbffea4eb7dda968062261

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=ab2f858af7a72448b6c015a5984c73f5cdaf3664

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=eaa23d32732c9bc3dd4f948781b5764cf21d84ba

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=5968f07fd5ccb2b7d4e407cd8fec86b0b1f80f3a
Comment 7 Peter Rajnoha 2014-03-27 14:35:07 UTC 
The key here is to create an LV and then create something else on top of that LV (something that writes its own signatures), then remove the LV and then create it again (on the same VG/PV) - the lvcreate should detect the signature previously used.

It may be the MD like mentioned here:

[0] raw/~ # pvcreate /dev/sda        
  Physical volume "/dev/sda" successfully created

[0] raw/~ # vgcreate vg /dev/sda
  Volume group "vg" successfully created

[0] raw/~ # lvcreate -l50%FREE vg
  Logical volume "lvol0" created

[0] raw/~ # lvcreate -l50%FREE vg
  Logical volume "lvol1" created

[0] raw/~ # mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/vg/lvol0 /dev/vg/lvol1
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: largest drive (/dev/vg/lvol0) exceeds size (32704K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

[0] raw/~ # mdadm -S /dev/md0
mdadm: stopped /dev/md0

[0] raw/~ # lvremove -ff vg
  Logical volume "lvol0" successfully removed
  Logical volume "lvol1" successfully removed

[0] raw/~ # lvcreate -l50%FREE vg
WARNING: linux_raid_member signature detected on /dev/vg/lvol0 at offset 4096. Wipe it? [y/n] y
  Wiping linux_raid_member signature on /dev/vg/lvol0.
  Logical volume "lvol0" created

[0] raw/~ # lvcreate -l50%FREE vg
WARNING: linux_raid_member signature detected on /dev/vg/lvol1 at offset 4096. Wipe it? [y/n] y
  Wiping linux_raid_member signature on /dev/vg/lvol1.
  Logical volume "lvol1" created


(...especially for the MD, if you answer "N", you'll see that there's the previous MD devices activated on top - you can check the lsblk output, you'll see something like this:

[0] raw/~ # lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda               8:0    0  128M  0 disk  
|-vg-lvol0      253:2    0   60M  0 lvm   
| `-md0           9:0    0   32M  0 raid1 
`-vg-lvol1      253:3    0   32M  0 lvm   
  `-md0           9:0    0   32M  0 raid1 

While when the signature is removed, you'll see it without the "md0" activated.



Or it may be swap:

[0] raw/~ # lvcreate -l50%FREE vg
  Logical volume "lvol0" created

[0] raw/~ # mkswap /dev/vg/lvol0
Setting up swapspace version 1, size = 61436 KiB
no label, UUID=3e898654-9741-4c42-b815-012fbd8dc460

[0] raw/~ # lvremove -ff vg
  Logical volume "lvol0" successfully removed

[0] raw/~ # lvcreate -l50%FREE vg
WARNING: swap signature detected on /dev/vg/lvol0 at offset 4086. Wipe it? [y/n] y
  Wiping swap signature on /dev/vg/lvol0.
  Logical volume "lvol0" created


Or it may be a filesystem:

[0] raw/~ # lvcreate -l50%FREE vg
  Logical volume "lvol0" created
[0] raw/~ # mkfs.ext4 /dev/vg/lvol0 
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
15360 inodes, 61440 blocks
3072 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=62914560
8 block groups
8192 blocks per group, 8192 fragments per group
1920 inodes per group
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

[0] raw/~ # lvremove -ff vg
  Logical volume "lvol0" successfully removed

[0] raw/~ # lvcreate -l50%FREE vg
WARNING: ext4 signature detected on /dev/vg/lvol0 at offset 1080. Wipe it? [y/n] y
  Wiping ext4 signature on /dev/vg/lvol0.
  Logical volume "lvol0" created


....and anything from the "blkid -k" list :)
Comment 9 Nenad Peric 2014-07-29 13:01:05 UTC 
Due to the old version of libblkid the discovery of signatures cannot be used directly. The internal LVM detection (discovery) is used, and it discovers only:

swap
cryptsetup and
md 

blkid utility is too old in RHEL6 as well, and does not support the -k switch. 


The QA will only test md, cryptsetup and swap devices/signatures.
Comment 14 Nenad Peric 2014-08-01 11:25:29 UTC 
[root@tardis-01 ~]# mkswap /dev/vg/swap_lv 
mkswap: /dev/vg/swap_lv: warning: don't erase bootbits sectors
        on whole disk. Use -f to force.
Setting up swapspace version 1, size = 1048572 KiB
no label, UUID=a454d649-7981-45e4-8b19-4e1a1c365165

[root@tardis-01 ~]# pvcreate /dev/vg/swap_lv 
WARNING: swap signature detected on /dev/vg/swap_lv. Wipe it? [y/n]: n
  Aborted wiping of swap signature.
  Aborting pvcreate on /dev/vg/swap_lv.


[root@tardis-01 ~]# lvremove -ff vg
  Logical volume "swap_lv" successfully removed

[root@tardis-01 ~]# lvcreate -l100%FREE vg -n new_lv
WARNING: swap signature detected on /dev/vg/new_lv. Wipe it? [y/n]: y
  Wiping swap signature on /dev/vg/new_lv.
  Logical volume "new_lv" created


Created LUKS on md0 raid device. Then tried to use that md as a source for a new PV:

[root@tardis-01 ~]# cryptsetup luksClose cryptodev
[root@tardis-01 ~]# pvcreate /dev/md0
WARNING: LUKS signature detected on /dev/md0. Wipe it? [y/n]: n
  Aborted wiping of LUKS signature.
  Aborting pvcreate on /dev/md0.
[root@tardis-01 ~]# 

deactivating luks and stopping raid:

[root@tardis-01 ~]# mdadm -S /dev/md0
mdadm: stopped /dev/md0
[root@tardis-01 ~]# lvremove -ff vg
  Logical volume "one" successfully removed
  Logical volume "two" successfully removed

[root@tardis-01 ~]# lvcreate -l100%FREE vg -n new_lv
WARNING: software RAID md superblock detected on /dev/vg/new_lv. Wipe it? [y/n]: y
  Wiping software RAID md superblock on /dev/vg/new_lv.
  Logical volume "new_lv" created
[root@tardis-01 ~]# 



Marking this as VERIFIED with:

2.6.32-492.el6.x86_64

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 15 errata-xmlrpc 2014-10-14 08:24:40 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