1894692 – lvcreate behavior change when detected signature is found

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 1894692 - lvcreate behavior change when detected signature is found

Summary: lvcreate behavior change when detected signature is found

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	lvm2
Sub Component:
Version:	8.4
Hardware:	x86_64
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	8.0
Assignee:	Zdenek Kabelac
QA Contact:	cluster-qe@redhat.com
Docs Contact:
URL:
Whiteboard:
Depends On:	1868169
Blocks:
TreeView+	depends on / blocked

Reported:	2020-11-04 19:29 UTC by Corey Marthaler
Modified:	2021-11-04 19:28 UTC (History)
CC List:	13 users (show)
Fixed In Version:	lvm2-2.03.11-1.el8
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:	1868169
Environment:
Last Closed:	2021-05-18 15:02:04 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Comment 2 Corey Marthaler 2020-11-04 19:31:35 UTC

hayes-01: lvcreate  --type raid6_la_6 -R 8192.00k -i 5 -n takeover -l 720 centipede2
WARNING: xfs signature detected on /dev/centipede2/takeover at offset 0. Wipe it? [y/n]: [n]
  Aborted wiping of xfs.
  1 existing signature left on the device.
  Failed to wipe signatures on logical volume centipede2/takeover.
  Aborting. Failed to wipe start of new LV.
couldn't create original volume on hayes-01


kernel-4.18.0-241.el8.dt1    BUILT: Mon Nov  2 08:09:33 CST 2020
lvm2-2.03.11-0.2.20201103git8801a86.el8    BUILT: Wed Nov  4 07:04:46 CST 2020
lvm2-libs-2.03.11-0.2.20201103git8801a86.el8    BUILT: Wed Nov  4 07:04:46 CST 2020
device-mapper-1.02.175-0.2.20201103git8801a86.el8    BUILT: Wed Nov  4 07:04:46 CST 2020
device-mapper-libs-1.02.175-0.2.20201103git8801a86.el8    BUILT: Wed Nov  4 07:04:46 CST 2020

Comment 7 Zdenek Kabelac 2021-01-06 16:05:27 UTC

The logic of wiping has been updated.

Internal devices for raid no longer needs confirmation of zeroing.

Error in wiping will stop whole command.

Comment 11 Corey Marthaler 2021-01-11 22:21:02 UTC

Fix verified in the latest rpms. Side note, all LVM regression testing is now done with the --yes flag to avoid this. 

kernel-4.18.0-271.el8    BUILT: Fri Jan  8 03:32:43 CST 2021
lvm2-2.03.11-0.4.20201222gitb84a992.el8    BUILT: Tue Dec 22 06:33:49 CST 2020
lvm2-libs-2.03.11-0.4.20201222gitb84a992.el8    BUILT: Tue Dec 22 06:33:49 CST 2020


[root@host-087 ~]# pvscan
  PV /dev/sde1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/sdc1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/sdd1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/sdb1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/sdf1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/sdg1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/sdh1   VG VG              lvm2 [<29.99 GiB / <29.99 GiB free]
  PV /dev/vda2   VG rhel_host-087   lvm2 [<7.00 GiB / 1.40 GiB free]
  Total: 8 [216.91 GiB] / in use: 8 [216.91 GiB] / in no VG: 0 [0   ]

[root@host-087 ~]# lvcreate  --type raid6_la_6 -R 8192.00k -i 5 -n takeover -l 720 VG
  Using default stripesize 64.00 KiB.
  Logical volume "takeover" created.
[root@host-087 ~]# mkfs.xfs /dev/VG/takeover 
meta-data=/dev/VG/takeover       isize=512    agcount=8, agsize=92144 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=737152, imaxpct=25
         =                       sunit=16     swidth=80 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=16 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[root@host-087 ~]# lvremove -f VG/takeover 
  Logical volume "takeover" successfully removed

# Verified that the logical volume is no longer auto creating w/o a y answer to the prompt.

[root@host-087 ~]# lvcreate  --type raid6_la_6 -R 8192.00k -i 5 -n takeover -l 720 VG
  Using default stripesize 64.00 KiB.
WARNING: xfs signature detected on /dev/VG/takeover at offset 0. Wipe it? [y/n]: 
  WARNING: Invalid input ''.
WARNING: xfs signature detected on /dev/VG/takeover at offset 0. Wipe it? [y/n]: 
  WARNING: Invalid input ''.
WARNING: xfs signature detected on /dev/VG/takeover at offset 0. Wipe it? [y/n]: ^C  Interrupted...
  Aborted wiping of xfs.
  1 existing signature left on the device.
  Interrupted...
  Interrupted initialization of logical volume VG/takeover.
  Aborting. Failed to wipe start of new LV.

# With the "--yes" it creates the LV

[root@host-087 ~]# lvcreate --yes --type raid6_la_6 -R 8192.00k -i 5 -n takeover -l 720 VG
  Using default stripesize 64.00 KiB.
  Wiping xfs signature on /dev/VG/takeover.
  Logical volume "takeover" created.

Comment 12 Richard W.M. Jones 2021-02-22 09:45:51 UTC

This change broke libguestfs twice, firstly in bug 1869118 / bug 1868169 (RHEL 8.3)
and now in bug 1930996 (RHEL 8.4).  We don't use the --yes option because it
was not needed, and we don't care about existing signatures and want LVM to
just wipe them without prompting.  What can we do to make sure LVM never prompts?

Comment 13 Zdenek Kabelac 2021-02-22 10:06:03 UTC

(In reply to Richard W.M. Jones from comment #12)
> This change broke libguestfs twice, firstly in bug 1869118 / bug 1868169
> (RHEL 8.3)
> and now in bug 1930996 (RHEL 8.4).  We don't use the --yes option because it
> was not needed, and we don't care about existing signatures and want LVM to
> just wipe them without prompting.  What can we do to make sure LVM never
> prompts?

See the comment 4  

When the user does not want lvm2 to check for signatures and prompt for wiping - he needs to disable them in lvm.conf.

I'd advice to use such condition only in controlled environment.

Comment 14 Richard W.M. Jones 2021-02-22 11:49:27 UTC

AIUI those flags disable signature wiping.  What we'd like is for LVM
to wipe without asking.  (Actually what we'd *really* want is for LVM
to always present us with zeroed devices, preferably ones which are
zeroed in the background.)  Anyway for the moment I added lvcreate --yes flag.

Comment 15 Zdenek Kabelac 2021-02-22 12:28:50 UTC

Ahh - so then user is supposed to use --yes in scripts (as default is  'no') - and we always try to make it more and more consistent.
In some case you may need also to use --force.

ATM I'd say it's rather intentional - we require usage of --yes on cmdline - as the command itself is logged in the history of metadata, so we know what has caused data overwrites.

It's not technically difficult to add lvm.conf  'always yes' option - but there is big problem with abuse of such option.

Comment 16 Richard W.M. Jones 2021-02-22 12:30:53 UTC

We made the change in libguestfs on the lvcreate command line.
For libguestfs because we run in a controlled environment with
our own lvm.conf a configuration option might still be helpful.

Comment 17 Nir Soffer 2021-04-05 12:08:16 UTC

This may be a "fix" for inconsistent behavior, but it seems to break also RHV
see bug 1946199.

Comment 18 Zdenek Kabelac 2021-04-06 09:31:51 UTC

(In reply to Nir Soffer from comment #17)
> This may be a "fix" for inconsistent behavior, but it seems to break also RHV
> see bug 1946199.

Please see the comment 4  how to get 'old' behavior aka creation without wiping.
(Lvm2 always tries to provides backward compatibility through lvm.conf setting)

Comment 20 errata-xmlrpc 2021-05-18 15:02:04 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 (lvm2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2021:1659

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