Notices

Oh, and my launcher doesn't actually copy flash_eraseall yet (I only recently figured out it was the best option to use). It only has libgcc_s.so.1 as a library dependency though (other than the standard libc.so.6 and ld-linux.so.3) which is already copied by the launcher anyway, so it's just a one-line addition.

Robie, the version that is in the repositories is 0.60.1 and have problems, can you up the 0.60.2?

Another thing, you know because when I use backupmenu fsck I get this error when analyzing Optfs?

EDIT: seems the option w usb mass storage read and write is not working on the new version.

I'll take more of a look tonight(and release v0.61), but right now I've fixed the fsck issue(I -thought- I'd forgotten something).

As for write-USB-Mass-Storage, remember that you've got to be root to write to the OptFS/2GB FS. I just tried that and had it work, so...

Tigerite, I'll look at your code tonight. Do you have a set of commands/options that you've gotten working? (i.e. what commands, options, and order you need to produce a valid file)

SSH didnt work for me.

thank you.

Ok, Version 0.61-1 has been uploaded.
This version:
1. Fixes those pesky battery-charger issues.
2. Fixes a slightly-broken SSH issue(login was possible, but getting a terminal was not)
3. FSCK mode should be fixed.
4. Removed some debug output; changed some black-on-black text to white-on-black so it can be seen.

edit: and it's now available in the repo.

Yep, I've got some scripts that I've successfully run chrooted. Backup is quite straightforward:

Naturally, replace zlib with lzo for that option and /tmp/mnt/rootfs to wherever the rootfs partition is mounted. Then ubinize that image:

The zlib here is of course optional, I just use it to distinguish between zlibbed and lzo'd images. BackupMenu would need to add the date stamp too, but as these are just my testing, I didn't bother; the ubinize.cfg is the standard one posted previously, with /home/user/MyDocs/systemBackups/rootfs.ubi.img in the image parameter. This can stay without any date/time as it's only a temporary image anyway.

Then for restore:

This assumes that the rootfs partition is at mtd5, I can't imagine it would ever be anywhere else, but perhaps some sanity check to be completely sure. Again the rootfs.zlib.img would need a date/time for BackupMenu. I also think doing a ubidetach prior to flash_eraseall and nandwrite, then ubiattach afterwards, would be safer; the rootfs partition should be umounted too:

Neither ubiattach/detach need new libraries, just the standard libc and linux.

Hope this helps

I've had a few issues with these latest versions, which I've (eventually) managed to track down. On my system, /bin/tar is a symlink to /usr/bin/gnu/tar (which is linked under /opt and unavailable) - I'm not sure whether this is as a result of something I've installed or whether it's something I've manually changed - so it fails to extract the extrafiles archive. This means the rest of the process fails (dumping a load of symlinks into the root) as the expected directories aren't there. Changing the BackupMenuLauncher.item script to call "busybox tar" instead of just "tar" fixes this (or using "/usr/share/backupmenu/tar" instead).

While playing around with that, I've also got BackupMenu showing up in the boot menu (instead of just launching it) - to do this, the /etc/bootmenu.d/backupmenu.item file needs to contains:

Today I had some spare time and so I tried again to make an ubifs image of my rootfs, by processing the latest tar generated by backupmenu. Well, I can confirm that the obtained image, when flashed, cannot boot. These are the commands I used:Is there anything wrong in your opinion in the above?

You know what? My suspect is the last line, the one which flashes the img.
After my n900 was in unbootable state, I reflashed the flashable_rootfs_v0.56-1-20101109.img that is available on Robbiethe1st site. Didn't flash the kernel.
After that I rebooted with keyboard open, intending to restore my latest rootfs. Well, I couldn't, because backupmenu couldn't see the sdcard (where my tar images were allocated).
I had to reflash the stock 1.3 firmware, then the image with backupmenu 0.56, then my rootfs (and of course reinstall kernel-power).

So my question is, what happened in the reflash with the zlib'd image that prevented my n900 to see mmc1, and was over when a full reflash with stock image was performed?

Might be that the last line reflashes in a wrong way and touches something that hadn't to be touched?

Sorry if this seems delirious. After all, I'm playing with things I don't fully understand

Yes, I believe that flasher doesn't like the ubinized file when it's compressed with zlib. However nandwrite isn't as fussy and just happily, well, writes the data to the mtd5 block - the reason that flash_eraseall is needed is so that the ubi controller doesn't get in a tizzy and fail to mount the device once attached.

I'll test later (to simulated NAND) if it's possible to use nandwrite with the file created via mkfs.ubifs, i.e. prior to ubinizing, if ubiupdatevol is called first. It probably won't work, but worth a try anyway.

Can you check this?
http://talk.maemo.org/showpost.php?p...&postcount=540