Bug 365041 - mkswap needs to clear signatures
mkswap needs to clear signatures
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: util-linux-ng (Show other bugs)
rawhide
i386 Linux
low Severity low
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-03 04:46 EDT by Leszek Matok
Modified: 2008-01-23 07:59 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-23 07:59:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leszek Matok 2007-11-03 04:46:03 EDT
After upgrading my main machine's F7 to development today (or can I call it F8
already?), I noticed new devices in my Nautilus. First is a fixed partition
mounted from fstab for ages. I believe there's another bug for this as I've seen
mention of that on fedora-devel.

Second is a device called "ROOT", which my unprivileged user can't mount (it
says I don't have rights). What's that? Let's see:
# lshal -l -u /org/freedesktop/Hal/devices/volume_uuid_374C_1F00
udi = '/org/freedesktop/Hal/devices/volume_uuid_374C_1F00'
  block.device = '/dev/sda1'  (string)
(...)
  volume.fstype = 'vfat'  (string)
  volume.fsusage = 'filesystem'  (string)
  volume.fsversion = 'FAT32'  (string)
  volume.ignore = false  (bool)
  volume.is_disc = false  (bool)
  volume.is_mounted = false  (bool)
  volume.is_mounted_read_only = false  (bool)
  volume.is_partition = true  (bool)
  volume.label = 'ROOT'  (string)
(...)

So it's FAT32 on /dev/sda1, labeled ROOT, simple. But:
# fdisk -l
(...)
/dev/sda1               1         499     4008186   82  Linux swap / Solaris
(...)

And:
# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       4008176 0       -1

And:
# grep sda1 /etc/fstab
/dev/sda1               swap                    swap    defaults        0 0

So, HAL "discovered" a FAT32 filesystem on my computer based on the contents of
my swap partition. I really wonder where did FAT32 headers came from, as this
disk never had DOS/Windows on it. I can only imagine that my computer was tested
using Windows in the shop before I bought it, and they only wiped the MBR and
partition table, leaving some bytes behind. It also requires that Linux mkswap
doesn't clear the beginning of the partition (it was FC6's mkswap AFAICT) and
using the swap space for nearly a year doesn't destroy its beginning.

If that's the case, I assume HAL can be easily tricked into discovering other
filesystems in swap, maybe even by allocating huge chunks of memory and writing
FS headers there? :)

I think the discovery of additional file systems should take into account the
specifics of Linux swap space. If my swap partition works for nearly a year and
still contains FAT32 headers, other people's computers can work that way, too.
HAL or its fs-discovering agents (I don't know, how exactly it all works) should
first detect swap, then file systems. Alternatively, it should first check if a
device is used as swap (as it's enabled before HAL starts).

I'd try to run mkswap again on the partition to see if it helps, but I'm going
to leave it for future investigation, if there's a need.
Comment 1 David Zeuthen 2007-11-03 13:21:58 EDT
Sorry to say, but this is caused by yourself using outdated and buggy software
that doesn't clear the signatures correctly. FYI this has been fixed with almost
all mkfs/mkswap in recent versions (FC3 and up I think). So closing this as NOTABUG.

(Probing for file system types is, by it's very nature, a guessing game.. Either
way, HAL uses libvolume_id from udev to do this so it's the wrong component
either way.)
Comment 2 Leszek Matok 2007-11-03 14:10:40 EDT
You're wrong, it's not fixed - to the contrary, from the man page of mkswap:
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.

It means version 1 (new) doesn't erase file system data from a partition, on
purpose! Even if you call it a bug in mkswap, nobody's going to "fix" it.

All of this means that libvolume_id should change the algorithm to find swap
(especially active one from /proc/swaps) first and I'd be grateful if someone
could reopen this bug or at least point me to appropriate upstream bug tracker.
Comment 3 Leszek Matok 2007-11-03 14:49:09 EDT
FYI, I did:

# mkfs.vfat -n itsabug /dev/sda1
mkfs.vfat 2.11 (12 Mar 2005)
# mkswap /dev/sda1
Setting up swapspace version 1, size = 4104376 kB

Now, after a reboot, I see a new device in my nautilus locations, named
"itsabug". A workaround is to fill the swap device with zeros before running mkswap.
Comment 4 David Zeuthen 2007-11-03 14:51:40 EDT
(In reply to comment #2)
> You're wrong, it's not fixed - to the contrary, from the man page of mkswap:
> 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.
> 
> It means version 1 (new) doesn't erase file system data from a partition, on
> purpose! Even if you call it a bug in mkswap, nobody's going to "fix" it.
> 

Hi sorry if I was wrong. However, I'm pretty sure we've been shipping a patch to
util-linux to fix this stupidity that the (now defunct) util-linux upstream was
insisting on. Ditto for other distros. And I think util-linux-ng does clear the
signatures. It seems now according to comment 3 that it does. Karel?

> All of this means that libvolume_id should change the algorithm to find swap
> (especially active one from /proc/swaps) first and I'd be grateful if someone
> could reopen this bug or at least point me to appropriate upstream bug 
> tracker.

Again, file system probing is really a dangerous business; I'm not sure upstream
will implement what you're asking for (just because of broken tools that don't
clear signatures)... but at least it's worth trying

 https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Thanks.
Comment 5 David Zeuthen 2007-11-03 14:54:48 EDT
(In reply to comment #3)
> Even if you call it a bug in mkswap, nobody's going to "fix" it.

Oh, why not? If mkswap doesn't clear signatures it's a serious bug that needs to
be fixed. So reassigning to util-linux-ng, updating the summary and reopening.

(In reply to comment #4)
> It seems now according to comment 3 that it does. Karel?

Erh, I meant _doesn't_.
Comment 6 Karel Zak 2007-12-12 16:50:35 EST
(In reply to comment #4)

> Again, file system probing is really a dangerous business; 
> I'm not sure upstream will implement what you're asking for
> (just because of broken tools that don't clear signatures)... 
> but at least it's worth trying

 This is old story. It is not so simple. We can't blindly zeroize a block device.

 man mkswap:

   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.

 :-(

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