Boot hangs with "Waiting for /some/mount [SM]" forever.

[H3g3m0n]

Binary package hint: sysvinit

After updating (which I notice pulled in the latest initscripts package). My system failed to boot with "Waiting for /some/mount [SM]". In my case it was an old partition that no longer existed, I was able to log into recovery mode and remove the offending fstab entry. Previously it was just silently failing and continuing to boot.

Another user is reporting the same issue except with an LVM home partition that does automatically mount find in recovery mode. http://ubuntuforums.org/showthread.php?p=9009005

A possible temporary work around might be to remove the fstab entry and mount manually in /etc/rc.local

Description: Ubuntu lucid (development branch)
Release: 10.04

ProblemType: Bug
Architecture: amd64
Date: Tue Mar 23 02:05:53 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100318)
NonfreeKernelModules: nvidia
Package: initscripts 2.87dsf-4ubuntu16
ProcEnviron:
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 SHELL=/usr/bin/zsh
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: sysvinit
Uname: Linux 2.6.32-16-generic x86_64

[Scott James Remnant (Canonical) (canonical-scott)]

This is the expected behaviour.

If you have an invalid or old entry in your /etc/fstab file, the system will not boot because it's waiting for that file - or for you to tell it what to do.

At this prompt, you could have pressed "S" to skip that entry and continue booting or "M" to drop to a shell to fix the problem yourself.

(There is a bug open to replace [SM] with explanatory text)

[Mark M. (earlmagnus)]

You missed the second part of the original report, which also affects me. That is, perfectly valid entires in fstab are hanging up with this problem and mount without issue in recovery mode. In my case, I have a second disk (EXT4 on LVM on LUKS) which mounts to /backup. The LUKS crypt is unlocked with a key in /root. This exact setup worked without issue on Karmic but fails with "waiting for" about 50% of the time.

While the first example may be expected behavior, the second is not. Please reopen this bug.

[Yann Rouillard (yann-pleiades)]

I confirm this bug, I am aso affected.
I have two partitions, including /home, which are ext4 on lvm and I randomly get the "Waiting for /home [SM]" at boot.

[Chris Elsworth (chris-shagged)]

I also confirm this bug.

Perhaps of interest; when shown this message for my troublesome filesystem, I pressed S to get on with the boot. I then mounted it from an ssh root shell which worked absolutely fine [using just mount /dump so fstab was used to look up the details], however this was displayed on the console immediately after the mount:

mountall: ./ply-boot-client.c:178: ply_boot_client_connect: Assertion '!client->is_connected' failed.
General error mounting filesystems.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and reboot the system.

[And a root shell was started on the console, apparently, although getty just took over again when I tried to do anything with it, oddness]

[Mark M. (earlmagnus)]

I have remarked this as new to give Mr. Remnant or others an opportunity to reexamine this considering the new evidence.

[Scott James Remnant (Canonical) (canonical-scott)]

There were a bunch of confirmed bugs that should all be fixed with Plymouth 0.8.1-3

(and hi, CaE!)

[Scott James Remnant (Canonical) (canonical-scott)]

err, I actually mean fixed with mountall 2.10 - it's been a long week