mountall hangs on tmpfs mount to /var/log and /var/tmp

Bug #479429 reported by IgnorantGuru
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: mountall

Mounting tmpfs to /var/log or /var/tmp in fstab causes mountall to hang at boot with the message "waiting for tmpfs"

This bug is present in karmic final but was not present in karmic alpha3 and prior. Mounting tmpfs to /tmp does NOT cause this problem. Please don't mark this bug as a duplicate unless it really is - there seem to be many bugs in mountall recently.

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

or
tmpfs /var/tmp tmpfs defaults,noatime,size=1000M,mode=1777 0 0

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

FYI, /var/log and /var/tmp can be mounted successfully with tmpfs in rc.local at runlevel 0. For a workaround see here: http://ubuntuforums.org/showpost.php?p=8232599&postcount=11

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Thanks for the report!

Could you run "sudo mountall --debug" from a shell and attach the output

Changed in mountall (Ubuntu):
status: New → Incomplete
importance: Undecided → High
Revision history for this message
IgnorantGuru (ignorantguru) wrote :

Sure - the attached output is with the /var/tmp tmpfs line disabled in fstab (which is the only way I can boot). Not sure which way you wanted it. But you will see /var/tmp mounted in there because it is currently mounted from a mount command in rc.local. If you prefer it another way just let me know.

If I add a test /var/txp to tmpfs line into fstab, mountall mounts it normally (post-boot with KDE running - I don't know if it would work at boot):
queue_fsck: /var/txp: no check required
mounting /var/txp
spawn: mount -a -t tmpfs -o defaults,noatime,size=500M,mode=1777 tmpfs /var/txp
spawn: mount /var/txp [22539]
mount /var/txp [22539] exited normally
mounted: /var/txp
mounted: local 1/1 remote 0/0 virtual 13/13 swap 0/1
...
update_mount: /var/txp: tmpfs tmpfs defaults,noatime,size=500M,mode=1777

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 479429] Re: mountall hangs on tmpfs mount to /var/log and /var/tmp

On Tue, 2009-11-10 at 15:06 +0000, IgnorantGuru wrote:

> Sure - the attached output is with the /var/tmp tmpfs line disabled in
> fstab (which is the only way I can boot). Not sure which way you wanted
> it. But you will see /var/tmp mounted in there because it is currently
> mounted from a mount command in rc.local. If you prefer it another way
> just let me know.
>
I need to see it failing in the log ;-)

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
IgnorantGuru (ignorantguru) wrote :

> I need to see it failing in the log ;-)

That makes sense, but I don't know how to do that. I tried disabling kdm start so I booted into a shell. I then enabled the /var/tmp line in fstab and ran mountall. In that case it seemed to mount /var/tmp okay, although it did hang. I had to press Ctrl-C to stop it. But the log showed nothing different, except it said /var/tmp was mounted successfully. A "mount" command confirmed that /var/tmp was mounted on tmpfs. Seemed to get way past that point in the log, which ended with the line
  run_swapon: /dev/disk/by-uuid/900b83f8-4962-4652-a865-3d775b3af2ed: already activated

So I don't know how to make mountall fail in the log, since it only seems to fail during boot (presumably when upstart executes it). I considered changing the mountall command in /etc/init/mountall.conf and adding a --debug and redirecting the output to a file, but where can I write the file? Aren't all filesystems unmounted at that point?

So I need instructions on the getting log you want. Thanks for looking at this.

Revision history for this message
IgnorantGuru (ignorantguru) wrote :

Also, in my above comment where I said
> In that case it seemed to mount /var/tmp okay, although it did hang.

I should add that it did NOT display "waiting for tmpfs" when it hung - it just seemed to stop without reporting any problem, and Ctrl-C got out of it. I have only seen mountall (or something?) report "waiting for tmpfs" during boot.

And I have yet to see anyone report that they have been able to mount tmpfs to /var/log or /var/tmp in fstab in karmic final - on the contrary the bug seems to be universal AFAIK.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Have tested it here locally, and it's working fine. I'm not convinced by your "seems to be universal" argument - the only person who has reported a problem is you so far, and I've not had any duplicates.

Could you attach the /etc/fstab file that you cannot get to work?

Changed in mountall (Ubuntu):
importance: High → Low
summary: - mountall hangs on tmpfs mount to /var/log and /var/tmp
+ mountall hangs on tmpfs mount to /var/log and /var/tmp (cannot
+ reproduce)
Revision history for this message
silroquen (silroquen) wrote : Re: mountall hangs on tmpfs mount to /var/log and /var/tmp (cannot reproduce)

I also have this problem. It fails to mount both my /var/tmp and my (encrypted) swap. If I hit escape for the shell and run "mount /var/tmp" and then exit the shell, it succeeds (including mounting the swap by itself). I also have the same problem on another system which is configured similarly but has a whole lot of other partitions too.

Here is my fstab:

proc /proc proc defaults 0 0
UUID=44cefac6-7f68-4498-b706-b5eb3647ef75 / ext4 relatime,errors=remount-ro 0 1
/dev/mapper/swap none swap sw 0 0
tmp /tmp tmpfs nosuid,nodev 0 0
vartmp /var/tmp tmpfs nosuid,nodev 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

Here is my crypttab:

swap /dev/sda1 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,hash=sha512

I'm attaching the output of mountall --debug from after a successful boot. I don't know if I can run it when /var/tmp isn't mounted yet from the shell or not, but I don't have time at the moment anyway; if you need something like that, or other information, let me know specifically what to do, and I will post it later in the week.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Shawn: a mountall bug (fixed in 2.1) causes your tmpfs to not be mounted until your encrypted swap has been mounted (technically this is fstab correct, but mountall often processes out-of-order). I don't know why your encrypted swap isn't being activated, but for that you should file a bug on cryptsetup

Changed in mountall (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

In fact, seeing that in your log makes me strongly suspect that the original reporter has been bitten by the same bug - and that /var/tmp or /var/log is actually being delayed until another mount has finished which never does.

Can't 100% verify since the original reporter hasn't provided the requested information (or even his /etc/fstab) - but I feel pretty confident that this is fixed in lucid since I can now replicate a similar problem, and can explain why this would only affect tmpfs

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Indeed, I now see from the fstab snipped that he has "tmpfs" in the device field instead of "none" - his would definitely cause the bug that I've fixed

summary: - mountall hangs on tmpfs mount to /var/log and /var/tmp (cannot
- reproduce)
+ mountall hangs on tmpfs mount to /var/log and /var/tmp
Revision history for this message
Leo Milano (lmilano) wrote :

@Scott

Sorry I couldn't post earlier. However, I am bitten by this bug, too. I can mount /tmp as tmpfs, but I can't mount /var/tmp or anything in /var for that matter as tmpfs. This is in a netbook where I don't really use a swap or any encrypted fs. If there is anything you'd like me to test in order to verify the fix, I would be happy to.

BTW: will the mountall fix be backported/included in Karmic?

Many thanks for all the great

Revision history for this message
Holger Krause (holger-krause) wrote :

My system was configured to use tmpfs for /var/log, /var/log/apt and /var/tmp before upgrading to karmic. On the first boot after the upgrade the message "waiting for tmpfs" was reported for /var/log/apt. Disabling the entries for /var/log/apt and /var/tmp allowed for an uninterrupted boot. Still /var/log was mounted as tmpfs! Today I changed /etc/fstab to also mount /var/tmp as tmpfs, which also works.

This is the current /etc/fstab I use:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=f1698a06-f89d-4438-a887-a4205ae1f8bf / ext2 noatime,errors=remount-ro 0 1
# /dev/sda5
UUID=efc9ca27-b198-4827-a223-68248ad3d7bb none swap sw 0 0
#tmpfs /var/log/apt tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

mountall-Version is 1.0

The only difference I see to the original bug description are the missing options. In a second try, I inactivated the /var/tmp mount and added options to the /var/log mount:

tmpfs /var/log tmpfs defaults,noatime,size=50%,mode=1777 0 0

Still the system boots uninterrupted and /var/log is mounted as tmpfs (as shown by mount).

Conclusion: I can't reproduce the bug given the original description.

Thanks.

Revision history for this message
John A. Lewis (pointful) wrote :

I experienced the same problem and figured out part of the cause. I have an external disk for my laptop that I put into fstab so it will mount automatically for backups and so forth. But it's not always connected. With the fstab entry for my external drive listed before all my tmpfs entry, the whole system hangs at boot during mountall. When I reordered things so that my tmpfs entries come before the external drive, the problem went away.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.