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 1657320 - "atari signature detected" during pvcreate attempts of luks volumes
Summary: "atari signature detected" during pvcreate attempts of luks volumes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Ondrej Kozina
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-07 16:22 UTC by Corey Marthaler
Modified: 2023-12-15 16:16 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-15 19:48:35 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Corey Marthaler 2018-12-07 16:22:28 UTC 
Description of problem:
We just started seeing this in rhel8 while setting up PVs on top of luks volumes.

10 disk(s) to be used:
     hayes-01=/dev/sdd /dev/sdc /dev/sdb /dev/sdj /dev/sde /dev/sdh /dev/sdi /dev/sdg /dev/sdk /dev/sdf

on hayes-01...
dicing /dev/sdd into 1... 
dicing /dev/sdc into 1... 
dicing /dev/sdb into 1... 
dicing /dev/sdj into 1... 
dicing /dev/sde into 1... 
dicing /dev/sdh into 1... 
dicing /dev/sdi into 1... 
dicing /dev/sdg into 1... 
dicing /dev/sdk into 1... 
dicing /dev/sdf into 1... 
re-reading disks on hayes-01...
Zeroing out the new partitions.../dev/sdd1.../dev/sdc1.../dev/sdb1.../dev/sdj1.../dev/sde1.../dev/sdh1.../dev/sdi1.../dev/sdg1.../dev/sdk1.../dev/sdf1...

Creating crypt volumes on the following storage: /dev/sdd1 /dev/sdc1 /dev/sdb1 /dev/sdj1 /dev/sde1 /dev/sdh1 /dev/sdi1 /dev/sdg1 /dev/sdk1 /dev/sdf1
cryptsetup luksFormat /dev/sdd1
cryptsetup luksOpen /dev/sdd1 cPV1
cryptsetup luksFormat /dev/sdc1
cryptsetup luksOpen /dev/sdc1 cPV2
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 cPV3
cryptsetup luksFormat /dev/sdj1
cryptsetup luksOpen /dev/sdj1 cPV4
cryptsetup luksFormat /dev/sde1
cryptsetup luksOpen /dev/sde1 cPV5
cryptsetup luksFormat /dev/sdh1
cryptsetup luksOpen /dev/sdh1 cPV6
cryptsetup luksFormat /dev/sdi1
cryptsetup luksOpen /dev/sdi1 cPV7
cryptsetup luksFormat /dev/sdg1
cryptsetup luksOpen /dev/sdg1 cPV8
cryptsetup luksFormat /dev/sdk1
cryptsetup luksOpen /dev/sdk1 cPV9
cryptsetup luksFormat /dev/sdf1
cryptsetup luksOpen /dev/sdf1 cPV10

creating lvm devices...
hayes-01: pvcreate /dev/mapper/cPV10 /dev/mapper/cPV9 /dev/mapper/cPV8 /dev/mapper/cPV7
WARNING: atari signature detected on /dev/mapper/cPV8 at offset 466. Wipe it? [y/n]: [n]
  Aborted wiping of atari.
  1 existing signature left on the device.   
WARNING: atari signature detected on /dev/mapper/cPV7 at offset 466. Wipe it? [y/n]: [n]
  Aborted wiping of atari.
  1 existing signature left on the device.   
couldn't pvcreate /dev/mapper/cPV10 /dev/mapper/cPV9 /dev/mapper/cPV8 /dev/mapper/cPV7 on hayes-01


Version-Release number of selected component (if applicable):
cryptsetup-2.0.6-1.el8    BUILT: Mon Dec  3 07:46:20 CST 2018
cryptsetup-libs-2.0.6-1.el8    BUILT: Mon Dec  3 07:46:20 CST 2018
cryptsetup-reencrypt-2.0.6-1.el8    BUILT: Mon Dec  3 07:46:20 CST 2018

kernel-4.18.0-49.el8    BUILT: Tue Dec  4 06:01:31 CST 2018
lvm2-2.03.01-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
lvm2-libs-2.03.01-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
lvm2-dbusd-2.03.01-1.el8    BUILT: Thu Nov  1 04:31:09 CDT 2018
lvm2-lockd-2.03.01-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
device-mapper-1.02.153-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
device-mapper-libs-1.02.153-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
device-mapper-event-1.02.153-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
device-mapper-event-libs-1.02.153-1.el8    BUILT: Thu Nov  1 04:29:08 CDT 2018
device-mapper-persistent-data-0.7.6-1.el8    BUILT: Sun Aug 12 04:21:55 CDT 2018


How reproducible:
Often
Comment 2 Ondrej Kozina 2018-12-07 17:36:19 UTC 
This may happen due to atari signature being too short and therefore often detected by mistake even with pseudo-random data on new unlocked LUKS device.

Karel, do you have any idea if there's a way to improve blkid scan so that it doesn't find the signature so often?

Otherwise I can only advise to wipe all /dev/mapper/cPV* devices first or just run pvcreate -y.
Comment 3 Karel Zak 2018-12-10 14:54:05 UTC 
I think call "wipefs -a" is a good idea to avoid wrong interpretation of the random data ;-) 

Unfortunately, I do not see a way how to make libblkid atari probing function more robust...
Comment 8 Jonathan Earl Brassow 2021-11-15 19:48:35 UTC 
closing WONTFIX - workaround is to wipe the device.
Comment 9 Gabríel Arthúr Pétursson 2021-11-17 16:33:21 UTC 
@jbrassow Can you please advice how this workaround may be implemented from within a Kickstart installation? Partition layout in Kickstart is declarative and there doesn't appear to be a way to request a wipe of the luks block-device before Kickstart attempts to probe for an existing filesystem.

This is the relevant excerpt from our Kickstart template:

	# Disk partitioning information
	clearpart --all --initlabel --drives=sda
	part /boot --fstype="xfs" --ondisk=sda --size=1024
	part /boot/efi --fstype="efi" --ondisk=sda --size=200 --fsoptions="umask=0077,shortname=winnt"

	part pv.157 --fstype="lvmpv" --ondisk=sda --size=15158 --grow --encrypted --passphrase=setup --luks-version=luks2
	volgroup el_{{inventory_hostname_short}} --pesize=4096 pv.157
	logvol swap --fstype="swap" --size=1024 --name=swap --vgname=el_{{inventory_hostname_short}}
	logvol / --fstype="xfs" --size=14128 --name=root --vgname=el_{{inventory_hostname_short}}

We were hoping for a proper bugfix as we occasionally encounter this "atari" bug when performing automatic installations on our servers.

Thanks!
Comment 10 Red Hat Bugzilla 2023-09-15 00:14:31 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days
Note You need to log in before you can comment on or make changes to this bug.