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

Tigerite	2011-01-28 , 21:00
Posts: 284 \| Thanked: 320 times \| Joined on May 2010 @ Peterborough, UK	#564

Originally Posted by Tigerite

Yes, I believe that flasher doesn't like the ubinized file when it's compressed with zlib. However nandwrite isn't as fussy and just happily, well, writes the data to the mtd5 block - the reason that flash_eraseall is needed is so that the ubi controller doesn't get in a tizzy and fail to mount the device once attached.

I'll test later (to simulated NAND) if it's possible to use nandwrite with the file created via mkfs.ubifs, i.e. prior to ubinizing, if ubiupdatevol is called first. It probably won't work, but worth a try anyway.

Well, you know what? It only blinkin' well went and worked! So, that's another option now - which again, creates no dmesg entries and results in a seemingly working partition (certainly one that's mountable and has all the files, at any rate). This would need ubirmvol, ubimkvol and ubiupdatevol - but crucially only 256MiB of space (less, actually) rather than double that for the pre-ubinized and then ubinized image. It should also save on NAND flash as there's no need for flash_eraseall or even nandwrite (though I imagine ubiupdatevol is calling something similar to nandwrite behind the scenes). The script to restore the pre-ubinized image would be:

Code:

ubirmvol /dev/ubi0 -N rootfs
ubimkvol /dev/ubi0 -N rootfs -S 1986
ubiupdatevol /dev/ubi0_0 /home/user/MyDocs/systemBackups/rootfs.ubi.img

..but BackupMenu would, in this instance, need to add the date and time to the image. However there'd be no need for the ubinize.cfg file, nor ubidetach/attach as the ubi commands would require rootfs to be attached to ubi control anyway. Also none of ubirm/mk/updatevol require any additional libraries!

Oh and I've got the gnu tools installed, so very glad I didn't try the latest version yet..

Last edited by Tigerite; 2011-01-28 at 21:02.

Quote & Reply |