Notices

I've got several framebuffer kernels too, that's not an issue - The problem is that it isn't in the stock kernel, or the power kernel - The ones most people use.

As far as ubifs images, I may very well add that soon - I'm waiting on someone to see if zlib compression actually -works-(last I heard, the resulting image wasn't bootable).

One other thing I've been thinking very seriously about is adding PIN-protection(or a password) - Not for security against someone stealing it, but because of this - Sure, it's crackable, but it'd take a while.


@pali:
I'm not getting -any- menu. No way to select backupmenu, or flash, or anything. There's -no screen output-.
I've tried reinstalling bootmenu-1.9, just in case... nothing.

With 1.8, if I didn't have a .item file there hijacking the process, it would give bootmenu's menu.

pin/password would be nice to have. Frankly I cannot install this to my productive device without it.

Fair enough.
Ok, question: Pin or Password?
I figure I've got three options:
1. Input pin using the top row of keys. This would be very simple to do, and very quick to enter.
2. Input pin through the use of arrow keys and enter: A "menu" with all ten numbers in a grid, and you have to move the cursor around and press enter to select each. This would be slightly harder to implement, but would also provide some time-security: each key attempt would take a good ten seconds, at least.
3. Password using the full keyboard. Code would be about the same as #2, but you wouldn't be able to do a key "combination" like shift+x - You would have to press shift, release it, then press x.

Also, should I use the OS pin(in the case of #1 & 2), the root PW(in the case of #3), or a -different- password/pin?

I'm looking for the way to restore my data quickly without connecting to internet,,this way could be a effective solution,,but I'M worry about its reboot would confict to my android 2.2 mutiboot menu~~

could you find an solution for me?~~thanks.

I vote PIN, as in numerical entry. I also vote for arrow/grid input, however, like you said, the implementation is harder to do so regular key input would be suffice as well.

First off, I don't believe in MultiBoot - It's a nasty kludge, only really works with nitdroid, and is dangerous to n900's.

That being said, my project is GPL, and as such, these folks have a modified version that works with Multiboot. Apparently it works, but I don't use it so I cannot say for certain.

Pin it is then.
Should it be the same or different from the Maemo OS lock code?

It should be different, default to 12345 and the end-user can change it from within /usr/share/backupmenu item.

Fair enough. Would you like to see BackupMenu's root SSH password set to the same value? Or just use the OS's root PW?

I'd like to see it as root:toor for simplistic sake, but that's just me.

I think there was concensus for default BackupMenu SSH password that user can change, separate from the OS one, for simplicity sake (also I'm sure there's some users who don't have SSH on their N900... I know, wierd people. But they exist).

So yeah, I say BackupMenu's root SSH and BackupMenu's pin should be the same by default. But you should be able to change both, methinks, separately. So separate values, just set to the same initial value.

That said, I'd also like to not see the arrow-keys-plus-on-screen-grid entry. I think if you do implement it, it should be a setting option. Why? Because if you're doing some trouble shooting or regular screwy N900 stuff that requires you to load up BackupMenu somewhat recently, it would get annoying very fast to select your password with arrow keys every time you boot into BackupMenu.

Hmmm... Is there a way to use TrueCrypt from within the boot-process? Just encrypt literally everything, except perhaps the bootloader?