failed to boot if /var/tmp and /tmp specified in /etc/fstab

[kakaroto]

Binary package hint: mountall

I've upgraded to Karmik and now the system does not boot anymore, I get the following error:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
/tmp: waiting for /dev/shm
/var/tmp: waiting for /dev/shm

If I comment the following lines in my /etc/fstab, the system boots:

/dev/shm /var/tmp none bind 0 0
/dev/shm /tmp none bind 0 0

Please let me know how to fix this, for security reasons I want to use these virtual filesystems.

[IgnorantGuru (ignorantguru)]

I can confirm this on kubuntu karmic final. This bug was NOT present in karmic alpha3, so perhaps the use of upstart is responsible? Mounting tmpfs to /tmp does NOT cause this problem, just /var or a /var subdir.

To reproduce, add this line to fstab:
tmpfs /var tmpfs defaults,noatime,size=1000M,mode=1777 0 0
or
tmpfs /var/log tmpfs defaults,noatime,size=1000M,mode=1777 0 0

In addition, this is an important ability for systems with SSDs (in order to minimize disk writes). mountall --version reports "mountall 1.0". I installed from kubuntu-9.10-alternate-amd64.iso

This may be a duplicate of https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/431040 but that bug was closed as "fix released". This has not been fixed.

[Patrick Horn (phrh)]

I got bitten by this as well after a Kharmic update. The system just booted to a black screen that said, for example:

/tmp: Waiting for tmpfs
/var/tmp: Waiting for tmpfs
/proc/bus/usb: Waiting for usbfs
...

The bit about hitting ESC also got cut off--printed before all the Waiting for blah lines--unless I booted with "nosplash", making this even more confusing (had to hard reset a few times before I figured it out).

I ended up just removing all the lines from my fstab that were not hard-disk related, but I think this is a serious bug to have --where a working and valid fstab causes a hang (with no obvious error message) at boot-time for no apparent reason. This sort of bug is hard to track down, and for the ordinary user, would leave them with no choice other than a complete reinstall, wasting a lot of time, and increasing the likelihood of a user error causing data loss.

I think the error messages could be improved (perhaps emphasizing that 'mountall' is not the same thing as 'mount -a', and maybe also listing the line number in /etc/fstab that is causing the problem). I didn't at first suspect fstab as a source of the boot problems, since I was thinking about my mdraid setup.

[IgnorantGuru (ignorantguru)]

That's odd because on mine /tmp mounts okay with tmpfs - it's just /var and var/subdir that seems to be affected. I don't have an explicit /proc/bus/usb mount, just /proc.

FYI you can mount /var/tmp in /etc/rc.local as an alternative. Details in the SSD CHANGES section here...
http://ubuntuforums.org/showthread.php?t=1310147
http://ubuntuforums.org/showpost.php?p=8232599&postcount=11

Unfortunately that doesn't work for /var/log, which has files opened in it before rc.local runs (even if a startup link for rc.local is added in rc0.d).

I concur that this is a significant bug, especially with the increasing use of SSDs.

[IgnorantGuru (ignorantguru)]

Can you explain why this was marked as a duplicate of https://bugs.launchpad.net/bugs/459642 Is there an implicit 'bind' mount when trying to mount /var/log to tmpfs?

That bug has been marked "won't fix" because "upstart/mountall doesn't handle bind mounts reliably". (I don't really see why 'unreliable' is a valid justification for not fixing it, but perhaps I don't understand the politics involved.) Regardless, do the unreliable bind mounts apply to mounting /var/log to tmpfs?

It sounds to me like upstart/mountall should be able to handle all of this since these mounts can be accomplished later. Some serious functionality has been lost with the change to upstart.

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-11-09 at 16:24 +0000, IgnorantGuru wrote:

> Can you explain why this was marked as a duplicate of
> https://bugs.launchpad.net/bugs/459642 Is there an implicit 'bind'
> mount when trying to mount /var/log to tmpfs?
>
This bug has nothing to do with tmpfs, the original reporter is clearly
bind mounting /dev/shm onto /var/tmp and /tmp - thus is a duplicate of
the existing bind mounts bug.

Scott
--
Scott James Remnant
<email address hidden>

[Patrick Horn (phrh)]

The partition was not set as a "bind" mount in my case. It's likely the two issues are related, but it's not purely an issue with bind mounts in my case.

My /etc/fstab had in it:

none /proc/bus/usb usbfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults,size=1G 0 0

I haven't tried to reproduce the problem since disabling tmpfs, but I can try again in a couple days.