[Bug 1096079] Re: boot fails when a tmpfs can't be mounted due to a dangling symlink

[Steve Langasek]

I'm still going back and forth on this.  There's also bug #1152274,
which I'm marking as a duplicate.  We really should do something better
here, I'm just not sure what.

FWIW, printing messages to the console just got harder, because mountall
has just been changed to log to /var/log/upstart instead of being bound
to the console at all.  Maybe we need to revisit that decision.

** Summary changed:

- boot fails when a mount is a dangling symlink
+ boot fails when a tmpfs can't be mounted due to a dangling symlink

** Changed in: mountall (Ubuntu)
       Status: Won't Fix => Triaged

** Summary changed:

- boot fails when a tmpfs can't be mounted due to a dangling symlink
+ boot fails when a kernel filesystem can't be mounted (e.g., due to a dangling symlink)

-- 
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 kernel filesystem can't be mounted (e.g., due to a
  dangling symlink)

Status in “mountall” package in Ubuntu:
  Triaged

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