maemo.org - Talk - [Announce] BackupMenu - OS backup & restore

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - [Announce] BackupMenu - OS backup & restore | New version - Jul 9th(v1.1) (https://talk.maemo.org/showthread.php?t=63975)

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

Quote:

Originally Posted by zimon (Post 888488)

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?

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

Quote:

Originally Posted by zimon (Post 888258)

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).

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

Quote:

Originally Posted by debernardis (Post 885453)

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:

Code:

mkfs.ubifs -x zlib -m 2048 -e 129024 -c 2047 -R 4MiB -r ./rootfs/ -v ./base.ubi.img

or a mixed compression like that:

Code:

mkfs.ubifs -x favor_lzo -X 5 -m 2048 -e 129024 -c 2047 -R 4MiB -r ./rootfs/ -v ./base.ubi.img

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.

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

Quote:

Originally Posted by Scorpius (Post 889996)

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

Quote:

Originally Posted by Tigerite (Post 890052)

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.