Notices

Oh by the way, is the console mode coming back into this new version? I think ubinize could be called from within it, which would save the stage of rebooting back to maemo for making a flashable image from the rootfs tar (if you haven't got a linux PC, that is).

Yes and no.
First, the advantage/disadvantage of this new version is its running entirely off of a ramdisk. Therefor, the rootfs and optfs can be safely wiped with no issues(previous version didn't - I'm still not sure -how-/why it worked...).
This means that any applications I want, I have to load into the ramdisk first, along with all libraries they need. This is the issue with FSCK currently; I'm missing one library.

On top of this, the other problem is that I'm trying to make it -only- depending on the RootFS - which means I have to copy any optified files I need to the RootFS during install.

Neither of these are too much of an issue, but they both have to be worked around.

Secondly, the console I had didn't really work right. I can bring it back right now... But it won't "remember" directories, so you have to use absolute paths all the time.
I'd -like- to find some sort of terminal application(or end up with just SSH), that does everything the way it should be, and not grabbing each keystroke, and running the command inside a pair of ``'s.

Yeah, I think it's much better to use the ramdisk and also to only depend on rootfs. The libraries issue will also crop up if you integrate ubinize into BackupMenu, as it depends on liblzo2_2. However, once that's done (if ever) then console mode probably won't be needed anyway - I kind of liked the one in the old BackupMenu though, even with all its nuances I had also forgotten about SSH - though when I try to launch it (through the s option, which still exists) it tells me that it's not installed, even though it is?

Just one final really minor feature point - would it be possible to alter the brightness of the display, as 50 is quite battery draining? I think 20-25 would be better

Thanks Robbie! Works like a charm on my device

Any change to pack this up and distribute via repos?

Oh no this sounds like terrible news for me.

My N900 got bricked with a faulty usb port so opportunity to reflash or backup. Nokia are going to provide me with a new N900. When I get the N900 I was going to use Backup Menu to restore my files to the new N900.

Now that this new version is incompatible with the old version it seems I will be unable to restore. So my only option would be the Nokia backup and restore. However, I have not used that since like February so contacts, conboy notes, etc will be far far out of date.

Is the old version still available for download at all? So I can use that to restore and then switch to the new version for back up and restores going forward.

Yes, the old one's still in the repo. In fact, you won't ever -lose- it, because you can -always- get old versions from the repo. Just remember that its version 3.x you need.
Also, you don't need it. You should flash the RootFS image you have via the Nokia flasher, then boot your N900(which will have the version of BackupMenu you had when you made the image) into BackupMenu, and restore the Optfs.
If you -can't- get the rootfs to flash properly, then you have a problem, the same problem that caused me to change.

Also, erm... To be fair, the only difference between the "old" backupmenu and the "new" one is that it's running in a ramdisk. All the old code(aside from console, which I took out because it was too -big- to read through when debugging) is still there. And the old key-commands still work. The menu-option text lines are just commented out.
However, none of the other options -work-, because of missing files.

Also, I don't think ssh or anything that relied on the USB Network actually worked; I copied that code from RescueMenu and didn't understand quite how to make it all work.

Ok, I added a couple more libraries, and I -think- I fixed FSCK. Also, lowered the brightness to 40/255.

Why does the latest .tar.gz include two .item files:
etc/bootmenu.d/BackupMenu.item
etc/bootmenu.d/backupmenu.item

Because this way it replaces all previous instances of BackupMenu, preventing any conflicts. This way, if you have BackupMenu installed from the repo, -this- version will overwrite it and it will work right.
Only one of them is needed, and they are identical, one-line launcher scripts.
Edit, FSCK not quite fixed. Needs "libcom_err.so.2.1" this time.

Hi. Em, help.

Is there any reason in the world for the restore procedure to say that the checksums don't match?

I tried a restore today (weird, weird stuff happens to me, with GSM modem being taken offline) and the rootfs said the checksums don't match. Optfs apparently was fine.

Is there any reason (other than a bad block on flash) this wold happen? It's _possible_ that I used a mismatched version, my backup was on the 19th and you changed versions on the 18th or 19th, so I'm not sure what version they were.

So, I guess questions:
a) If mismatching versions between BackupMenu and images, is it possible to get a checksum error and end up with an unbootable device?

b) Does a bad block do that?

c) How do I check rootfs for bad blocks? The menu includes a "fsck all partitions" but it takes way too little to be a "surface" check. Finished in 3 seconds tops.

Hepl!

(what do you know, a sense of humor with an unbootable device)

ETA: It booted.

Re-flashed rootfs to default. Restored optfs with BackupMenu.