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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1096079
Title:
boot fails when a mount is a dangling symlink
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1096079/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
