maemo.org Bugzilla – Bug 5450
Installing many packages at a time via App Manager exhausts rootfs space
Last modified: 2010-04-12 11:23:39 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 1.2009.41-10 STEPS TO REPRODUCE THE PROBLEM: 1. Make sure / file system has about 60MB free. 2. Start Application Manager 3. Install 10-15 packages in a row, with the total size of <60MB. OR 3. Restore 10-15 previously installed packages, with the total size of <60MB. EXPECTED OUTCOME: The packages install successfully, the available / space is reduced by the total size of installed packages. ACTUAL OUTCOME: The / filesystem runs out of space in the middle of installation process, some packages fail to install. The only known way to return / to its normal state is to reboot the device. After reboot, the / filesystem gets its free space back again. REPRODUCIBILITY: sometimes
I ran into a similar issue at Mameo Summit after installing lots of apps. Every two minutes I got an annoying ""Device storage memory full. Remove data to free memory"" (or something similar) popup. "df -h" stated that I have 0% space left on rootfs.
Also see bug 5613.
*** Bug 5613 has been marked as a duplicate of this bug. ***
1. Started with several MB free on / (didn't grab the exact figure), then installed a few small packages: Filesystem 1k-blocks Used Available Use% Mounted on rootfs 233224 229892 0 100% / 2. After reboot: rootfs 233224 202200 26744 88% / 3. After installing tuner (nominally a 24K package!): rootfs 233224 205816 23128 90% / One thing that tuner's (and most packages') post-install script does is update the gtk icon cache. This is stored on the rootfs and is currently 20MB (although highly compressible) here. 4. So, let's just update the cache manually and see what happens: Nokia-N900-41-10:~# gtk-update-icon-cache -f /usr/share/icons/hicolor/ gtk-update-icon-cache: Cache file created successfully. Nokia-N900-41-10:~# df / Filesystem 1k-blocks Used Available Use% Mounted on rootfs 233224 224400 4540 98% / Ok, that's bad but let's sync the fs to reclaim some: Nokia-N900-41-10:~# sync Nokia-N900-41-10:~# df / Filesystem 1k-blocks Used Available Use% Mounted on rootfs 233224 209352 19588 91% / Better, but that's 3.5MB gone since step 3. Maybe something is keeping the old version open, let's find out: Nokia-N900-41-10:~# ls -i /usr/share/icons/hicolor/icon-theme.cache 80519 /usr/share/icons/hicolor/icon-theme.cache Nokia-N900-41-10:~# gtk-update-icon-cache -f /usr/share/icons/hicolor/ gtk-update-icon-cache: Cache file created successfully. Nokia-N900-41-10:~# sync Nokia-N900-41-10:~# df / Filesystem 1k-blocks Used Available Use% Mounted on rootfs 233224 212912 16028 93% / Nokia-N900-41-10:~# lsof | grep 80519 Nokia-N900-41-10:~# lsof | grep deleted hildon-de 1770 user 20w REG 0,12 0 17665 /tmp/mb_wm_theme_loading (deleted) Nope, but another 3.5MB has leaked just like that. Perhaps I'm overlooking something, but it looks like a UBIFS problem to me. Maybe it's a leak or maybe it's just too pessimistic in its free space reporting, but is there any way to trigger its garbage collection without a reboot? I tried remounting / read-only but it fails: Nokia-N900-41-10:~# mount -n -o ro,remount / mount: mounting ubi0:rootfs on / failed: Device or resource busy Another reboot recovers the "lost" space of course: Nokia-N900-41-10:~# df / Filesystem 1k-blocks Used Available Use% Mounted on rootfs 233224 202292 26648 88% /
Great & helpful analysis, Lucas! Thanks.
(In reply to comment #4) > Perhaps I'm overlooking something, but it looks like a UBIFS problem to me. > Maybe it's a leak or maybe it's just too pessimistic in its free space > reporting, but is there any way to trigger its garbage collection without a > reboot? Sync initiates GC. However, what gets you the disk space back is applications not anymore keeping the old versions of the updated files open after reboot so that the file system can actually GC them.
(In reply to comment #6) > However, what gets you the disk space back is applications not anymore keeping > the old versions of the updated files open after reboot so that the file system > can actually GC them. I did check with lsof (and even tried a "killall hildon-desktop" which I probably should have mentioned). Is there anything else I can test?
(In reply to comment #7) > I did check with lsof (and even tried a "killall hildon-desktop" which I > probably should have mentioned). Is there anything else I can test? If you check which processes have this file open: lsof | grep /usr/share/icons/hicolor/icon-theme.cache before and after the package installation, you see that the inode has changed for the cache file these processes keep open. However, if you "strace -f -p PID" these same processes when you do the new application install, you'll see that they didn't close and re-open this file. Therefore kernel needs to keep the old file contents for them.
(In reply to comment #8) > If you check which processes have this file open: > lsof | grep /usr/share/icons/hicolor/icon-theme.cache > > before and after the package installation, you see that the inode has changed > for the cache file these processes keep open. Right, so lsof lies :-( Oh well, should probably file a bug about that somewhere... However "grep /usr/share/icons/hicolor/icon-theme.cache /proc/[1-9]*/maps" does show the correct (old) inode. So it's not UBIFS (sorry!) which is /very/ good news. So the scenario AIUI is: 1. Device boots, processes start and mmap the existing icon cache. 2. User installs app. 2. Package post-install script updates icon cache. 3. Pre-existing processes still hold the old version(s) open, while any apps started after this point use the new one. 3.5MB down the drain. 4. User installs another app. 5. Goto 2. I guess it's unrealistic to expect all offending packages to be fixed soon, but perhaps moving the icon cache off the root filesystem is an option? @Andre: is there anything relevant in bugzilla.gnome.org that might be useful here?
(In reply to comment #9) > I guess it's unrealistic to expect all offending packages to be fixed soon, but > perhaps moving the icon cache off the root filesystem is an option? While on this topic, I would also like to mention locale cache (about 16MB of data in a single file) that may also be worth moving off rootfs.
Some updates: - Newer lsof versions (tested 4.78) display the inodes of deleted mmaped files correctly, eg: worldcloc 1723 user mem REG 254,1 81009 /usr/share/icons/hicolor/icon-theme.cache (path inode=84452) worldcloc 1723 user mem REG 254,1 20833088 84452 /usr/share/icons/hicolor/icon-theme.cache - After installing 5 updates in one go with application manager, there are now 6 different versions of the icon cache in use and available space dropped from 25936 to 6684 blocks. - More importantly, running 'lsof|grep "path inode="' and 'lsof|grep "DEL"|egrep -v "/dev/zero|SYSV00"' shows no other deleted files still in use. - The gtk icon cache issue is also reproducible in scratchbox, so it looks like the problem is 100% userland. - In GNOME 2.26 (Ubuntu 9.04 to be precise) rebuilding the icon cache and using it (eg by opening a new gtk application) causes all running processes to release the old version and open the new one. It seems solvable, but at this point it's very unfamiliar territory to me. Are there any GTK+ hackers around that can shed some light?
(In reply to comment #11) > - More importantly, running 'lsof|grep "path inode="' and 'lsof|grep > "DEL"|egrep -v "/dev/zero|SYSV00"' shows no other deleted files still in use. I should add: "lsof|grep deleted" shows only /tmp/mb_wm_theme_loading.
(In reply to comment #11) > - Newer lsof versions (tested 4.78) display the inodes of deleted mmaped files > correctly, eg: > > worldcloc 1723 user mem REG 254,1 81009 > /usr/share/icons/hicolor/icon-theme.cache (path inode=84452) > worldcloc 1723 user mem REG 254,1 20833088 84452 > /usr/share/icons/hicolor/icon-theme.cache > > - After installing 5 updates in one go with application manager, there are now > 6 different versions of the icon cache in use and available space dropped from > 25936 to 6684 blocks. The think I don't understand is how there can be so many different versions of the icon cache if one just installs multiple applications in AM without starting other applications. I would understand there being two versions, the original, and the latest one. What process keeps the intermediate versions?
(In reply to comment #10) >> I guess it's unrealistic to expect all offending packages to be fixed soon, >> but perhaps moving the icon cache off the root filesystem is an option? > > While on this topic, I would also like to mention locale cache (about 16MB of > data in a single file) that may also be worth moving off rootfs. locale-archive could be used by things that are run before /home is mounted. If I read the startup scripts correctly, currently it seems to be mounted in: ---- /etc/event.d/rcS-late --- ... start on started xomap ... script ... /bin/mount /home || echo "Failed to mount /home partition." ------------------------------ Btw. This shows what sized files are opened, sorted by file size: lsof | egrep -v '(DEL|/dev/|unix|sock|pipe)' | \ awk '{if($7>0) print $7, $9}' | sort -n | uniq ... 815172 /usr/lib/libdb-4.2.so 825344 /home/user/.cache/tracker/file-meta.db 828660 /usr/lib/libstdc++.so.6.0.9 846784 /usr/lib/libtelepathy-glib.so.0.30.0 867344 /usr/lib/libglib-2.0.so.0.2000.3 911512 /usr/lib/microb-engine/libmozjs.so 940144 /usr/lib/microb-engine/libnss3.so 944144 /usr/lib/libX11.so.6.2.0 984884 /usr/bin/modest.launch 1011520 /usr/lib/libcalendar_backend.so.0.0.0 1145180 /usr/lib/libsync4j.so.3.0.0 1160576 /lib/libc-2.5.so 1172896 /usr/lib/libxml2.so.2.6.32 1229276 /usr/lib/libcrypto.so.0.9.8 1334008 /usr/lib/libglslcompiler.so 1525356 /usr/bin/Xorg 1779664 /usr/bin/intellisyncd 1780247 /var/log/syslog 3607964 /usr/lib/libgtk-x11-2.0.so.0.1400.7 6850580 /usr/lib/browser/plugins/libflashplayer.so 13315848 /usr/lib/microb-engine/libxul.so 16510624 /usr/lib/locale/locale-archive 20306412 /usr/share/icons/hicolor/icon-theme.cache (As only one copy of the previous file needs to be retained by kernel / file system, it doesn't matter how many processes are keeping the old version open, as long there's at least one process which isn't restarted on these new package installs.) Because rootfs content is LZO compressed, what matters for the rootfs usage is the file size as compressed. For above files this: for file in $(lsof | egrep -v '(DEL|/dev/|unix|sock|pipe|/$)' | awk \ '{if($7>0) print $7, $9}' | sort -n | uniq | tail -20 | awk '{print $2}'); do lzop -c $file > ${file##*/}.lzo done du -ks *.lzo | sort -n gives: ... 512 libglib-2.0.so.0.2000.3.lzo 512 libnss3.so.lzo 576 libcalendar_backend.so.0.0.0.lzo 576 libmozjs.so.lzo 576 modest.launch.lzo 640 libX11.so.6.2.0.lzo 640 libsync4j.so.3.0.0.lzo 704 libc-2.5.so.lzo 704 libxml2.so.2.6.32.lzo 768 libcrypto.so.0.9.8.lzo 832 libglslcompiler.so.lzo 960 intellisyncd.lzo 1024 Xorg.lzo 2048 libgtk-x11-2.0.so.0.1400.7.lzo 2624 icon-theme.cache.lzo 3648 libflashplayer.so.lzo 6272 locale-archive.lzo 7360 libxul.so.lzo From here one can see that in addition to locale-archive e.g. Browser related libraries (especially Flashplayer and XUL library) are huge. For RAM usage the uncompressed size is more important, but one needs to use sp-smaps-* tools to see how much of that data applications actually need in RAM. AFAIK SSU closes down all applications before proceeding, including pre-started ones like Browser, but I'm not sure whether it closes down all Browser daemon(s). If not, currently user may need to uninstall stuff enough that she gets >10MB more (compressed) space on the root file system free before proceeding. Locale-archive is used also by other things than apps and Gtk is used by application manager itself so we cannot really avoid that by closing down processes. As SSU reboots the device at the end and we test how much free space there needs to be for SSU update (+ add some safe margin), it should not fail. It's just currently done non-optimally. I.e. only application installations after SSU should be an issue...
(In reply to comment #14) > locale-archive could be used by things that are run before /home is mounted. Because of the very special situation that Maemo 5 is in, I think we can make the argument that /home should be mounted as early as needed: together with /usr, say, and both could be mounted as soon as the needed kernel modules can be loaded.
(In reply to comment #13) > What process keeps the intermediate versions? Would seem to be hildon-home (easy to see just by monitoring its VmSize, it increases ~20MB on each app install). Next question is, is it home itself or one of the applets... (In reply to comment #15) > Because of the very special situation that Maemo 5 is in, I think we can make > the argument that /home should be mounted as early as needed: together with > /usr, say, and both could be mounted as soon as the needed kernel modules can > be loaded. Because Browser stuff is larger than locale archive, first I would be more interested to know whether AM terminates Browser daemon (master, rtcom, browser UI) instances before doing SSU?
(In reply to comment #16) > Because Browser stuff is larger than locale archive, first I would be more > interested to know whether AM terminates Browser daemon (master, rtcom, browser > UI) instances before doing SSU? Not as far as I know. It closes all applications, but does nothing special for daemons.
(In reply to comment #16) > (In reply to comment #13) > > What process keeps the intermediate versions? > > Would seem to be hildon-home (easy to see just by monitoring its VmSize, it > increases ~20MB on each app install). Next question is, is it home itself or > one of the applets... The application menu (the one that opens when you click in the upper left corner) reloads the list after an app installation, and as it displays icons of applications, it most likely uses the icon cache for that. Maybe that's something that is fixable in the code of that application?
(In reply to comment #18) > (In reply to comment #16) > > (In reply to comment #13) > > > What process keeps the intermediate versions? > > > > Would seem to be hildon-home (easy to see just by monitoring its VmSize, it > > increases ~20MB on each app install). Next question is, is it home itself or > > one of the applets... > > The application menu (the one that opens when you click in the upper left > corner) reloads the list after an app installation, and as it displays icons of > applications, it most likely uses the icon cache for that. Maybe that's > something that is fixable in the code of that application? Oh, sorry, the application menu seems to be provided by hildon-desktop, not hildon-home. (if you type "killall hildon-desktop" into the xterm and then quickly open the application menu, you can see how the icons get loaded there) Hildon-home might still use the icon cache, as all the launcher icons have to display application icons which - again - probably is done using the icon cache file.
Created an attachment (id=1528) [details] Script to count how many times processes mmap given file (In reply to comment #19) > Hildon-home might still use the icon cache, as all the launcher icons have > to display application icons which - again - probably is done using the icon > cache file. Good point, I forgot about that. So the installed application icons can actually be used by two processes (and their memory shared by the icon cache). Attached is a script counting how many times and which processes map the given file (One could get almost same info from lsof, but it doesn't seem to give full process names and it misses process mmapping the same file twice). After bootup once all the pre-started apps have started and opening Application manager, the result is on my device: 1 browser [1858] 1 browserd [1852] 1 hildon-application-manager [2205] 1 hildon-desktop [1083] 1 hildon-home [1082] 1 hildon-status-menu [1076] 1 image-viewer [1884] 1 modest [1895] 1 osso-addressbook [1841] 1 rtcom-call-ui [1845] 1 rtcom-messaging-ui [1850] To see which applications can cause this issue on install and which also on uninstall, use: grep gtk-update-icon-cache /var/lib/dpkg/info/*.post* After uninstalling one such app: 1 browserd [1852] 1 camera-ui [1112] 1 hildon-desktop [1083] 1 osso-addressbook [1841] 1 systemui [974] 2 browser [1858] 2 hildon-application-manager [2205] 2 hildon-home [1082] 2 hildon-status-menu [1076] 2 image-viewer [1884] 2 modest [1895] 2 rtcom-call-ui [1845] 2 rtcom-messaging-ui [1850] And then after installing few apps: 1 browserd [1852] 1 camera-ui [1112] 1 hildon-desktop [1083] 1 osso-addressbook [1841] 1 systemui [974] 2 browser [1858] 2 hildon-status-menu [1076] 2 image-viewer [1884] 2 modest [1895] 2 rtcom-call-ui [1845] 2 rtcom-messaging-ui [1850] 2 worldclock [2520] 3 hildon-application-manager [2205] 5 hildon-home [1082] At this point hildon-home or one of its applets had managed to map one icon-theme.cache instance twice, but as you see, AM isn't completely innocent either. Btw. After installing all these apps/applets, I noticed that some of the Home applets I had installed from extras cause Home window to be updated at 10Hz(!) even when Home is on background. (I wondered why Home was using CPU while AM was on top and "xresponse -a '*' -w 0" told the rest. If somebody's using these applets from extras, please check which one of them are this broken and file bugs against them.)
So, way worse for me here. Wondering if this is the same issue?: SOFTWARE VERSION: 45-14 ADDITIONAL SOFTWARE ALREADY INSTALLED: openttd, rootsh STEPS TO REPRODUCE: 1. Become root in Terminal ("sudo gainroot") 2. Run "df -h" and get: Filesystem Size Used Available Use% rootfs 227.9M 151.3MB 72.4M 68% 3. run the command "apt-get install ukeyboard xournal maelstrom maemo-recorder hildon-systray tomotko touchsearch kmplayer personal-photo-frame openntpd madbomber stockthis wormux" 4. Get the message: "Need to get 69,4 MB of archives. After this operation, 117MB of additional disk space will be used. Do you want to continue [Y/n]?" 5. Do not realize that 117MB > 72.4MB and press "y" and "Enter" key. 6. Wait while device installs stuff. 7. After some time, get "dpkg: Unrecoverable fatal error, aborting: [...] No space left on device E: Sub-process /usr/bin/dkpg returned an error code (2)" 8. Oops. Try "apt-get remove" for one of the packages. 9. Get an error: "E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem" 10. Hence run "dpkg --configure -a" 11. Get an error: "dpkg: Unable to open/create status database lockfile: No space left on device" 12. Start Application Manager. 13. Get "Operation failed" popup. 14. Click "Uninstall". 15. Get "(no applications installed)". 16. Run "df -h" and get: Filesystem Size Used Available Use% rootfs 227.9M 227.9MB 0 100% EXPECTED OUTCOME: * In step 5 there should be a warning, or even better: The process should be stopped. * User should somehow be able to remove installed software to get free space again. ACTUAL OUTCOME: User in a situation where he can only reflash the device if he does not get a good idea, like "rm -rf /usr/share/themes/". Rebooting does NOT help. REPRODUCBILITY: 2 out of 2
>3. run the command > "apt-get install ukeyboard xournal maelstrom maemo-recorder hildon-systray > tomotko touchsearch kmplayer personal-photo-frame openntpd madbomber > stockthis wormux" That command alone will fill your rootfs because all deb are first downloaded to /var/cache/apt/archives/, which is in rootfs unless something has changed Try with application manager
Andre these are different issues. If you re-install the same package several time, it'll exhaust rootfs due to a bug in the icon cache handling. This should not happen. Your case is different as you tried to install more data than it is physically available. Aniello
(In reply to comment #21) ... > 6. Wait while device installs stuff. > 7. After some time, get > "dpkg: Unrecoverable fatal error, aborting: > [...] No space left on device > E: Sub-process /usr/bin/dkpg returned an error code (2)" ... > 8. Oops. Try "apt-get remove" for one of the packages. > 9. Get an error: > "E: dpkg was interrupted, you must manually run 'dpkg --configure -a' > to correct the problem" > 10. Hence run "dpkg --configure -a" > 11. Get an error: > "dpkg: Unable to open/create status database lockfile: > No space left on device" What was the package that failed at step 7? dpkg should remove the failing package also in case when it fails due to running out of space, but some packages can be buggy and write to disk stuff that dpkg doesn't know about (and therefore cannot remove). (In reply to comment #23) > Your case is different as you tried to install more data than it is physically > available. Apt-get not warning about this seems stupid, but that's Debian issue, not Maemo end user one. The interesting question is does Application manager prevent / warn about this case?
This has been fixed in two packages and should be included in the internal week43 build version. (Note that 2009 is the year and the number after is the week.) Any public update released with or after this build version will include the fix. Please verify that the new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time.
*** Bug 7000 has been marked as a duplicate of this bug. ***
I simply linked archives directory, now it works in MyDocs to keep rootfs alive. Is it possible to move this directory to a larger storage in the future? /var/cache/apt/archives/ (In reply to comment #22) > >3. run the command > > "apt-get install ukeyboard xournal maelstrom maemo-recorder hildon-systray > > tomotko touchsearch kmplayer personal-photo-frame openntpd madbomber > > stockthis wormux" > > That command alone will fill your rootfs because all deb are first downloaded > to /var/cache/apt/archives/, which is in rootfs unless something has changed > > Try with application manager >
I'm a bit weary to go into all the details, but before reflashing your device, try this: sudo ./flasher-3.5 --enable-rd-mode And reboot. Some info here: http://www.freemoe.org/users/jebba/MALF/ And in bug #7019
sudo ./flasher-3.5 --enable-rd-mode With this, I was able to recover my device *WITHOUT REFLASHING*. (It also showed that it wasn't a full / filesystem that kept my system from booting.) Sorry for the noise, but I was prodded to add: Note to children playing at home: DO NOT LEAVE YOUR SYSTEM IN R&D MODE. It will cause weird side effects (such as making your keyboard flash), so you should disable it. To disable it run: sudo ./flasher-3.5 --disable-rd-mode If you don't have sudo set up, just run the command as root. Note this is a GNU/Linux command, I'm not sure about other OSes. In sum: I had a bricked system, I put it in R&D mode, I booted up in R&D mode fine, I then put the system in Production mode and booted up fine again without the need for any reflashing or data loss.
This appears to be FIXED in 2.2009.51-1, but leaving open in case others still encounter it.
(In reply to comment #30) > ...but leaving open in case others still > encounter it. > Or, rather, leaving FIXED in case anyone needs to reopen it. ;)
Just to confirm I couldn't reproduce this bug in 51-1.
The fix seems to be doing away with icon caches altogether (/usr/bin/gtk-update-icon-cache is now a nop shell script). While this does resolve the problem reported here I wonder if it's the final solution or a temporary workaround and a better fix is coming in a later release.
(In reply to comment #33) > The fix seems to be doing away with icon caches altogether > (/usr/bin/gtk-update-icon-cache is now a nop shell script). While this does > resolve the problem reported here Disabling it speeds up application installation, decreases disk churn and frees 3MB(!) of disk space for other data. If you don't reflash your device, you may need to remove the cache file manually (I don't know whether SSU removes it). As a downside it may slightly slows down some applications startup if they use a lot of icons, especially such which data has already been loaded by other apps. Depending how icon data is laid out in the cache file, getting rid of it may increase or decrease application real memory usage. It will slightly increase system RAM usage in general, but lower it at package installation (less kernel page cache usage). These differences should be too small to be user visible though, so I think it's pretty good compromise. > I wonder if it's the final solution or a temporary workaround and > a better fix is coming in a later release. AFAIK it's final, but not a complete solution. For SSU there are further improvements: * application manager disk space heuristics have been slightly improved * application manager will kill more always resident processes on SSU so that they don't cause old disk contents (browser libs etc) to be retained until reboot * UBIFS LZO compression level will be raised. It was lower than what's used for the release images, so re-installing newer versions of pre-installed packages increased disk usage. Higher compression level on rootfs means that more (compressable) data will fit there, but SSU package installation will be slower. (getting rid of icon cache rewrite compensates for this on normal application installations, so I don't think their speed changes significantly)
(In reply to comment #34) > Depending how icon data is laid out in the cache file, getting rid of it > may increase or decrease application real memory usage. It will slightly > increase system RAM usage in general, but lower it at package installation > (less kernel page cache usage). These differences should be too small to be > user visible though One advantage of the cache is that it's mmap'ed so it's shared between apps. I would expect higher memory usage overall, but to be honest I haven't noticed any issues after using 2.2009.51-1 for a couple of days. > so I think it's pretty good compromise. Better than the previous situation for sure! Still, I wonder how GNOME manages not to run into this problem and whether it could be an easy fix in some library, but life's too short to pursue further I guess. > AFAIK it's final, but not a complete solution. Ok, verifying then. I had plenty of space left after flashing 2.2009.51-1 and restoring all apps in one go, whereas I had to restore in several steps with reboots inbetween with 1.2009.42-11. (Also removing non-optified keyword as the solution didn't involve /opt after all)
(In reply to comment #35) > Still, I wonder how GNOME manages not to run into this problem Desktop machines have typically GBs of free disk space, so you might not notice an issue like this there... If you're running your desktop machine with only few tens of MB of free space and you start doing system upgrades, you're going to run into problems too. :-)
(In reply to comment #36) > Desktop machines have typically GBs of free disk space, so you might not notice > an issue like this there... I meant that in GNOME 2.26 at least (comment 11) all running apps seem to notice that the cache has changed and refresh it so there's no filesystem leak.
The problem reported here should be fixed in the update released today for public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes). Please leave a comment if the problem is not fixed for you in this update version.
(In reply to comment #38) > The problem reported here should be fixed in the update released today for > public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes). It should be fixed already in the PR1.0.1 (44.1 update).
(In reply to comment #39) > (In reply to comment #38) > > The problem reported here should be fixed in the update released today for > > public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes). > > It should be fixed already in the PR1.0.1 (44.1 update). > 42-11: 14MB free 51-01: 16MB free :-\ I run this script, after i have 55MB. http://talk.maemo.org/showthread.php?t=40131&page=6
hey guys, i just encounter the no space available in installing apps after installing hildon-input method-plugins-scim, hildon-theme-hitech, hildon-theme-itheme & hitech. i uninstalled some of the apps before hildon apps but that aint work. after unstalling hildon apps my n900 was able to download apps again and it run fast. i need help for my themes. after i installed the pc suite for n900 so that i can connect my phone to my pc the themes stop working. when i tap the themes in the phone settings it aint do nothing. now i cant change any themes even i have downloaded few in application manager.
(In reply to comment #41) > hey guys, i just encounter the no space available in installing apps after > installing hildon-input method-plugins-scim, hildon-theme-hitech, > ... > i need help for my themes. after i installed the pc suite for n900 so that i > can connect my phone to my pc ... Your requests do not have anything to do with the bug tracker you are commenting on. To get help from the community, post your questions to talk.maemo.org. While doing that, keep in mind that none of the people there are paid to solve your problems, so your success rate getting help may vary.