Notices

does backupmenu starts and work fine if maemo is not booting i.e if it is reboot loops ?

It depends on how far Maemo is booting before rebooting..

Normally backupmenu is running from bootmenu, which in turns is executed by /sbin/preinit (first userspace program run directly by the kernel).

If you already have bootmenu and can see it when booting, then you should be OK. Otherwise, if you have U-boot (and you should), then you can use the image posted a couple of posts above to run backupmenu directly from U-boot.

how can I get contact list from backupmenu ?
because my screen doesn't respond and I cannot pass the lockcode screen
also I am not sure what is the terminal root password and I don't know how to access the terminal from backupmenu I get black screen I don't know what should I type "root" and then "[password]" then press enter or just the password

I need contact list urgently because I got out from hospital after surgery and I have Doctor's number saved but the touch screen doen't respond

So... I have an issue and a word of advice to all. I have a rather customized system, but have been using backup menu to back things up occasionally before updates and what not. I recently had need to try to restore from a backup, and found it failed. Imagine my surprise when I found that pretty much all of the optfs backups I'd made failed when trying to manually untar them with the error:

Backup menu gave no indication that the archive was faulty, but almost all of the optfs backups had this issue. The file system it was backing up had no fs errors (I ran fsck from the command prompt before doing a backup to be sure). The rootfs backups seem to be fine.

Maybe it has something to do with the size of the tar files? They're only about 1.4G, which should be well under the size cap for files on a vfat system. Maybe a sync/unmount isn't being done after the tar is done? I just don't get why it would be screwed up.

Doing a tar -tvf | wc -l shows about 50000 files, where fsck shows more than that. So a lot of data is after this bad spot. Word to the wise: check your backups to make sure they're good.

I'm trying to do a hand-backup using tar from the root prompt in backup-menu right now to see if it works any better. Turns out the mountsd script is broken in some way too, just FYI. Manual mounting works find though, and again fsck says the files system is fine...

Edit: As a note, hand-mounting and using a tar command to create a backup of the optfs worked just fine. The end file count was 65226 files, with a compressed size of 978M. Uncompressed it should be 1.6G. I'm trying to do a piped decompress now to see if I hit a file system issue when doing so.

Please define "manually untar". AFAIK Backupmenu (I don't have it so I can't say 100% for sure) uses a separate tar (not busybox). Perhaps you tried to manually untar it using busybox?

I don't know if this may be the problem or not, but in any case, I'm slowly reaching the conclusion that the general problems associated with busybox (power or stock) don't compensate for any (alleged) benefits.

I think it's time to get rid of it (will get to it as soon as I have some time .

No.. I tried to manually untar it both Fremantle and in Backupmenu's root shell, as well as on my Fedora system at home. All gave the same results. It was a bad/truncated file, not a busybox issue at all.

After running another backup, I dropped to root shell after and found the systems still mounted. I did a sync, unmounted, then rebooted, and that archive tested as fine. So I'm thinking it's some kind of caching issue?

In the end, more of a warning: Check your backups after you make them. It only take a few seconds, and is worth the check. Maybe an option in Backupmenu to check a backup file would be a good idea?

Never had such issue (but not yet needed to use it really, just untaring and get some files)!
And/but I do use the multiboot-backupmenu. Do not know if there are differences (at least there is no shell).

Just made a new backup, checked and everything OK.

One of the options in BackupMenu is to start a terminal shell (t, if I recall). It's actually quite a life saver for doing minor adjustments and fixes, like moving/replacing a file or the like.

And again, I'm not blaming anyone for anything. It could also be that the file system these were on became corrupt, since most of these backups were from past updates (so spanning months at a time). Just figured I'd note that it's best to actually test the archives made, and request maybe one additional menu option to test an existing archive.

This may also be device specific, or only happening in certain card types (I'm backing up to my uSD: 32G class 10). In any case, never hurts to check.

And thanks again to Robbie for all the work on this. It's pulled more devices out of the fire than I think anyone really knows.

Quick question: Did you try and unpack it with a GUI on your Fedora system?

I use Nautilus FM at home, and often I simply right-click a file to unpack it. But the last year or so, I have been seeing errors doing that, where the errors would disappear the moment I used the command line version to unpack/decompress.

No.. I'm more of a command line guy.

Turns out I had a couple of older backups I was able to get the data I needed from. But it looks like a sync issue. May have something to do with the class/size of the memory card? (32G/10) Put my 32G/4 in instead and it works fine every time. May also be a device issue... This is my most used device, running 24/7 now for 3 years.