Notices

hi robbie,

first of all thanks for this great app.

i wanted to know if this new version is stable or should i stick to the one in extras repo and is this version only for testing?
cause this one works with tar-gnu and the first one with .img?
whats the difference?

i have noticed that creating a backup with this version goes way faster than the first version, is it because of tar? and how do i know if everything is backdup? in the first version my optfs backup was 2g and with this version its 546 mb? is it becuase of the tar?
sorry i am a noob!

and i might be wrong but i think ur second line in the explaination shouldn't be backupmenu-n900 but bootmenu-n900???

thanks in advance

Now, that would make sense as to why I had another BackupMenu.item within /etc/bootmenu.d - actually though, it doesn't make much difference, because apt-getting the extras-devel version of backupmenu-n900 installs bootmenu-n900 anyway and there aren't any other files it generates.

It does back up everything though - the size of the tar depends on how much free space you've got in /home. As for it being stable, I'm not too sure, but the backup worked fine for me?

I do have a question about mtd-utils for Robbie; can we not simply download the maemo version that titan uploaded to the repository at http://maemo.org/packages/view/mtd-utils/ ? It does require liblzo2-2 which took some finding, but its deb can be downloaded from here and it seems to work fine (at least, I could create a rootfs image from the tarball, but of course I had to write to /home/user/rootfs and to /home/user/MyDocs/base.ubi.img which was then ubinize'd to /home/user/MyDocs/rootfs.img)

I suppose I should have thought about it and made my file "BackupMenu.item" instead of "backupmenu.item" so it'd overwrite and force this version instead... But I wasn't thinking.
As its just a one-line launcher in this version, I'll make my next release with two copies of that file, so it'd overwrite. At least, until I get it built for extras-devel to replace the old version.

The one in the repo works fine on 50-80% of N900s. On the others, it will backup properly, but not restore due to bad blocks on the rootfs NAND. The problem is, that version uses DD to make a byte-for-byte image, which ignores bad blocks, and OneNAND flash doesn't "hide" bad blocks, unlike MMC/SD/harddisks do.
This version copies all the files using tar, then restores those as files. Because it works in files, bad blocks aren't an issue, and you can edit the resulting images if you want(say copy files out or apply a patch before restoring).

Yea, that's what it's supposed to be. It'd work anyway, though, provided you deleted the "/etc/bootmenu.d/BackupMenu.item" file.
Yup, just make sure you can flash that rootfs image and it'll work.
(I had an odd version of mtd-utils on my desktop. It'd make images, say it was done. The images were the right size, I'd flash it... And it wouldn't mount on the N900).

I figured, though, that you'd probably have your N900 "bricked" due to a failed backup, and want to use your desktop to make the image and flash it. If you have the foresight to make the image first, that's always a good thing.

Now, eventually, I intend to both A, have an option to gzip the image, and B, an option to make a flashable image right there from BackupMenu. A would make the images smaller, but take longer. B would be useful, but take an extra 256mb of space.

Actually the image ends up around ~150mb, but I think those options would be great. Thanks for all the hard work so far, this is a really brilliant tool!

Note: Until I make sure that safe, unzipped .tar images can be backed up and restored safely, I'm not going to add those options and make things -more- complex. So, test things. Make a backup, then try to restore. If it -doesn't- work right, it either won't boot, or you won't have your apps.

hi robbie

thanks for ur reply

as u know i am a noob

so i just wanted to know how it works i understand whats the meaning of this app but now i want to know how that proces of restoring goes with tar file backup.

if i choose to restore a backup what will happen next?
do i need to type something afterwards in the xterminal to untar the backup or will the app do that part as well??

thanks in advance and i am sorry for my amature english.

waiting for ur reply

Ok, so I gave this a proper stress test last night and it worked flawlessly, barring one small thing but I doubt that's anything BackupMenu can help with - I may be mistaken though!

I backed up both rootfs and optfs using the latest Backup Menu, and created an image on the device using ubinize as described. I also exported my contacts and used the built-in backup utility to copy my communications, bookmarks etc and copied the whole MyDocs directory to PC via USB.

I then flashed the latest FIASCO image, and a modified eMMC image (with larger values for the ext3 and swap partition to make /home up to 10.5GiB and swap to 1.5GiB, leaving a MyDocs of around 18GiB). Had several issues when doing this but none related to Backup Menu so I'll leave them out (mostly me being a muppet )

After this I flashed the rootfs image I created via the -r flag, rebooted with the keyboard out to launch Backup Menu, restored the optfs tar, enabled USB host mode, copied MyDocs back and rebooted.. resulting in my system almost exactly as it was before, only with a bigger /home partition and swap. Brilliant!

The only thing missing was the power kernel, as this had been wiped when I flashed the FIASCO. However it was still installed as it had been present on rootfs/optfs, so I couldn't reinstall it. To fix this I removed it through FapMan and could then reinstall kernel-power, which then came back to life after a reboot. Is there any way Backup Menu could backup the kernel too, or is this impossible?

Thanks again for all the work Robbie, it's really an excellent utility. Oh, two more very minor points - upon reboot with the keyboard out, the ramdisk text gets mangled with whatever other text is on the left as they're on the same line, and FSCK still doesn't work. Neither of these matter a jot to me though

Hm, that's nice. Kernel wise, someone told me that it's not stored in the rootfs or emmc - It's in its own special 2MB partition. This also contains all bootloader stuff, which is why that needs to be flashed when switching to Nitdroid.
I'm not sure how I'd fix this, aside from manually loading the power kernel if it exists on disk, then flashing it internally if asked... But I think that would be more trouble than its worth, especially considering you aren't supposed to have to flash a fiasco image before restoring your backup.

FSCK, yea, its on the fix list.
And yea, there's a couple of odd lines of text. Problem is, I tried adding spacing before those lines... and for some odd reason, it wouldn't work. I'm still not sure why - the same spacing worked fine on all other lines.

BTW, would you mind posting a complete tutorial on how you got it all to work? Complete with modified eMMC image?


@Ali:
BackupMenu both creates and uses .tar images. You should be able to backup your system to your SD card or eMMC, then go right ahead and restore from those images. You should not need to mess with anything.
Note however that it's still slightly experimental, so if things don't work out right, you -may- have to mess with it. But that -shouldn't- happen.


Thanks,

-Rob

yeah I wouldn't mind a copy of that emmc image either.

@rob: been testing the new version, backup file is alot smaller,
now that your using your new method, and when i restored a backup to another device it worked flawlessly unlike the last version where it would give me errors and result in a unbootable device.
which is good to keep my second n900 up to date which all the changes i make to my primary device.

Thank you for your continued work on this. you save me hours of work restoring my n900 every time i reflash.

I'll certainly try to write up the steps required when I get chance (maybe tomorrow but if not at the weekend), missing out where I messed up due to my own stupidity though like thinking the eMMC wasn't flashing as it paused at 20%, and cancelling it - not a good idea, for anyone wanting to try it..

As for the image, I'd gladly post it but it is over 200Mb big, so it's probably easier just to show a screengrab of the bytes I changed (see attached). I can't take credit for this idea as it was DrWilken who came up with it - see this post. I just found that it's in fact possible to go over 9999 for the partition. Do please note that the filesize must remain unchanged, I simply shifted the 0D 0A bytes along, removing one 09 byte in the process, which is only a tab anyway and not needed.