View Single Post
Posts: 284 | Thanked: 320 times | Joined on May 2010 @ Peterborough, UK
#556
Originally Posted by RobbieThe1st View Post
Tigerite, I'll look at your code tonight. Do you have a set of commands/options that you've gotten working? (i.e. what commands, options, and order you need to produce a valid file)
Yep, I've got some scripts that I've successfully run chrooted. Backup is quite straightforward:

Code:
mkfs.ubifs -x zlib -g 0 -m 2048 -e 129024 -c 2047 -R 4MiB -r /tmp/mnt/rootfs -v /home/user/MyDocs/systemBackups/rootfs.ubi.img
Naturally, replace zlib with lzo for that option and /tmp/mnt/rootfs to wherever the rootfs partition is mounted. Then ubinize that image:

Code:
ubinize -o /home/user/MyDocs/systemBackups/rootfs.zlib.img ubinize.cfg -m 2048 -p 128KiB -s 512
rm /home/user/MyDocs/systemBackups/rootfs.ubi.img
The zlib here is of course optional, I just use it to distinguish between zlibbed and lzo'd images. BackupMenu would need to add the date stamp too, but as these are just my testing, I didn't bother; the ubinize.cfg is the standard one posted previously, with /home/user/MyDocs/systemBackups/rootfs.ubi.img in the image parameter. This can stay without any date/time as it's only a temporary image anyway.

Then for restore:

Code:
flash_eraseall /dev/mtd5
nandwrite -q /dev/mtd5 /home/user/MyDocs/systemBackups/rootfs.zlib.img
This assumes that the rootfs partition is at mtd5, I can't imagine it would ever be anywhere else, but perhaps some sanity check to be completely sure. Again the rootfs.zlib.img would need a date/time for BackupMenu. I also think doing a ubidetach prior to flash_eraseall and nandwrite, then ubiattach afterwards, would be safer; the rootfs partition should be umounted too:

Code:
ubidetach /dev/ubi_ctrl -m 5
...
ubiattach /dev/ubi_ctrl -m 5
Neither ubiattach/detach need new libraries, just the standard libc and linux.

Hope this helps

Last edited by Tigerite; 2011-01-28 at 09:11.
 

The Following 2 Users Say Thank You to Tigerite For This Useful Post: