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

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).

Status changed to 'Confirmed' because the bug affects multiple users.

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.

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.

Console logging this early in the boot should be trivial via /dev/kmsg, if nothing else? Maybe that's mildly abusive of the interface, but any attempt to hint at people why their boot is failing to be useful sure beats just sitting there.