'cannot yet be mounted', 'waiting for /dev/sda1'

This is the relevant fstab entry:

/dev/sda1 /media/sda1 ext3 defaults 0 0

This bug was fixed in the package mountall - 1.0

---------------
mountall (1.0) karmic; urgency=low

  [ Kees Cook ]
  * Call out to restorecon after mounting tmpfs filesystems. LP: #456942.

  [ Johan Kiviniemi ]
  * Fix a bug introduced by the 0.2.6 change. In certain situations, we’d
    quit even though we’re still waiting for some filesystems to be
    mounted. LP: #456806.

  [ Scott James Remnant ]
  * Don't clear the splash screen when we're waiting for filesystems,
    instead just output following whatever else is there. In non-verbose
    mode this won't look any different, but it means we don't clear previous
    verbose mode text. LP: #458389.
  * Only update the "waiting for one or more mounts" text if there's actually
    a change in the set we're waiting for; this removes the need for a CLEAR
    this case anyway.
  * Don't say we're waiting for mounts we're, in fact, not waiting
    for. LP: #459859.
  * Stop mountall (normally) when entering recovery mode. LP: #458060.

  * Clean up source tarball. LP: #460348.

 -- Scott James Remnant <email address hidden> Mon, 26 Oct 2009 09:30:41 +0000

I have just been getting this message appearing on my usplash screen; except it's trying to mount my ext3 /home.

The system starts up normally except for this message, which also offers to open a recovery shell.

As far as I can tell, the message started appearing after applying the "proposed" updates from last night.

How am I supposed to fix this bug by updating Ubuntu, if I cannot even boot into it??

It stops booting after:

/home waiting for UUID=blahblafadfasasffsafsafa

OK, I found the solution:
http://creativeinstantia.blogspot.com/2009/11/upgrade-to-karmic-koala-kubuntu-910.html

"re OK, I found the solution"

I don't think this has anything to do with whether the UUID or /dev/sd?? is used in fstab to identify the drive. Nor in my case does disabling drive checking by zeroing out fstab column 6 (last digit). It stops checking alright, but I still finish up with a read-only drive and need to remount it read/write with "mount -o remount,rw /dev/sda1", then exit to bring up an X session. This needs fixing.

I have exactly the same problem. It happens to me at every boot. I have checked that the ouput of a "blkid" command is the same as the content of my /etc/fstab so it would be nice to know what is causing the bug.

Also, it gives me the opportunity to press ESC to access a recovery shell, which then logs me as the root user without any password prompt!! Security-wise, it could be better...

P-S: I experience the bug, even with mountall 1.0.

me too. Same bug, even with mountall 1.0 and usplash 0.5.49

I'm affected as well : (ubuntu 9.10 amd64 on dell lattitude E6500). At present I can boot with the live CD but I can't boot from the disk itself. It started after I edited fstab to mount nas shares. to the best of my knowledge there are no errors in the fstab file and in any case the modified/added lines were after the mount of "/". Trying to access the disk became very slow with the nautilus wind greying out twice before the file opened. When I rebooted I found the problem above.

How does one update to the new mountall (as I cannot boot from the disk itself) ?

I ran into this on upgrading from Kubuntu 9.04 to 9.10 - booting freezes and gives a screen asking for ESC to drop to a rescue shell - mountall is at V1.0, so unless the above changes aren't in the online updates yet, I'm fairly sure the problem isn't fully fixed yet. The problem appears to be that root is being mounted read only even though "mount" displays it as read/write, and simply entering "mount -o remount /", then "mountall" at the recovery prompt will allow the system to boot. This makes me wonder if the problem is really with mount, rather than mountall. The workaround I came up with is this:

rename /sbin/mountall to /sbin/mountall.bin
create the file /sbin/mountall (make sure it's chmodded to 755):

#!/bin/bash
/bin/mount -o remount /
/sbin/mountall.bin "$@"

My system now boots properly every time. I first tried replacing all the /etc/fstab UUID lines with /dev/sdax lines, but that didn't help the problem - reverting that change and installing the above "-o remount" wedge solved it, so it's definitely not anything to do with the UUIDs (although the "waiting for" messages all have the UUID in them, of course.)

Same bug on Karmic i386 with all updates (mountall 1.0, usplash 0.5.49).

Screenshot

But it's resolved? I was affected now...

Xsdgee

On Jan 15, 2010 11:32 AM, "LuSio" <email address hidden> wrote:

But it's resolved? I was affected now...

-- 'cannot yet be mounted', 'waiting for /dev/sda1'
https://bugs.launchpad.net/bugs/459859 You rec...

Xzmgirfx gxcfrknmndetc, r

On Jan 15, 2010 11:32 AM, "LuSio" <email address hidden> wrote:

But it's resolved? I was affected now...

-- 'cannot yet be mounted', 'waiting for /dev/sda1'
https://bugs.launchpad.net/bugs/459859 You rec...

Same bug here on a fresh Karmic install on a notebook. As far as I can tell, the message started appearing after applying the "proposed" updates.

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
/home/waiting for UUID=e2cca39c-70bb-46be-a5d1-2fdafe1dd2a1
Press ESC to enter a recovery shell

Cannot boot any more. Any solution?
.

Bug still exists for me (same message as #20).

Workaround of #14 did not work for me (if you try it, DO NOT FORGET TO CHANGE RIGHTS TO 755!)

I use encrypted home volumes

How can I undo workaround of #14, I can not reach the recovery console anymore.