Notices

Sorry I am sort of a noob on this. I know how to flash the firmware on Windows but how do I flash the back up image? Do I replace in the flasher command for the firmware (flasher-3.5.exe -F RX-51_2009SE_2.2009.51-1_PR_COMBINED_MR0_ARM.bin -f -R) with (flasher-3.5.exe -F 20100822-backup-rootfs.img -f -R)
with 20100822-backup-rootfs.img being the name of the backup image.

Alternatively how do I get the old version of backup menu? Can't find it in application manager. Only found 0.56 which I assume is the new version.

Okay I worked out the right command:

flasher-3.5.exe -r 20100822-backup-rootfs.img -f -R

Flashing a rootfs image:
flasher-3.5.exe -r 20100822-backup-rootfs.img -f -R

As far as the old version goes... Um, I'm gonna have to find a copy and upload it to my website.
Note, though, that when you restore your rootfs, you will end up restoring backupmenu; leave your keyboard open on first boot, and restore the optfs from inside backupmenu.

I had this problem today.I had around ~70MB's, and after restore I have only 48MB's. I checked the folders looking for something that was using this space but couldn't identify the reason.

My bad that I did't logged a root "df -h > /home/user/MyDocs/root.log" to know exactly the affected dirs. Anyway, I really recomend this
before a restore. Maybe we're missing something.

Yes it's the same problem I faced: the restored ubifs has half the space free. I imagine it's an issue in the way files are compressed. I read there are two compression methods in ubifs. Could it be possible that when restoring the less efficient is used? Can we force the most efficient?

I found very interesting this chapter on lzo vs. zlib compression on ubifs, and the way to use both of them more efficiently: http://www.linux-mtd.infradead.org/f...ml#L_favor_lzo
We might transform the tar rootfs archive in a flashable img selecting either only zlib or a mix of zlib and lzo by using the proper parameter in mkfs.ubifs - see the first post of this thread for the howto.


On another hand, I am trying to fork the old ver 0.32, that as far as I know is the latest using dd to store a filesystem image. Basically, I want to solve the post pr1.3 problem of it not exiting the dd cycle and needing to pull the battery out to stop. In my hands, ver 0.32 has worked much better than the following tar based versions. With tar, several times I've had a broken restore of the optfs (stale nfs handle errors). Instead, img restore of optfs has never failed, and for rootfs it's been enough to restore through flashing with an external machine and never try a restore from the N900.

What do you think Robbie?

Just for the record, yesterday I did a complete restore from a ~1GB of rootfs+optfs backup and it worked perfectly.

But. When I started using BackupMenu I sometimes got confused by the "error" messages in the dialog. in many dialogs and was thinking if I did something wrong in the operations, particularly because I didn't see the details of the "errors". For instance when restore is complete, above the line "press any key to continue" I see something like "Error returned: 2". IF I was too panic to proceed I MIGHT have press hold and then ...
Similar things happen in fsck. There seem to be "errors" even if the checking goes through, like "errors may have been encountered..."
Also I wonder if it would help to put a list of available commands in the console. I still don't know what the terminal mode can do especially because of missing "/" (symbols input seem not working?).(edit: sorry I was talking about older versions. the current one doesn't have the terminal mode)
Maybe it's only me?
Overall I feel very happy with BackupMenu and I am thankful to the dev for making this which should have been provided by Nokia.

Maybe I'm wrong but I think I read somewhere that using DD could be dangerous. I think that this was the reason to switch to TAR but indeed it's a very odd problem. I'm reflashing my device right now. I don't want to lose ~20MB not even knowing what exactly is happening.

Maybe using the USB mode and DD from computer could be a solution. Wouldn't be so easy and convienient as just selecting the image from the MyDocs folder but I'm ok if is an option.

@009N

If your backup is ok this weird messages can't hurt you =]

BackupMenu is amazing, and grow very quickly... Rob is doing a great piece of code here. Maybe is something on my config/enviroment that is wrong but it's the second time I get a difference between space before/after restore.

Right now I feel afraid to do one restore but whatever it is, I know Robbie will figure it out.

I don't think *reading* with dd is dangerous. Is it? Then writing by reflashing should be safe.

Sorry buddy, I meant writing the image with DD.

Just came across another issue:
With both backupmenu (+ bootmenu-n900) and kernel-power v42 installed, the phone cannot boot up with charger plugged in. Uninstalling backupmenu & bootmenu-n900 then booting is fine. Not sure if it's a particular case. Just see if others can also reproduce this phenomenon.