View Full Version : [ubuntu] mount delays and blkid issue with 9.10

Ian Goodacre
October 29th, 2009, 06:53 PM
I installed 9.04 a few days ago - fresh install. Then I installed openerp-client and openerp-server. These installs completed successfully but the software wouldn't run. But a comment on one of the bug reports said that they recently installed and worked in Karmic, so I upgraded yesterday morning. Something went wrong towards the end of the upgrade (I didn't capture the error messages - I think it was trying to remove one of the packages related to openerp) but the upgrade proceeded.

After the upgrade my system works, but during boot I see the following:

fsck from util-linux-ng 2.16
one or more of the mounts listed in /etc/fstab cannot yet be mounted:
(ESC for recovery shell)
/: waiting for /dev/disk/by-uuid/...
/tmp: waiting for (null)
/boot: waiting for /dev/disk/by-uuid/...
/dev/sda6 clean...

(There were real UUIDs in the above, but I type too slowly to copy them).

Everything mounts successfully and the system runs fine, but I not also that /dev/.blkid.tab doesn't exist so /etc/blkid.tab is a broken link. If I run blkid then /dev/.blkid.tab is created. The UUIDs recorded are the same as those in /etc/fstab (/ and /boot are mounted by UUID).

So - system runs fine, but there is some slight delay accessing / and /boot by UUID during system initialization.

Is blkid relevant any more? I guess not, since my system runs without the cache being created.

Any idea why the file systems "cannot yet be mounted"?

October 30th, 2009, 02:26 PM
Sorry to cross post but it's pretty much as the same thing I noted here:


I'll have a look at the blkid stuff when I've got time over the weekend and see if mines similar to yours (broken link).

October 30th, 2009, 04:07 PM
Found this which might be relevant, I'll try moving those files and see if it stops the errors appearing and post results later:


October 30th, 2009, 09:34 PM
Didn't make any difference at all unfortunately so I changed /etc/fstab so it used devices rather than UUID's and found that it's the two LVM's the the boot sequence is waiting on.