Notices

Friends who can help me?
Restore the backup application is using Maemo flasher..

Let me get this straight. You have a backup made with BackupMenu and want to restore your phone to that backup using Fasher? The short answer is you can't. BackupMenu uses the tar format and Flasher uses its own format which is almost, but not entirely unlike tar. Someone might be able to write a convertor but you can't just take one and expect it to work in the other.

There is a way of restoring a BackupMenu backup without using BackupMenu but it not for the feint of heart, does not work in all cases, requires a correctly booting device and is so fraught with danger that I would not recommend it to anyone whose Linux skills are below at least a brown belt level.

Why can't you just use BackupMenu?

no hope to have the new package?

I'm not regular user of BackUpMenu. I just installed version 1.2.0-1. I started to create backup of root and opt. And got confused how much I need spare space.

Now I'm reading /usr/share/backupmenu/BackupMenu.item:778 And I'm still not understanding help text about "Make sure you have 2GB+ of free space on..." I mean, is this hint for both selections or only for the latter?

It should not use hardcoded 2GB, but check how much there are data to backup. Compressed size can be only estimate. (Yes, I have bigger opt than 2GB)


It got rootfs done and when my disk run out of space with optfs, it gave "Error 2" + "OptFS Backup complete" + "All operations completed successfully."

And indeed when unpacking I got "Unexpected EOF in archive".

@alexporta,
If instructions in post #1200 make no sense to you, then your best option really is rolling initrd-progs back to 0.81-7, as has been suggested to you a number of times. You can fix the version (so that FAM and/or apt-get upgrade won't bother you) by opening (or creating if not present) a file /etc/apt/preferences and adding this bit:
@AapoRantalainen,
You are right, some things are hard-coded. The size is one of them. Locations of various partitions is another. Most annoyingly so is the type, at least in one case (see below).

@RobbieThe1st,
May have a suggestion if you ever get around to updating BackupMenu. I suggest replacing mkfs.ext3 on line 1255 of BackupMenu.item with mkfs.$backup_optFS_part_type. That way if I reformat my optfs to ext4, BackupMenu won't reformat it back to ext3 on next restore. It also requires adding mkfs.ext4 to extrafiles.tar.gz and probably updating mount* accordingly. I have updated them by copying the relevant subset of lines 14-24 from BackupMenu.item.

upgrading many tests i've found that updating the package: "initrd-progs" causes backupmenu to get stuck at the black screen right after the "chrooting..." message. this is output from the update:

Preparing to replace initrd-progs 0.81-7+0m5 (using .../initrd-progs_1.0-2_armel.deb)

i am using 2011.38-1Tmaemo7.2+thumb1, KP - 2.6.28.10-power52 and backupmenu 1.2.0-1.
overwriting the files in this package with the files of "0.81-7+0m5" makes backupmenu work again (the blue screen with keyboard commands is displayed)

I have to reboot unexpectedly difficult to bring
Is there any relationship between the keyboard and the backup menu? At the Reboot ؛)

I have switched from Multiboot to Uboot and reinstalled backupmenu using the image and process (sort of) described in this post: http://talk.maemo.org/showpost.php?p...&postcount=915

I notice that backup menu shows v1.1, but isn't blue/white like it used to be. Is this the latest verison I'm running that is just a plain text screen? (maybe a side-effect of running it under this uboot compatible image?)

It has been reported that a recent change to initrd-progs changed the colours in BackupMenu and/or stopped it working. I have not tried your combination so cannot confirm this is the cause but you can easily verify it by forcing initrd-progs to version 0.81-7.

I don't believe that is the problem, as it works fine. The uboot "image" posted is a kernel, a initrd image, and a lzma file with all the helper files that I believe is unpacked into ramdisk where root lives.