As $URL says, when blkid goes looking for the volume name of a vfat volume, it can run past the end of the root directory and start reading other data on the disk. It's possible (it happened to me) that this other random data can match what it thinks is a volume label and it'll return binary garbage as the label. Reproducible: Always Steps to Reproduce: 1. blkid <device_with_vfat_filesystem> or, more interestingly: 1. hotplug any device containing a vfat filesystem Actual Results: # blkid /dev/sdb /dev/sdb: LABEL="h pag\<.NM-^^\" UUID="35EE-1E0E" TYPE="vfat" # ls /media/ h pag\<.N
Note that the same change (in libblkid.so) also breaks exporting NFS directories hosted on btrfs. Specifically, rpc.mountd uses libblkid to create a unique fsid, but fails. Log excerpt: rpc.mountd[2516]: authenticated mount request from 172.17.1.1:1017 for /export/packages (/store/packages) rpc.mountd[2516]: qword_eol: fflush failed: errno 9 (Bad file descriptor) rpc.mountd[2516]: Cannot export /export/packages, possibly unsupported filesystem or fsid= required
(In reply to comment #1) > Note that the same change (in libblkid.so) also breaks exporting NFS > directories hosted on btrfs. I'm not the maintainer, nor have I tested btrfs, but I don't see how there's any relationship. The patch in $URL is contained completely within superblocks/vfat.c and seems like it should have no relationship to btrfs. There might be a problem with btrfs and NFS, but I don't think it's this.
please post `emerge --info` with every bug report you file. seems to work on my random vfat partitions. please run: dd if=/dev/sdb of=header.bin ibs=512 count=1 then post the header.bin file as an attachment
(In reply to comment #3) > seems to work on my random vfat partitions. please run: > dd if=/dev/sdb of=header.bin ibs=512 count=1 > then post the header.bin file as an attachment fat32 filesystems can have the volume label as an entry in the root directory[1] (look at the 0x08 attribute). So, the volume label on a fat32 volume can be in either the root directory or the header. The blkid code prefers the root directory and looks there first. But, as $URL specifies, it doesn't respect the end_of_fat marker and will go off the end of the root directory and into random data on the disk looking for the label. If some of that random data happens to have the correct set of bits in the right place, then the code thinks its found the volume label and reports that as fact instead of failing back to the label in the FS header. So, I could give you the header of my filesystem, but you won't find anything wrong with it. You'd need a real filesystem with the properly set random bits in the right place. I updated $URL to point at util-linux's temporary home and the specific commit in question. [1] http://en.wikipedia.org/wiki/Fat32#Directory_table
the point is, post a small test case to reproduce the issue or just e-mail the list yourself: http://vger.kernel.org/vger-lists.html#util-linux the commit in question doesn't really help since it's already in util-linux-2.20, and reverting it doesn't make sense since it fixes another bug.
(In reply to comment #5) > the point is, post a small test case to reproduce the issue > > or just e-mail the list yourself: > http://vger.kernel.org/vger-lists.html#util-linux > > the commit in question doesn't really help since it's already in > util-linux-2.20, and reverting it doesn't make sense since it fixes another > bug. No, the point is that it's already been fixed upstream and I'm confirming that the upstream fix is good (which is why I said <util-linux-2.20 is broken). But, Gentoo's stable version (2.19) is broken. Please stabilize 2.20 in order to fix Gentoo... or backport the fix that's already in the upstream repository to 2.19 and fix it that way.
i missed the "<" in the summary 2.20 is in the tree already
(In reply to comment #7) > > 2.20 is in the tree already Ok, one question then I'll drop it (the bug's closed and I won't start/continue a discussion here): So, when a stable package is broken why is the resolution "it's fixed in the unstable version" sufficient to close the bug? How does gentoo recognize the state "stable is currently broken and needs to be fixed"?
stabilization for specific issues depends the severity of the bug. in this case, the bug is pretty minor and people are unlikely to be severely impacted by waiting for the normal testing period to be followed. so i'm not going to bother accelerating things.
