My uneducated and totally intuitive suggestion for people having problems during swapoff is to enable swap on microsd first, i.e. "swap refreshing" procedure should look as follow:

swapon mmcblk1p2
swapoff mmcblk0p3
swapon mmcblk0p3
swapoff mmcblk1p2

Of course You NEED to have a swap partition on Your SD card, but it may be even just few megabytes. Going back to my totally unchecked and not proofed (cause I'm unable to replicate that sort of reset when swapoff) ideas, i think that swapoff hard way without enabling swap elsewhere may drive some critical processes mad - but only in certain circumstances, i.e. not always reproduceable. then, of course, watchdogs perform reset.

By the way, and what may be even more important - using swap (normal 768 Mb, not few-megabytes variant only for refreshing) exclusive on microSD and tweaks as discussed on thread mentioned by qole (last pages, first post is outdated), I got 0 problems with reboots/crashes/whatever, no matter how big file i test.

anyway, i think that it may be worth to mention (again in topic about I/O improvement) recent discoveries about MyDocs exclusive involvement in I/O problems - maybe that is something with vfat module or whatever related to vfat? I wonder if someone who got MyDocs reformatted to ext3 - for example - got the same problems.

Eero Tamminen of Nokia blames "your program" for causing all the problems. Apparently if "your program" doesn't have a workaround for the N900's idiosyncratic way of caching data?

As I said in the bug report I link to below, I would love a little app that "tells the kernel" to stop caching data for any arbitrary command or shell session, the way you can run "time <command>" or "tsocks <command>". It would be cool to be able to run, "nocache lzma "


https://bugs.maemo.org/show_bug.cgi?id=9353#c18

This is interesting. I have had tragic crashes with file system corruption when trying to copy many files or just one big file with cp.
Now I'd like to know how to copy with gnome-vfs.

Yea, i also follow this bug report from the very beginning. I think that by "your program", Eero mean "copy program" (that is exactly what he said in your citation), i.e he blame cp / dd. Other way, it not make any sense... So, should we rise bug against cp / dd, or what? And, anyone confirmed that using gnome-vfs really solve issues 100% times?

for all the people having decompression problems, instead of relying on the n900 to decompress the image, I instead decompressed it on a pc using 7zip. I too had the crash whilst decompressing.

Install steps I took:
- install the easy debian app from the application manager
- from your desktop computer, go to
http://qole.org/files/

and download either

debian-m5-v3d.img.ext2.lzma or debian-m5-v3e.img.ext2.lzma
depending if you want the v3e or v3d image

Open and extract this using 7zip.

Copy and then paste onto your n900 in the root directory.

Then just run the easydebian apps that you require (no need to do the deb img install)

Didnt see this posted elsewhere

I really want to hear back from those using the newest 0.9.56 from Extras-Devel: Does the new installer fix your problem or cause a reboot just before decompression?

For me, the new version was the "magic bullet" but some people are having new problems with it (reboot before starting decompression).

I didn't know how powerful gnomevfs was... and it has always been on our n900! See here: http://www.linux.com/archive/feature/130834

On my install I have:
gnomevfs-cat gnomevfs-info gnomevfs-monitor
gnomevfs-copy gnomevfs-ls gnomevfs-mv
gnomevfs-df gnomevfs-mkdir gnomevfs-rm

Should be enough for common file operations.

There are also the following modules:
ls /usr/lib/gnome-vfs-2.0/modules/
libcaselessfile.so libgzip.so libtar.so
libdns-sd.so libhttp.so libupnpav.so
libftp.so libnetwork.so libvfs-test.so

Alan, maybe if your image file is gzipped instead that lzma-ed you could uncompress it with gnomevfs and have no crashes?

I was wondering why I do not have the reboot problem. The only really strange thing that happens is when I try to download a program from the debian repositories and I do not have enough space. This corrupts some files that I am not able to delete. My solution is to either copy over a backed up image or download and install a new one. (I've done both) I have not had any reboot issues. So my question is, what have I not done that everyone else has that leads to the rebooting problem?

Try to answer us Yourself do You use Swappolube? Or modified any i/o settings Yourself/by hawaii early scripts/whatever? Or, maybe You use/don't use microSD card of non standard properties?

Hi. I had mentioned this a bit earlier

http://talk.maemo.org/showpost.php?p...postcount=2248

http://talk.maemo.org/showpost.php?p...postcount=2250

As you can see, I'm not that adventuresome by most standards!
Anyways, I'd be happy to try some suggestions if it can help whittle down possible causes. I'll check my microSD card and get back to you.


EDIT. For what it's worth, I'm using a Scan Disk 8GB microSD HC.
I have never downloaded the compressed Debian image directly to the microSD, but I have copied the Debian image (uncompressed) back and forth from microSD and MyDocs.