I have an USB stick with a single ext2 partition on it. The corresponding fstab entry works with a label since the partition is an USB stick with variable device name due to its hotpluggable nature: > /etc/fstab LABEL=usb_drive /mnt/usb ext2 noauto,noatime,user 0 0 The labeled ext2 partition is correctly recognized by udev: > ls -l /dev/disk/by-label/ lrwxrwxrwx 1 root root 10 2008-06-09 22:51 usb_drive -> ../../sdg1 However, when mounting /mnt/usb, it tries to use a different device: > mount /mnt/usb mount: special device /dev/sdc1 does not exist This is due to a wrong entry in /etc/blkid.tab which does not get updated: > /etc/blkid.tab <device DEVNO="0x0821" TIME="1213033250" LABEL="usb_drive" UUID="1234-5678-90ab-cdef" TYPE="ext2">/dev/sdc1</device> After deleting the file, the mount works fine, but the file is automatically recreated by mount. After umounting, and plugging the stick back in later, with a different device name, mount tries to access the wrong device again. The corresponding entry in /etc/blkid.tab does not get updated properly when this device is plugged in. Everything else works just fine, udev /dev/disk/by-label always points to the correct device. As a workaround, I made /etc/blkid.tab a symlink that points to nowhere (blkid.tab -> blkid.tab recursive symlink). This is the only thing that I found prevents the recreation of /etc/blkid.tab with every mount. Not having a valid /etc/blkid.tab does not seem to hurt any and all mounts work as they are supposed to. It would be nice to see the blkid behaviour fixed properly, so if blkid.tab is useful for anything it should at least have up to date entries at all times and stop messing up my mounts. In case of mounts that are of importance for the system, like external backup storage media, having the mount fail for such a silly reason is a critical error. Reproducible: Always
I have been seeing similar problems intermittently for a while now, in my case with an (external) USB hard drive. I upgraded e2fsprogs to 1.40.10 having read the start of the Release Notes at http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.10 which seemed to refer to the problem: 'When deciding whether or not to revalidate a blkid cache entry, if the device's mtime is newer than the last time the cached entry was validated, force a revalidation.' However, I am still getting mis-matches between variable device names as known to the kernel (/dev/sdeX v./dev/sdaX) and the ability to mount them based on either disk labels or UUIDs, which is obviously the ability that blkid is there to provide. Interestingly, this problem does not affect locating the / partition (real_root=LABEL=ROOT32), which is both good and somewhat curious. The new code seems to be in lib/blkid/probe.c as described in: http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commit;h=492ea6556e82caf88d77c78bde2beb8849aa4eaf I will try the recursive symlink trick ...
In case it helps the thread at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463787 discusses similar issues.
> Interestingly, this problem does not affect locating the / partition > (real_root=LABEL=ROOT32), which is both good and somewhat curious. Of course, it wouldn't because the problem blkid.tab is on the / partition itself, which is not mounted at that point. The recursive symlink trick seems effective, so far.
Same thing here. After adding controller, disk order changed and /etc/blkid.tab did not regenerate? it still contained lots of old garbage. Running blkid -g segfaults: blkid[1746]: segfault at 8 ip 7f74bddd9fd0 sp 7fffc61fccd0 error 6 in libblkid.so.1.0[7f74bddd6000+b000] gdb on blkid -g gave the following: Starting program: /sbin/blkid -g Program received signal SIGSEGV, Segmentation fault. 0x00007fc37bb59fd0 in __list_del (prev=0x241, next=0x0) at ../../lib/blkid/list.h:89 89 ../../lib/blkid/list.h: No such file or directory. in ../../lib/blkid/list.h After manually regenerating cache with "blkid -w" I tried to change the device name in one of the strings ("/dev/sda1 -> /dev/sdx1"), and blkid -g segfailted again. Next I've tried the same on th debian system (the same version). I did not receive any segfaults and cache regenerated correctly.
Same thing here. After adding controller, disk order changed and /etc/blkid.tab did not regenerate? it still contained lots of old garbage. Running blkid -g segfaults: blkid[1746]: segfault at 8 ip 7f74bddd9fd0 sp 7fffc61fccd0 error 6 in libblkid.so.1.0[7f74bddd6000+b000] gdb on blkid -g gave the following: Starting program: /sbin/blkid -g Program received signal SIGSEGV, Segmentation fault. 0x00007fc37bb59fd0 in __list_del (prev=0x241, next=0x0) at ../../lib/blkid/list.h:89 89 ../../lib/blkid/list.h: No such file or directory. in ../../lib/blkid/list.h After manually regenerating cache with "blkid -w" I tried to change the device name in one of the strings ("/dev/sda1 -> /dev/sdx1"), and blkid -g segfailted again. Next I've tried the same on th debian system (the same version 1.0.0. of blkid). I did not receive any segfaults and cache regenerated correctly.
I am also having issues with this. After a kernel update /dev/sda became /dev/sdb. This device is where my boot and / partitions are located. There were no new devices added or removed from the machine and booting with the older kernel the device is still /dev/sda. I thought that using labels in fstab and grub.conf would take care of the problem but the root file system is mounted based on the label but the boot fails shortly there after because the system wants to do a file system check on /dev/sda3 (the / partition) which does not exist since it is now /dev/sdb3. I tried erasing /etc/blkid.tab before rebooting but it still fails so it appears that /etc/blkid.tab is created as part of the shutdown process if it is missing. I then tried the symlink trick and my system now boots with both the new and old kernels. This is a fairly significant problem and it can affect the / partition making a system un-bootable.
If udev rather than mdev (the busybox alternative) were used in the initrd then problems like the present one might disappear. blkid and LABEL= stuff would be redundant in the face of persistent mount-points produced by udev rules relating to particular hardware devices. At present the inability of mdev to deal with the changes in the block layer (unless CONFIG_SYSFS_DEPRECATED_V2=y) is one of the blockers on 2.6.25 becoming stable - at a time when 2.6.26 is reaching the end of its -rc cycle. Which would seem to be another reason for (?re-)enabling udev in genkernel. Not too much of a digression, I hope.
How is initrd related to the problem, if it happens and is reproducible even long after the system has finished booting? (I'm not using genkernel but a custom built vanilla kernel, so no auto-generated initrd for me). I prefer my recursive symlink workaround over creating custom udev rules for my devices. Labels and UUIDs have the advantage that they work everywhere and with any device (or at least they should) without adding any special rules. If my USB stick breaks, I can just give the new one the same label as the old had and be done with it. What irks me most is that the blkid.tab causes trouble while not being useful for anything... or I failed to notice what it is supposed to be useful for, as I haven't got it anymore for a while now and not noticed a single regression.
(In reply to comment #6) > > I then tried the symlink trick and my system now boots with both the new and > old kernels. This is a fairly significant problem and it can affect the / > partition making a system un-bootable. > I'm also having trouble with this. I have two SATA controller cards (two different manufacturers) which come up as different drive names sometimes. When they do that, blkid fails to live up to its manpage promise and validate the cached data. Accordingly, the UUID= stuff in /etc/fstab has become useless because blkid believes its cache. The system fails during boot. Label and UUID were designed to deal with this sort of situation, but blkid has returned us to the old confusion.
Tried with .11?
Yes. Same issue.
This issue seems to have been resolved with 1.41.0 (cf. also the release notes, http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.41.0). I have restored the use of /etc/blkid.tab (i.e. removed the recursive symlink) and have not had any problems with file-system labels since upgrading.
I can confirm that as well. Basic unplugging and replugging (under a different device name) no longer causes issues with blkid. Thus the issue seems to be fixed. Nevertheless I still fail to see the point of this blkid cache - if it ever causes problems again I'll just put the symlink back in.
