Comment 3 for bug 1096079

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.