mountall fails with "mountall: fsck /home [369] terminated with status 8"/ Non-existent device - Possible race ?

My guess is that /dev/disk/by-uuid wasn't properly populated at the time that fsck was run.

I've always thought the /dev/disk/by-uuid was a horribly bug, and its use should be stamped out. Fortunately with the blkid library now being incorporated into util-linux-ng, and this is what is being used in all major distributions, it *can* be stamped out. Don't use /dev/disk/by-uuid; it's horribly fragile and not guaranteed to work all the time.

The far better thing to use is to put the following in /etc/fstab instead:

UUID=a14daa42-496b-425a-bc9f-d59cca6a0216

Its use is documented in the fstab man page.

-- Ted

Thanks for the quick reply.

fstab already use the syntax UUID= and this is a fresh installation. The difference with a fresh installation are the disk partitions.
I attach fstab to the report.

Huh. Well, the pathname /dev/disk/by-uuid/.... that e2fsck was complaining about was passed to it by fsck. And fsck is part of the util-linux-ng package, which as far as I knew translated UUID=... into a /dev pathname directly, and which didn't use /dev/disk/by-uuid/... any more.

Hm.... can you show the output of "fsck -ANV" (it doesn't have to run as root; this is a debugging command that doesn't actually do any thing but print what fsck would execute).

output of

$ fsck -ANV
fsck from util-linux-ng 2.17.2
Checking all file systems.
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sda1
[/sbin/fsck.ext4 (1) -- /home] fsck.ext4 /dev/sdb3
[/sbin/fsck.ext4 (1) -- /var] fsck.ext4 /dev/sdb2

This only happens if 'quiet splash' is present on the boot command line.
Definitely not an fsck issue, I'm affecting to mountall.

Also note that the boot doesn't fail if mountall verbose mode is on, or when there is a small delay (sleep .1) before starting mountall in /etc/init/mountall.conf

This looks like a race of some kind.

I experience the same issue, but for me it doesn't happen on every boot, only occasionally.
I'm attaching my /var/log/boot.log which claims there are several problems, both with the swap disk (which seems to work fine) and with a disk that is a RAID array (which is present when I get to a desktop, unlike boot.log claims). But it doesn't seems to be associated with any particular partition. Except for my root and home partition, this seems to happen to a different disk each time it occurs.

Same here on a dmcrypt /home partition. A sleep 0.1 does not do it, nor does a sleep 1. But if I ignore the error (pressing I) then I can continue normally...
I have checked this partition and it is perfectly fine fsck-wise.

This is a real show stopper for anybody who has set up encryption on a partition and does not know how to troubleshoot using the console (hopefully not my case).

Removing quiet splash does not change anything for me.

Status changed to 'Confirmed' because the bug affects multiple users.

Hi Jean-Baptiste,

Is this issue still affecting you?

Every default Ubuntu system uses UUID= syntax in /etc/fstab. So if there is a race with the creation of the /dev/disk/by-uuid/ links, it's strange that only a handful of people should be reporting it.

If you're still seeing this in 12.04, can you attach /var/log/udev log? There may be something we can see there.

Hi Steve,
I can't tell, I changed the partitioning of this system due to this error.
I'm closing this report because I cannot provide any additional useful information.