[Bug 1096079] Re: boot fails when a mount is a dangling symlink

[Steve Langasek]

Hi LaMont,

This problem is entirely specific to the fact that this is a tmpfs mount
being affected.  A tmpfs mount meets mountall's definition of a
"virtual" filesystem, and mountall (wisely) does not encode policy about
which mount points for virtual filesystems are required at boot or not
because this changes over time.  And until the virtual filesystems are
mounted, nothing else on the system can start up - including the
plymouth splash - so there's no sane way for mountall to give you an
option to skip over this mount.

If this had been anything *other* than a virtual filesystem, you would
certainly have been given an option to skip the missing mount.  As it
is, the missing mount point should probably be treated as a hard failure
by mountall and cause the system to drop to a root shell.  It would be
helpful if you could confirm that this problem actually happens with
later versions of mountall.

Other configurations that would have avoided this problem:
 - marking the mount 'nowait', so mountall knows not to block boot events waiting for it
 - mounting as part of the chroot setup rather than in the system /etc/fstab, which I think is more typical (though from context it appears this was a static chroot, so that's probably not an option here).

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mountall in Ubuntu.
https://bugs.launchpad.net/bugs/1096079

Title:
  boot fails when a mount is a dangling symlink

Status in “mountall” package in Ubuntu:
  New

Bug description:
  In 2.15.3 (lucid), and probably later, if I have this in fstab, then the boot locks up:
  none /srv/chroots/raring-amd64/dev/shm tmpfs defaults 0 0

  Looking at the target for the mount:
  lrwxrwxrwx 1 root root 8 2012-11-07 23:05 /srv/chroots/raring-amd64/dev/shm -> /run/shm
  On the lucid machine, /run/shm does not exist, of course.

  Changing that to:
  none /srv/chroots/raring-amd64/run/shm tmpfs defaults 0 0
  works around the issue.

  A dangling symlink in fstab should not cause a completely silent
  failure to boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1096079/+subscriptions