Notices

Quoting myself, I was right. I have now built my ubifs img with lzo compression on-device and it loads ok. I passed from 37.5M to 59.3M free and I'm very happy of that!

Robbiethe1st had already hinted that:
We can safely assume that mtd-utils_20100706-1_i386.deb from ubuntu maverick repos doesn't work.

Could you try with zlib compression and see if it flashes? It should give you a good 10M more again if so..

I thought we could backup the rootfs without the need of rebooting and acting inside a bootmenu item by doing something like:
and applying mkfs.ubifs to /home/user/nand

This almost works, but when I invoke mkfs.ubifs to make the image e.g. in /media/mmc1/base.ubifs.img it complains that the destination image *is* inside the rootfs.
Indeed, the mounted ./nand contains the rootfs *minus* the submounts like /proc, /sys and /media, but mkfs.ubifs - who thinks he's smart - still thinks that /media/mmc1/base.ubifs.img is inside the tree he's got to process.

If we find a way to fool mkfs.ubifs we can backup the rootfs (and much more easily the optfs) from an ordinary gui app, without the need of using bootmenu, and this would be sweet.

We can still mount nand with bind and copy everything to another directory - say nand2 - then apply mkfs.ubifs to nand2 which now isn't really the root "/" - but this is disproportionally slow.

Anybody has an idea how to do it?

EDIT: also consider that my last two attempts to untar a rootfs.tar in /home/user or cp -a /home/user/nand/* /home/user/nand2/ ended in catastrophic optfs damage - I had to mount /optfs in backupmenu, mkfs.ext3 it again and restore the optfs tar. It seems that very large copy attempts are not liked by the system.

NO.
There's a very good reason not to do this - Trying to copy files that may change on-the-fly is bad practice; in addition, the files in /dev/ are wrong - At boot time, there are a few special files in there, and udev mounts over top of it, so you can't find the required files.
I ran into this quite a while ago; it took a bit of help to figure out -why- it wouldn't work right.
------

V0.62-1 has been uploaded, with the above patches.
If it still doesn't work, let me know. Let me know any tests, what works, what doesn't. Please!

You can do it within a chroot though, which is how I tested (with the help of nandsim) the various scripts. There is still the issue that files may be in use, though; not so sure on the dev argument?

Starts allright this time, not showing bootmenu menu. Senses charging (or, at least, turns brightness on and off - don't know how to determine if really charging). Exposes rootfs, optfs, sdcard in 'w' mode. Doesn't throw errors in 'fsck all partitions'. Makes the tar archives on sd as required. A-OK for these issues .

Edit: BUT! After rebooting, doesn't sense any more mass-storage mode (this is an issue that showed also after using h-e-n aka hostmode now scripts). Senses charging though through the power adapter. Can't restore normal functioning by now. Tried pulling battery for one or for five minutes but still doesn't do mass storage.

Edit2: not even 10 minutes without battery sufficed. Now reflashing stock kernel, then my yesterday's lzo image, then restoring yesterday's optfs. Fingers crossed.

Edit3: Then I had to restore kernel-power, and still it didn't do mass storage. Then rebooted and mass storage worked again.

Sticking to 0.56 for now, be careful please with i2c-tools

It looks like it's -still- not fixed. Darnit.
I'll try adding some timing elements; see if that's causing the problem - For some reason, the charging chip's mode is not set to whatever BME happens to want, and it complains.
edit:
I was told "Oh, yea, it's -perfectly- safe. I've been using it for weeks. Nothing to worry about." Yea...

One thing you can do to (possibly) fix USB mode is:
1. Open up a console, gain root.
2. type "stop bme", plug in your USB cable.
2. extract /usr/share/backupmenu/extrafiles.tar.gz
3. run "./bin/charge.sh" from inside it. Wait a few seconds for it to say "charging" etc.
4. hit ctrl+c to cancel it, wait 20 seconds until the LED goes solid orange.
5. Hit "start bme". Things should begin to charge normally and USB mode will work again.

edit: The above -may- not work above 90% charge; you may have to let it run down to around there, then try it. Why? I dunno.

IIRC BME doesn't charge unles battery is under a certain percent to prevent yoyo charging when left plugged for ages and against fidgety power.

So, by design?

OK, I did it. The on-device-zlib-compressed rootfs flashes and saves much more rootfs space: I have now 78.9M free! (With lzo was 59.3M, with plain untarring was 37.5M). More than doubled!

What am I going to do with all this free space in rootfs?

Oh, and by the way: I untarred the backupmenu rootfs tar in /home/user/rootfs with my external computer, and with my n900 connected in backupmenu's mass storage mode. Trying to untar on-device doesn't always result in an happy end; more likely, it's going to stall the device and make damage on optfs, at least in my hands - and with swappolube on. I should try with swappiness=100.

Thanks menu working again, just doing a backup now.