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.
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.)
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.
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.
(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.
(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_.
(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. :-(