checkfs fails at startup while trying to check /dev/.tmp-XXX

Same here (and on my gf laptop), it looks like some kind of race condition (maybe udev related ?)

I checked e2fsprogs, and from the source code, it doesn't look like they are doing something to prevent the race.
(And I don't see how it could prevent it, maybe use /dev/disk/by-uuid/ and rely on devfs/udev ?)

I don't have skills/time to have a look into e2fsprog, but I know that this computer worked perfectly for nearly one year, and then, it has started to fail at boot with this error... So I guess there is a way to avoid this race... Maybe I'll try to track changes in e2fsprog package and downgrade it. The last solution is simply to hack /etc/init.d/checkfs in order to skip this (and f-e only check known disks).

Wow, that's hackish :) maybe you could first try to add a "sleep 5" or something in /etc/init.d/checkfs.sh to avoid the race.

In my opinion it can come from either udev, the kernel, or upstart. The clean solution would be to make sure that udev settles down before starting checkfs.

I'm facing exactly the same problem.

Same problem here. This appears to have happened recently, however I don't reboot too often. Here is the log from /var/log/fsck/checkfs

Log of fsck -C -R -A -a
Sun Sep 16 09:36:44 2007

fsck 1.40-WIP (14-Nov-2006)
fsck.ext3: No such file or directory while trying to open /dev/.tmp-254-0
/dev/.tmp-254-0:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

fsck died with exit status 8

Sun Sep 16 09:36:45 2007
----------------

I cannont reproduce this bug. Can you tell us if you have still this behaviour. Thank you!

[Expired for sysvinit (Ubuntu) because there has been no activity for 60 days.]