update-manager cannot find space on /tmp ramdisk

[Ubfan]

Binary package hint: update-manager

 In 32 Bit Karmic Koala (9.10), running off a 4G usb stick, when
mounting a 256M ramdisk for /tmp from fstab, update-manager claims
not enough space is available on /tmp. The /tmp ramdisk works fine,
able to hold a 70M zip and unpack it, and there is lots of space
left on /. Note that a 64 bit Karmic on a 4G stick with an
identical ramdisk, update-manager works fine. However, even on the
64 bit version, df shows 0 avail for /tmp.

Update-manager can download the package information, but fails to
download any actual packages. The first time update-manager was run,
11 packages of 5.2M found, soon after, 12 packages of 5.3 meg were
found. Not sure if the 5.234k changed when 12 packages found. No
later changes of the 5.234 were seen, regardless of the size of the
download (larger or smaller).

Example:
 Update Manager finds 12 packages needing 5.3m, but selecting the
Install button leads to a popup error window:
Not Enough Free Disk Space
The upgrade needs a total of 5,243k free space on disk '/tmp'. Please free at
least an additional 5,243k of disk space on '/tmp'. Empty your trash and
remove temporary packages of former installations using 'sudo apt-get clean'.

Removal of the /tmp line in /etc/fstab, reboot, and update-manager
works fine. Restore the /tmp line in fstab, (wait a bit) and next
time two packages sized 1.2M are avail, the original error window
complaining of needing 5.234k reappears. Even later, when the
packages to download total 39.9M, the message remains the same --
5,234k needed. This bug may be related to 285096. Firefox has no
trouble downloading files. Cannot find any other program having
problems, even the Synaptic Package Manager works fine.
"df -a" output is all zeros for /tmp, even on the 64 bit system
which seems to have no problems with update-manager.

The below system info is from the time when update-manager
finds 12 packages.

System info:
Presario V3000
 AMD Turion 64, 2G mem, an ext2 filesystem on a 4G usb stick for
root, no swap, no proprietary drivers in use. Karmic 9.10, both
32 and 64 bit versions, patched to date 12/8/2009.

The line in /etc/fstab creating the /tmp ramdisk:
$ fgrep ramfs /etc/fstab
ramfs /tmp ramfs size=256M,mode=1777 0 0

mount shows the /tmp ramdisk.
$ mount
/dev/sdb1 on / type ext2 (rw,noatime,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
ramfs on /tmp type ramfs (rw,size=256M,mode=1777)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/ubfan/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ubfan)

df may indicate a /tmp space issue, but the working 64 bit output is the same.
$ df -a
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 3850176 2897432 757160 80% /
proc 0 0 0 - /proc
none 0 0 0 - /sys
none 0 0 0 - /sys/fs/fuse/connections
none 0 0 0 - /sys/kernel/debug
none 0 0 0 - /sys/kernel/security
udev 998080 260 997820 1% /dev
none 0 0 0 - /dev/pts
none 998080 388 997692 1% /dev/shm
ramfs 0 0 0 - /tmp
none 998080 196 997884 1% /var/run
none 998080 4 998076 1% /var/lock
none 998080 0 998080 0% /lib/init/rw
binfmt_misc 0 0 0 - /proc/sys/fs/binfmt_misc
gvfs-fuse-daemon 0 0 0 - /home/ubfan/.gvfs

$ free
             total used free shared buffers cached
Mem: 1996160 473400 1522760 0 57740 240276
-/+ buffers/cache: 175384 1820776
Swap: 0 0 0

cd /proc/self
$ cat mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev tmpfs rw,relatime,mode=755 0 0
/dev/disk/by-uuid/0c9a28f4-ff16-433f-95c2-dca95354146b / ext2 rw,noatime,errors=remount-ro 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
none /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
ramfs /tmp ramfs rw,relatime,size=256M,mode=1777 0 0
none /var/run tmpfs rw,nosuid,relatime,mode=755 0 0
none /var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0
none /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
gvfs-fuse-daemon /home/ubfan/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

$ cat mountinfo
15 18 0:0 / /sys rw,nosuid,nodev,noexec,relatime - sysfs none rw
16 18 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc none rw
17 18 0:15 / /dev rw,relatime - tmpfs udev rw,mode=755
18 1 8:17 / / rw,noatime - ext2 /dev/disk/by-uuid/0c9a28f4-ff16-433f-95c2-dca95354146b rw,errors=remount-ro
19 15 0:8 / /sys/kernel/security rw,relatime - securityfs none rw
20 15 0:16 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
21 15 0:5 / /sys/kernel/debug rw,relatime - debugfs none rw
22 17 0:11 / /dev/pts rw,nosuid,noexec,relatime - devpts none rw,gid=5,mode=620,ptmxmode=000
23 17 0:17 / /dev/shm rw,nosuid,nodev,relatime - tmpfs none rw
24 18 0:18 / /tmp rw,relatime - ramfs ramfs rw,size=256M,mode=1777
25 18 0:19 / /var/run rw,nosuid,relatime - tmpfs none rw,mode=755
26 18 0:20 / /var/lock rw,nosuid,nodev,noexec,relatime - tmpfs none rw
27 18 0:21 / /lib/init/rw rw,nosuid,relatime - tmpfs none rw,mode=755
28 16 0:22 / /proc/sys/fs/binfmt_misc rw,nosuid,nodev,noexec,relatime - binfmt_misc binfmt_misc rw
30 18 0:23 / /home/ubfan/.gvfs rw,nosuid,nodev,relatime - fuse.gvfs-fuse-daemon gvfs-fuse-daemon rw,user_id=1000,group_id=1000

$ cat mountstats
device rootfs mounted on / with fstype rootfs
device none mounted on /sys with fstype sysfs
device none mounted on /proc with fstype proc
device udev mounted on /dev with fstype tmpfs
device /dev/disk/by-uuid/0c9a28f4-ff16-433f-95c2-dca95354146b mounted on / with fstype ext2
device none mounted on /sys/kernel/security with fstype securityfs
device none mounted on /sys/fs/fuse/connections with fstype fusectl
device none mounted on /sys/kernel/debug with fstype debugfs
device none mounted on /dev/pts with fstype devpts
device none mounted on /dev/shm with fstype tmpfs
device ramfs mounted on /tmp with fstype ramfs
device none mounted on /var/run with fstype tmpfs
device none mounted on /var/lock with fstype tmpfs
device none mounted on /lib/init/rw with fstype tmpfs
device binfmt_misc mounted on /proc/sys/fs/binfmt_misc with fstype binfmt_misc
device gvfs-fuse-daemon mounted on /home/ubfan/.gvfs with fstype fuse.gvfs-fuse-daemon

The ramdisk actually works -- example unpacking a zip file in /tmp.
Initial size of tmp:
$ sudo du -s /tmp
12 /tmp

$ cp pebuilder*zip /tmp
$ cd /tmp
$ ls
keyring-KZtBLC orbit-ubfan pulse-PKdhtXMmr18n ssh-bmHFaV1802
orbit-gdm pebuilder3110a.zip pulse-ySSFfpyl52CL virtual-ubfan.QmMTrW

$ sudo du -s /tmp
3320 /tmp

$ unzip pebuilder3110a.zip
Archive: pebuilder3110a.zip
...
$ sudo du -s /tmp
9192 /tmp

Note that the copy and upziped file were not put on the / filesystem
and still do not appear on /tmp.
$ df -a
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 3850176 2897288 757304 80% /
...
none 998080 388 997692 1% /dev/shm
ramfs 0 0 0 - /tmp
...

ProblemType: Bug
Architecture: i386
Date: Thu Dec 10 09:19:17 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/yelp
Package: yelp 2.28.0-0ubuntu2
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.52-generic
SourcePackage: yelp
Uname: Linux 2.6.31-16-generic i686
XsessionErrors:
 (gnome-settings-daemon:1809): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:1809): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:1841): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:1880): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Ubfan (ubfan1)]

Further testing with a 64 bit Karmic system now shows this problem.
With ramdisks mounted on /tmp and /var/cache/apt/archives (with
a directory "partial" created), the no space message appeared for
a 40M download for both the ...archives directory (possibly valid, but
I thought the default was 64M), and the /tmp directory, with the
same 5.234M additional space needed. Removing the ...archives
ramdisk removed the associated error message, but the /tmp message
presisted, just like on the 32 bit Karmic system. Removing the /tmp
ramdisk allowed the update to proceed normally. All updates
were attempted via the "System/Administration/Update Manager"
menu entry.

[Ubfan (ubfan1)]

The root of this problem is the inability of python's os.statvfs to handle ramfs file systems. A workaround
is to use tmpfs instead, then everything works. ...DistUpgradeCache.py has the checkFreeSpace function which utilizes the os.statvfs. The purpose of using a ram disk here is to minimize writes to flash, which has a limited number of write cycles. From the docs, it looked like ramfs would be better for this than tmpfs (I have no swap either), but since I can successfully run update-manager with the tmpfs, this fix should be low priority.

[Jean-Baptiste Lallement (jibel)]

Thanks for your report. Confirming since you've provided enough information and I'll let the devs handle it from here.

[RedSingularity (redsingularity)]

Cleaning up. Is this still an issue in the most current stable release?
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Ubfan (ubfan1)]

This is still an issue with 10.04 and 11.04. Probably 10.10 too, but I'll have to wait until some more updates are available to test.
Suggested fix:
Use the size= option in the fstab line, which the mount command will report.
Use the amount of free space in ram.
Use the needed download size.
Figure out some amount of ram not to use to keep the system running, and
if the device free space comes back zero (which is what the system function reports for ramfs devices),
calculate using the above to see if there is really enough space.

[RedSingularity (redsingularity)]

Ok, I would like to try and reproduce this. Can you give me some steps to follow after booting the USB drive? Thanks much.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Ubfan (ubfan1)]

Edit your /etc/fstab to add a line putting /tmp into a ramfs device. See the below excerpt of fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0

# update-manager cannot see any space in /tmp when ramfs used
ramfs /tmp ramfs size=256M,mode=1777 0 0
-------snip------

Reboot, and /tmp will be in a mounted ramdisk. The size=256M is unused, but will be reported by mount.
Most things will run fine if you really do have free ram, but update-manager will die with insufficient space errors
for any size (greater than zero) update.

Change the two "ramfs"s in the line to tmpfs, and things work with update-manager.

[Ubfan (ubfan1)]

I just confirmed that this is still a problem in 10.10.

[RedSingularity (redsingularity)]

Sorry for the delay. Confirmed on my system.

Thanks for those reproduction steps you gave. Much appreciated and very helpful!

Marking 'Triaged' for developers to begin work.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Chris Wilson (notgary-deactivatedaccount)]

This doesn't qualify as a papercut as it's not a problem likely to be encountered by an average user in their day-to-day use of Ubuntu.