Notices

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.

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)

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.

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.

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

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

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?

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

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.

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