Re: [Announce] BackupMenu V2 - OS backup & restore
 

You are lucky - It -did- work. If it didn't, your system wouldn't have booted.
Either way though, the V0.3x series is old and only for people who need to restore old backups. The new version is safer, and while it has it's own glitches, it works better overall.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

BackupMenu.item line 407:

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Huh, I'll try removing the -y option next time I edit things.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I have tested alternative compression types on my rootfs.tar.

Using no parameter in the mkfs.ubifs command, as above, gives a finale img file 192,806,912 bytes large.

Using zlib compression like that:or a mixed compression like that: gives a much smaller img file to flash: 168,951,808 bytes.

The difference is quite large: 23,855,104 bytes.

Maybe this is the key to the problem of disappearing space when restoring.

I am not in the mood of trying a restore - I need my N900 working... but someone more inclined to experiments could try and see if flashing images with different compression types results in different free space in the rootfs.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

You don't need to reflash it you can use nandsim to the same effect - even on-device if you apply a diff and compile your own kernel (it needs cache_file as otherwise all the RAM gets used up, I've asked Titan to add it to kernel-power, but no response as of yet).

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I keep getting an error message when I try to back up:

Mounting the OptFS...
Backing up Optfs with Tar---
Error: retured 2.
Press any key to continue
OPtFS Backup complete
all operations completed successfully

Get the same message on the root backup.

Although it says operations completed successfully but I do not think the backup was successful because it takes no time at all and of course because of the error message as well.

Any ideas on how I fix the problem?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Check your *drive*/systemBackups folder - what files exist and what size?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

one thing ive noticed, is my MyDocs doesnt get restored properly... I think anyway... must do more tests

Re: [Announce] BackupMenu V2 - OS backup & restore
 

MyDocs gets backed up too? That's new to me. How do you do that?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

...it's also not in the backup included. Perhaps this is the reason. ;)

It's more easier to connect your N900 via usb to your PC and backup MyDocs manually. BackupMenu with a Backup including MyDocs will be possible. But your MyDocs is 27GB large. And in this case you will only be able to backup to your SD card... and not everybody owns a empty 32GB micro SD card. :)

So I guess the current solution is the best one for everybody.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Have a 623.1mb -optfs file and a 270.4mb rootfs file.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I think, Backupmenu should have a settable password.

I'd love to install this, but if my device get stolen or lost, backupmenu without password is too easy way to hack it.

Because, even if rootfs and eMMC is flashed, security code stays the same and if it has been set, the device will ask the security code when the system boots after both rootfs+eMMC-flash.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Er... No, it doesn't. If you flash your n900, the security code will be the same, yes, but it -will not- ask for it at boot. This means that someone could easily enough simply pull up a root terminal, grab a "key-code grabber" script(It's one line), run the encrypted result through John The Ripper, and have a new password set in an hour.

Remember: When you lose physical control, you have lost all security.

As such, I'm not going to do this. SSH/terminal mode -do- require a password however(Your root password).
Also, for anyone that cares - Once you login via ssh and have your password entered, you can type "getlockcode" at the prompt to recover your (encrypted) lock code.

@etuoyo:
Can you give me the output of "df -h"? That rootfs size looks fine, and the optfs -may- be fine too. It may be just a corrupted file or something... But you should be getting a message about it during backup.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I have flashed couple of times both eMMC+rootfs and every time when I boot, the N900 asks the security code or it will not boot further. Also my N900 (both of them) somehow does not show anything useful for John The Ripper to work from.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I just checked the topic. I'm guessing you broke something in /dev/mtd1 (Bad block, perhaps?) - Not only is flashing not resetting it, but you aren't getting any code back, while everyone else seems to be able to do it.

Unless you can actually have your code -work- as well as not be able to get in after reflash without the code, I can't say that's the "normal" behavior.

edit:
As it is, if you are a knowledgable person(and take the time), if you have BackupMenu on your system you would be able to login via SSH(with your root password) and either crack or replace/fix the lock code if it was needed.
I'm pretty sure that in the case of BackupMenu, users would prefer to be able to recover things than have more security. Remember, if there was a lock on this too, you would be screwed - you wouldn't be able to get in via BM either.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Hey Robbie, I've been thinking more about using nandsim/nandwrite to make it easier to create the ubinized image. In the process, I've discovered an alternative to using dd which does include OOB data - namely, nanddump /dev/mtd5 (the rootfs partition). This can then be restored using nandwrite -a -o /dev/mtd5 path/to/image/file and does keep bad blocks marked etc?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

There are few others who have this "problem" also, that there is not coming anything looking like DES encryption after the string "lock_code" in /dev/mtd1

I wonder, if this is a patent thing, and in some parts of the world Nokia has indeed used other encryption than DES.
Or if it indeed is some kind of fortunate seldom triggered bug, that makes the device harder to crack.

And forgot to mention, I have in settings, that in 10 minutes of idle usage, the device will lock itself with the security code. I think that is why it asks the security code every time it boots up, also after full rootfs+rMMC reflash. I guess people normally do not have that auto security lock enabled and haven't noticed it does survive over reflash also. (which seems to be a good thing).

Backupmenu asks a root password with ssh access, good, but using (o) USB-storage mode or Create a backup it is, IMO, too easy now to copy user data out of the device by a thief. Couldn't the same password be used as with ssh-access to whole backupmenu if a user wants to set up it that way?

I know, having physical access to the device and enough time, a thief can get the data anyhow, maybe (?), but now with backupmenu leaving the phone unattended just for a few minutes lets a cracker copy eMMC to his PC and only thing owner notices is that the device has been shut down.

I said "maybe", because currently I haven't figured out how to access or mount /home/user (or MyDocs) without knowing the security code. Maybe flashing with rescue_initrd allows it to be mounted over USB without knowing the security code? Also in those devices where DES is working "normally", I guess one can flash /dev/mtd1 and get rid of the security code asking, but then the owner will notice that the security code has been removed.

At least, it would make the crack harder and more time consuming and perhaps there would be marks left by a cracker. Now with backupmenu installed there is no trails left to notice if someone has stolen you data while you were in a toilet.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Guys,
I havent read the 42 page thread but need some suggestions. I plan to install my own custom kernel on N900 but before doing that want to make sure i dont end with a bricked device. I have installed backupmenu and taken a backup of rootfs and opt in MyDocs.

Now if i flash my kernel (and copy over /lib/modules) and the device doesnt boot will i be able to restore the /lib/modules from backup. This is assuming that i still willbe able to see the bootmenu even after flashing my custom kernel and a bricked device.

Also, i dont plan to change my kernel version string but have it as -omap1 which is the same as stock kernel. I will simply overwrite all the stock /lib/modules/2.6.28-omap1 with my own custom kernel modules.

How does this sound?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

You'd be on a safers ide if you were leaving original files as they are and use some other string for your own kernel. That way you'd have no downside (as far as I know) but would always be able to reflash the original kernel and it would immediately find its own modules again.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I presently have a symlink /lib/modules/current which points to /lib/modules/2.6.28-omap1. Is that 'current' symlink necessary in maemo? Because if it is, and since it will point to my new set of modules and if try to use the stock kernel it will fail.

If i have /lib/modules/2.6.28-omap1 and /lib/modules/2.6.28-mykernel and no 'current' symlink, would the device boot up fine?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Usually: yes
But to be honest, I don't have a clue what modifications Nokia made to system, kernel, modules and handling of all of them. The 'current' symlink should just be a convenient way to access the current's kernel modules without having first to find out the exact revision number. Kernel internally should always use the full qualified modules path (e.g. /lib/modules/<myrevision>). But there might be chances that some external software relies on such a link, even if i doubt. In the end, all alternate kernels are working troublefree, so you might check whether they are installing such a link.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Another idea about the password.
Why not even enable user to set backupmenu such a way, if one wants, that it will ask password always wether keyboard was open or closed during the boot? As the default security code in N900 is DES-based, having some other <safe> encryption used as a "BIOS password" would be nice.

Have I understood correctly, backupmenu is located in a /dev/mtd0 in the bootloader area (this could be mentioned in the wiki page)? Flashing kernel, rootfs and eMMC will not override backupmenu? Is it possible to flash bootloader separately when the device is in flash-mode connected with USB?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

No, backupmenu is a simple script installed on the rootfs. Bootmenu/multiboot handle the early stages, but I'm pretty sure they don't replace the bootloader either (again, I think they're just scripts that replace the default init process) - uboot probably does though.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I'm slightly lost here - I thought that everyone who is not able to get their code via the mtd1 method was -also- not able to login with -any- code?

Now, one thing I -did- notice was that when I was testing out that /dev/mtd1 grabber script, the -first- time I tested it with root console, I got my encrypted code. The -second- and all following times, I got a blank string back.
However, when I ran that command via SSH inside BackupMenu, I was able to get the code -every- time I tried, with several different codes.

This may just be an issue of luck, or perhaps something ends up locking it up -sometimes-.

Either way, would you mind trying to grab it by installing BackupMenu and SSH server, then logging in and running "getlockcode" from the console? I'd like to see if it's an OS thing, or there -is- something different here.

@zimon: Rob1n is correct. It's just a script that relies on bootmenu-n900 for all the actual boot stuff. In fact, I'm not entirely sure quite how bootmenu-n900 actually works; I'm sure I was told at one point or another, but I've forgotten.
What I do know, though, is that if I put an ash-script file inside /etc/bootmenu.d/ with the extension .item, it will run that code during boot with the keyboard open.
Now, what's -supposed- to happen is that bootmenu-n900 will read all files and get menu items out of them as encoded variables. What -actually- happens is that it tries to read my script, which "hijacks" it, keeping control. This is why, when BackupMenu fails, it drops to the default bootmenu-n900 prompt.

Now, I'd like to figure out how to get a proper bootmenu-n900 compatible file there, so they can be run side-by-side, but I can't figure it out quite.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Can BackupMenu be NOT dependable of bootmenu? Because I have it installed using multiboot. I had to force install the deb package, and then tar the result, uninstall the package, untar the result.

That's the only way I don't get the failed dependences everytime I want to use apt-get for another package.

I guess there are others around here using multiboot instead of bootmenu as well...

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Well, I finally got around to testing this tonight - in the process figuring out that mkfs.ubifs actually works with the real rootfs partition when Maemo is running, as long as you create a chrooted environment first - and was very surprised with the results. Not only does zlib compression create a smaller image file (both pre- and post- ubinize) than lzo, but it's also much faster and yes, results in a lot more free space once that image is then written to simulated NAND (via nandwrite, with a flash_eraseall prior to that) - it rose from around 66Mb to 84Mb. I'm now going to try to add it to the backupmenu script - it should be doable as the setup-chroot script that I wrote was based on BackupMenuLauncher.item; not tonight, though ;)

Re: [Announce] BackupMenu V2 - OS backup & restore
 

You can edit the control file and remove that dependency. Or grab the binary package, remove the gzipped tarball and extract it manually.

It's fine the way it is, as far as I am concerned - it works for a new user, and anybody else who wants to toy with it and colliding packages - should understand how to fix these problems, in any case.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Even easier than that - BackupMenu.item is all run inside a chroot and the NAND Rootfs is -unmounted-.
All you've got to do is copy the files you need in the launcher, then inside BackupMenu.item you can mount the rootfs and whatever partition you want to store to, then run your code.
You can easily use existing stuff, too - Just stick your code after "#Put your test code after this comment." and when you press a key(L, I think it is), any code there will be run.
You may need to setup a loop for feedback like I've done with tar, but there's plenty of examples there.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Yep, I noticed that - it's what pointed me to chrooting on-device to try to use mkfs.ubifs :) By the way, why is the /tmp folder ignored during the tar process? It's empty anyway on the NAND - it's only there as a mount point, so copying it is harmless, surely? I only ask because I can't remove that during the mkfs.ubifs process.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

IIRC, for whatever reason -some- application ended up sticking a persistent fifo or device file inside it - something that couldn't be copied for whatever reason, and produced an error when tarring. So, I just excluded everything -inside- of the directory, though the directory itself gets copied.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

No, I have always been able to get in the system and my security code has been working. It asks it every time when I boot, whether it is normal boot or after roofs+emmc flash.

Something is weird in that, because now with the same system and through Backupmenu's ssh-terminal, I can see 5 "lock_code" strings, where the last three give DES-hash on the 13th row.
I can find the correct original (12345), my previous and the current security codes with 'john'.

But I am sure, before there wasn't any DES-strings found when I did the "grep -A 13 lock_code /dev/mtd1"-thing.

It is funny, you got the same result once also.
Seems like something little chaotic in the system.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

If I have understood correctly BackupMenu v2 use a ramdisk.
So it starts in rootFS, it creates a ramdisk and it copies some libs and other files to ramdisk, then it switches to ramdisk (and it dismounts rootFS).

Why don't materialize this ramdrive and then boot with initrd ?

• Faster start-up
• Possibility to use other boot system (i.e. multiboot, u-boot)
• Possibility to run BackupMenu even with rootFS destroyed. I.e. u-boot bootloader which loads a kernel and a initrd (containing BackupMenu) from SD Card
• Possibility to have many versions of Backup menu installed (many different initrd files)

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Mainly because I don't know how to do it.
If you want to do something of the sort, all you would have to do is:
1. make an initrd with all the files listed in /usr/share/backupmenu/BackupMenuLauncher.item
2. run /usr/share/backupmenu/BackupMenu.item from inside the initrd as a shell-script with ash.

It's actually pretty easy to mess with, but I don't know an awful lot about initrd's and other boot stuff - It's GPL, though, so you can do it yourself.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

My back up menu is definitely not working. I had a compressed backup and an uncompressed one. Tried to restore from both and neither worked. Got an unable to restore message.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

One, what version are you using.
Two, exactly what error message do you get?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

First i want to thank the developers of this very useful application.

I have Backup Menu 0.56 installed with multiboot and although i haven't yet tested a restore i think my backups are ok.

There are 2 issues however that i would like to know if they are already known / common or happen only in my system (sorry i didn't read all posts and search wasn't helpful):

1 - After selecting b for backup and t, for rootfs and opt, i have to press twice the M option to start the backup.

2 - sometimes, at he beginning of the rootfs backup, i get this error:

gtar /var/temp/qtsingleap-home-c6fc-752f socket ignored

It doesn't happen always and i don't know if this error is critical or not as the backup continues normally. For safety i always delete the backup with that error and do it again.

Thanks for your comments

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Of course my fingers were itching too much and I was able to hurt my optfs at the point I needed a restore.
This time I tried to make an img file out of a rootfs tar with zlib compression as detailed some posts above. But, when I flashed it, the device resulted unbootable.
Too bad.
So I restored the tar as usual and lost 14 megabytes of free root space. Not so tragic, provided that we won't have a pr1.4 most likely and so I won't be bothered not to have enough space to install the update.

Any other tried flashing a zlib compressed root img? Success?

Re: [Announce] BackupMenu V2 - OS backup & restore
 

e, e, for extras,erase is suboptimal! you easily bounce 'e' key. Make that anything different. I'd even suggest to have only UPERCASE command keys in extras menu, so you need to hold shift to 'confirm' you meant to do that.

in backup process (and other context as well?) there's a "depress hold switch..." statement. What is hold-switch? The sliding switch on right side of device is usually referred to as the lock-switch

fsck after creating backup results in

Might be worth a note that obviously during backup-menu battery charging isn't enabled

There's obviously no way to exit backup-menu and continue with normal bootup to system, just 'q' (quit) and "hold-switch" (which is lock-switch, and doesn't work when kbd-slider closed :-/). It would be *very* nice if lockswitch would work with closed kbd-slider as well, and wouldn't reboot device (i.e. do NOT go to NOLO again), but actually would boot up to normal system.


/j

Re: [Announce] BackupMenu V2 - OS backup & restore
 

I can't understand this:
the same optfs tar archive was able to be restored without any error two days ago.
Today, it gives several hundreds of "gtar: path/to/file/name: Cannot open: Stale NFS file handle" errors.
Tar exits with "Error: returned 2."

What's happening there?

EDIT: which way can I determine if the flash chip hosting /opt (and MyDocs) is becoming broken? This might be a common explanation of all my problems.

EDIT: weirdly enough, to restore my optfs, I had to:
1) restore the opt img with dd (but it wasn't good, when rebooting the optfs was mounted read only)
2) restore it again from tar.
This time no NFS stale handle errors

If I tried to restore the tar without putting there the img before, I had countless NFS stale handle errors and the optfs was damaged.

I am more and more convinced that my optfs chip is broken.

Re: [Announce] BackupMenu V2 - OS backup & restore
 

Might that be related to some detail I picked up in your signature? Buzzword electromigration.