Bug 488354 - pvcreate does not wipe swap label
pvcreate does not wipe swap label
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Petr Rockai
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2009-03-03 16:08 EST by Issue Tracker
Modified: 2011-02-16 08:55 EST (History)
11 users (show)

See Also:
Fixed In Version: lvm2-2.02.42-8.el4
Doc Type: Bug Fix
Doc Text:
This update ensures that the pvcreate utility correctly detects and conditionally wipes swap space signatures.
Story Points: ---
Clone Of:
Last Closed: 2011-02-16 08:55:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Issue Tracker 2009-03-03 16:08:03 EST
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2009-03-03 16:08:05 EST

when doing mkswap /dev/dm-xx
then pvcreate /dev/dm-xx

the swap label is still there, because pvcreate does only wipe the first 2 Kbytes of a device(means md and other lvm headers). It should also wipe swap headers (4Kbytes)

See pvcreate.c Line 238 lvm version 2.02.27. 

We destroyed a productive Filesystem, because our rescue image (fedora live cd) took all swap partition with a valid label online. But the device was a lvm volume with data on it. pvcreate should therefore guarantee that the swap label is removed. 

This event sent from IssueTracker by dejohnso  [Support Engineering Group]
 issue 190871
Comment 2 Issue Tracker 2009-03-03 16:08:07 EST
you are correct, parts of the swap header are above 2k:
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32 

I've done some tests with a loop device, rhel4.5 does not allow you to do
a swapon after the pvcreate:

[root@dhcp-1-31 tmp]# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
[root@dhcp-1-31 tmp]# uname -a
Linux dhcp-1-31.fab.redhat.com 2.6.9-55.ELxenU #1 SMP Fri Apr 20 17:30:23
EDT 2007 i686 i686 i386 GNU/Linux
[root@dhcp-1-31 tmp]# dd of=loopfile bs=1M count=0 seek=204
0+0 records in
0+0 records out
[root@dhcp-1-31 tmp]# losetup /dev/loop0 loopfile
[root@dhcp-1-31 tmp]# mkswap /dev/loop0
Setting up swapspace version 1, size = 213905 kB
[root@dhcp-1-31 tmp]# swapon /dev/loop0
[root@dhcp-1-31 tmp]# swapoff /dev/loop0
[root@dhcp-1-31 tmp]# pvcreate /dev/loop0
 Physical volume "/dev/loop0" successfully created
[root@dhcp-1-31 tmp]# swapon /dev/loop0
swapon: /dev/loop0: Invalid argument

I've transfered the loopback file to a fc9 installation, same result:

[root@localhost tmp]# cat /etc/redhat-release 
Fedora release 9 (Sulphur)
[root@localhost tmp]# losetup -d /dev/loop0
[root@localhost tmp]# losetup /dev/loop0 loopfile
[root@localhost tmp]# swapon /dev/loop0
swapon: /dev/loop0: Invalid argument
Comment 3 Issue Tracker 2009-03-03 16:08:09 EST
General Escalation Information

   1. Provide time and date of the problem

- 07-10-2008 01:17pm CEST

   2. Provide clear and concise problem description as it is understood at
the t
ime of escalation

          * Observed behavior

- The customer used some devices as swapspace in the past. Later they used
them as PV (ran pvcreate). 
After booting the rhel4.5 system with a fedora live rescue cd, those PV
devices were brought up as swapspace, resulting in data loss.
I could not reproduce that, see my last post, but the customer thinks that
pvcreate should wipe not only the first 2k but 4k of the device.

          * Desired behavior 

- pvcreate should wipe enough bytes to completely remove any swap

   3. State specific action requested of SEG

- please clarify if we should wipe more than 2k

   4. State whether or not a defect in the product is suspected

- I don't really know. I could not reproduce it, but pieces of the swap
header are still there after pvcreate:
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32 

Provide supporting info

1. State other actions already taken in working the problem:

- Tried to reproduce the issue, verified pvcreate.c, talked to another
TAM, did a fulltext search. Please look at BZ 443062
Comment 4 Issue Tracker 2009-03-03 16:08:13 EST

This is indeed an issue.  The problem is in the lvm2 library..

lib/label/label.c with the function..

int label_remove(struct device *dev)

This function writes zeros to the size of LABEL_SIZE not taking into
account larger labels such as swap.  A simple fix would be to write 0s to
the size of LABEL_SIZE * 2 but I am not sure that development would agree
so I am creating a BZ.


This event sent from IssueTracker by dejohnso  [Support Engineering Group]
 issue 190871
Comment 5 Alasdair Kergon 2009-03-03 16:23:40 EST
label_remove() is correct as it is: It is purely concerned with LVM labels.

What we can do is add specific code in pvcreate.c to recognise a swap signature and ask the user whether or not to remove it - same as we do if we see a software raid md superblock.

Ultimately this code should use a central library (shared with all the other apps that format devices) to deal with these cases.
Comment 6 Petr Rockai 2009-03-04 07:18:24 EST
Yes, this is just a RHEL4 dupe of BZ443062. The proposed stop-gap measure is to clear a page-sized area of the device to catch swap signatures. I am not convinced detection is necessary, although it might be marginally useful.

Anyway, I will look into the issue.
Comment 11 Petr Rockai 2009-03-09 11:56:27 EDT
From man mkswap:
> Linux  knows about two styles of swap areas, old style and new style.  The
> last 10 bytes of the first page of the swap area distinguishes  them:  old
> style has ‘SWAP_SPACE’, new style has ‘SWAPSPACE2’ as signature.

Alasdair says he wants an interactive prompt and only erase the swap signature when it's present, not touching the optional 2K wipe. This means we need to check on a few places for "SWAP_SPACE" or "SWAPSPACE2", ie. on all useful page-size boundaries (4096, 8192 at very least, maybe sparc can use 64K-paged swap).

The other option would be to defer to a more general label-detection library (I believe there's one being worked on by someone). I'll report back when I know more about that.
Comment 12 Petr Rockai 2009-08-03 02:19:00 EDT
This has been checked into upstream codebase on 17th of March, so this has been part of 2.02.46 already. I.e. good to go.
Comment 14 Milan Broz 2010-10-21 13:16:13 EDT
Fixed in lvm2-2.02.42-8.el4.
Comment 16 Corey Marthaler 2011-01-19 16:23:32 EST
Marking verified in the latest rpms.


lvm2-2.02.42-9.el4    BUILT: Thu Oct 21 15:49:57 CDT 2010
lvm2-cluster-2.02.42-10.el4    BUILT: Tue Jan 18 06:17:17 CST 2011
device-mapper-1.02.28-3.el4    BUILT: Thu Mar  4 14:48:16 CST 2010
cmirror-1.0.2-1.el4    BUILT: Thu Feb 26 15:29:27 CST 2009
cmirror-kernel-2.6.9-43.14.el4    BUILT: Wed Dec 22 16:24:19 CST 2010

[root@grant-01 ~]# mkswap /dev/sdb1
Setting up swapspace version 1, size = 36569554 kB

[root@grant-01 ~]# dd if=/dev/sdb1 count=8
r;ˆ¡þ•w0LˆÔ™\Ë©°SWAPSPACE28+0 records in
8+0 records out

[root@grant-01 ~]# pvcreate /dev/sdb1
  Wiping swap signature on /dev/sdb1
  Physical volume "/dev/sdb1" successfully created

[root@grant-01 ~]# dd if=/dev/sdb1 count=8
LABELONEÜ"ˆ LVM2 001nLuBkFAeK8ehmEXxgsHPK4BmZvV3QtHP>·ð8+0 records in
8+0 records out
Comment 17 Jaromir Hradilek 2011-01-20 07:48:15 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    New Contents:
This update ensures that the pvcreate utility correctly detects and conditionally wipes swap space signatures.
Comment 18 errata-xmlrpc 2011-02-16 08:55:46 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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