Bug 443065 - mkswap does not zero out old pvcreate signatures
Summary: mkswap does not zero out old pvcreate signatures
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux-ng
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-18 13:58 UTC by Eric Sandeen
Modified: 2009-03-31 10:17 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-31 10:17:12 UTC


Attachments (Terms of Use)

Description Eric Sandeen 2008-04-18 13:58:42 UTC
this sequence on a machine with 4k page size:

xfs_io -F -c "pwrite 0 4096" /dev/sdb2
pvcreate -u 92e4895d-a9c2-4a70-8f02-b8f67372e506 /dev/sdb2
mkswap -U 92e4895d-a9c2-4a70-8f02-b8f67372e506 /dev/sdb2

generates exactly the same first 4k on the block device as this sequence:

xfs_io -F -c "pwrite 0 4096" /dev/sdb2
mkswap -U 92e4895d-a9c2-4a70-8f02-b8f67372e506 /dev/sdb2
pvcreate -u 92e4895d-a9c2-4a70-8f02-b8f67372e506 /dev/sdb2

making it awfully hard to know if the device is truly swap or not:

00000000  cd cd cd cd cd cd cd cd  cd cd cd cd cd cd cd cd  |................|
*
00000200  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000210  19 e6 90 d1 20 00 00 00  4c 56 4d 32 20 30 30 31  |.... ...LVM2 001|
00000220  39 32 65 34 38 39 35 64  61 39 63 32 34 61 37 30  |92e4895da9c24a70|
00000230  38 66 30 32 62 38 66 36  37 33 37 32 65 35 30 36  |8f02b8f67372e506|
00000240  00 d0 2d e6 1b 00 00 00  00 00 03 00 00 00 00 00  |..-.............|
00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000260  00 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000270  00 f0 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000280  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  01 00 00 00 dc 62 be 01  00 00 00 00 92 e4 89 5d  |.....b.........]|
00000410  a9 c2 4a 70 8f 02 b8 f6  73 72 e5 06 00 00 00 00  |..Jp....sr......|
00000420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32  |......SWAPSPACE2|
00001000

(the xfs_io command simply patterns the first 4k to make it obvious what has
been re-written)

It seems like it would be wise for mkswap to zero out a bit more of the device,
to eliminate old lvm2 signatures or anything else that might be out there. 
(although I see in the source that various spots take care not to clobber
disklabels and such...)

Thanks,
-Eric

Comment 1 Karel Zak 2008-04-28 22:37:36 UTC
Well, this is pretty common and often reported problem. It seems we need a
solution, but... from mkswap man page:

   The  new  style  header does  not  touch  the  first block, so may 
   be preferable, in case you have a boot loader or disk label there.

so my question is: is it safe to zero out the device? 

I see that (for example) mkfs.e2fs checks for BSD labels and zaps few blocks...
but is it enough for swap area? I have no clue.



Comment 2 Bug Zapper 2008-05-14 09:38:29 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Karel Zak 2009-03-31 10:17:12 UTC
The problem has been fixed in util-linux-ng v2.15-rc1 upstream release. The release should be included in F-12 and (probably) RHEL6.


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