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

[Steve Langasek]

Looking over this bug, I don't think there's anything we can do here to
improve mountall's handling without compromising the guarantee of a
consistent, race-free boot.  We simply have no way of knowing that this
particular tmpfs mount is not "required" for boot unless the admin marks
it so in the /etc/fstab (with the 'nobootwait' option).  And we can't
reliably interact with the user on console until after the "virtual-
filesystems" event is sent, because this is a prerequisite for udev, and
udev needs to poke the hardware to make sure we wind up with the right
console drivers.  So the system is at an impasse.

I certainly agree that we don't want to leave the machine deadlocked
with no output on the screen; but architecturally, I just don't see a
way to address this corner case without introducing substantial bugs in
more common scenarios.

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

-- 
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:
  Won't Fix

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