'cannot yet be mounted', 'waiting for /dev/sda1'
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | mountall (Ubuntu) |
Low
|
Scott James Remnant (Canonical) | ||
| | Karmic |
Low
|
Scott James Remnant (Canonical) | ||
Bug Description
Binary package hint: mountall
Since a few days, I get in Karmic on the xsplash screen multiple occurences of the messages:
cannot yet be mounted...
/media/sda1 waiting for /dev/sda1
(/dev/sda1 aka /media/sda1 is my Jaunty installation, NOT the partition I'm booting from)
The message is repeated about 20 times, involving a lot of scrolling.
ProblemType: Bug
Architecture: i386
Date: Sat Oct 24 17:59:52 2009
DistroRelease: Ubuntu 9.10
Package: mountall 0.2.5
ProcEnviron:
LANG=C
SHELL=/bin/bash
ProcVersionSign
SourcePackage: mountall
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
(gnome-
(polkit-
(nautilus:1608): Eel-CRITICAL **: eel_preferences
(gnome-
| tags: | added: ubuntu-boot-experience |
| Changed in mountall (Ubuntu): | |
| status: | New → Fix Committed |
| importance: | Undecided → Low |
| assignee: | nobody → Scott James Remnant (scott) |
| milestone: | none → ubuntu-9.10 |
| Launchpad Janitor (janitor) wrote : | #3 |
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
| Changed in mountall (Ubuntu Karmic): | |
| status: | Fix Committed → Fix Released |
| ChrisLees (christopher-lees) wrote : | #4 |
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.
| ChrisLees (christopher-lees) wrote : | #5 |
| ChrisLees (christopher-lees) wrote : | #6 |
| roffik (roffik) wrote : | #7 |
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=blahblafad
| roffik (roffik) wrote : | #8 |
OK, I found the solution:
http://
| pamindic (pam-indicia) wrote : | #9 |
"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.
| yuval aviel (yuval-aviel) wrote : | #12 |
me too. Same bug, even with mountall 1.0 and usplash 0.5.49
| Changed in mountall (Ubuntu): | |
| status: | Fix Released → Confirmed |
| status: | Confirmed → Fix Released |
| justfred (frederic-durodie) wrote : | #13 |
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) ?
| Phil Salkie (phil-asylumhouse) wrote : | #14 |
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.)
| Roman Khatko (nosorog) wrote : | #15 |
Same bug on Karmic i386 with all updates (mountall 1.0, usplash 0.5.49).
| Roman Khatko (nosorog) wrote : | #16 |
Screenshot
| LuSio (lusio88) wrote : | #17 |
But it's resolved? I was affected now...
| hanzomon4 (hanzomon4) wrote : Re: [Bug 459859] Re: 'cannot yet be mounted', 'waiting for /dev/sda1' | #18 |
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:/
| hanzomon4 (hanzomon4) wrote : | #19 |
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:/
| nomnex (nomnex) wrote : | #20 |
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-
Press ESC to enter a recovery shell
Cannot boot any more. Any solution?
.
| Sebastian Werk (sepp) wrote : | #21 |
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
| Sebastian Werk (sepp) wrote : | #22 |
How can I undo workaround of #14, I can not reach the recovery console anymore.


This is the relevant fstab entry:
/dev/sda1 /media/sda1 ext3 defaults 0 0