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 /
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: mountall (Ubuntu)
Status: New => Confirmed
--
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:
b
** Changed in: mountall (Ubuntu)
Importance: Low => Medium
--
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 abou
** Changed in: mountall (Ubuntu)
Importance: Undecided => Low
--
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 a
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
becaus