Here's the output of blkid -g from gdb  ..

(gdb) run -g
Starting program: /sbin/blkid -g

Program received signal SIGSEGV, Segmentation fault.
blkid_free_dev (dev=<value optimized out>) at ../../lib/blkid/list.h:90
90		prev->next = next;
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
libselinux.x86_64 libsepol.x86_64 lvm2.x86_64
(gdb) bt
#0  blkid_free_dev (dev=<value optimized out>) at ../../lib/blkid/list.h:90
#1  0x00000030c7003ac7 in blkid_gc_cache (cache=<value optimized out>) at
cache.c:170
#2  0x00000000004016ae in main (argc=2, argv=0x7fffeb2e9748) at blkid.c:216

Patch for the segfault bit put into F9 and devel and sent upstream anyway...

At first glance it seems like blkid_find_dev_with_tag() and the things it calls
(which is a path we go down when it's trying to mount-by-label) is doing the
right thing, trying to validate the entry, removing if it doesn't find it,
starting over, etc.  I'll try recreating it and see what's going on.

Ok there's a problem in blkid_verify():

        if (((probe.fd = open(dev->bid_name, O_RDONLY)) < 0) ||
            (fstat(probe.fd, &st) < 0)) {
                if (probe.fd >= 0) close(probe.fd);
                if ((errno != EPERM) && (errno != EACCES) &&
                    (errno != ENOENT)) { 
                        DBG(DEBUG_PROBE, 
                            printf("blkid_verify: error %s (%d) while "
                                   "opening %s\n", strerror(errno), errno, 
                                   dev->bid_name));
                        blkid_free_dev(dev);
                        return NULL;
                }
                /* We don't have read permission, just return cache data. */
                DBG(DEBUG_PROBE,
                    printf("returning unverified data for %s\n",
                           dev->bid_name));
                return dev;

We find the bad device, and stat it - if the device doesn't exist, we get
ENOENT.  But we return the stale data for the nonexistent device anyway.  Eh?

http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commitdiff;h=8bcaaabb1a023af4852dbf0dba76249982c62e40

did this:

When a nonprivileged user uses the blkid command, we want to keep the
cached filesystem information, and opening a device file could result
in an EACCESS or ENOENT (if an intervening directory is mode 700).  We
were previously testing for EPERM, which was really the wrong error
code to be testing against.

but I'm not sure about the ENOENT part ...this seems wrong.  We find a device in
the cache, stat it, get ENOENT and return it anyway?

Ted has some recent commits claiming to fix the rest, see also debian bugs
487758 and 487783.  I'll recreate & give it a whirl.

I've pushed 1.41.0 to f9 testing, it should address this.

1.41.0 is in stable now; this should be resolved (guess I forgot the bug nr. in the push for the bodhi-magic)