BackupSuite
Re: BackupSuite #81
Posted 18 January 2013 - 20:03
But I'm not sure if I can distribute the new version because of the problem Jooe is suffering.
Is there anybody who can confirm this problem?
Satkiekerd had no problem restoring the image.
Is one of the Dev's able to comment on this issue, what is going wrong or what am I doing wrong?
Re: BackupSuite #82
Re: BackupSuite #83
Re: BackupSuite #84
Posted 19 January 2013 - 06:10
First of all: the kernel isn't too big. I made backups of the Solo2 from several images, and all my kernels are 7.340.032 bytes.I have some troubles with solo2 backup
First kernel_cfe_auto.bin is too big (7.34MB)
I was restore backuped image, but now I can't flash my box with any other image, it's show on display that all Is Ok (reading/erasing/programming/update), but after reboot I always have my restored from backup image in my box
Any idea how I can flash it with original (or any other) image?
Secondly: The Solo2 also flashes from the internal HDD. That means that if a flashable image is present on the HDD (wich will be the case using the backup suite) the box will flash that image (even though the VFD reports to be reading USB).
I flashed and restored numerous images (including PLi using the backup suite) and found no problems in this area.
Re: BackupSuite #85
Posted 19 January 2013 - 09:04
First of all: the kernel isn't too big. I made backups of the Solo2 from several images, and all my kernels are 7.340.032 bytes.
I have some troubles with solo2 backup
First kernel_cfe_auto.bin is too big (7.34MB)
I was restore backuped image, but now I can't flash my box with any other image, it's show on display that all Is Ok (reading/erasing/programming/update), but after reboot I always have my restored from backup image in my box
Any idea how I can flash it with original (or any other) image?
Secondly: The Solo2 also flashes from the internal HDD. That means that if a flashable image is present on the HDD (wich will be the case using the backup suite) the box will flash that image (even though the VFD reports to be reading USB).
I flashed and restored numerous images (including PLi using the backup suite) and found no problems in this area.
U are absolutely right. Thanks a lot for info.
It was hard to imagine that such a conflict is possible, on my Vu + Ultimo this problem never existed.
vuplus folder with backup files created by Backupsuite on hdd was a problem. After delete it from hdd, my fox was flashed without any problem.
Just a note for info:
Also, if the vuplus folder on the USB have some missing from vuplus folder on HDD files (f.e. initrd_cfe_auto.bin, splash_cfe_auto.bin) during upgrade, missed files installs from USB, and kernel with image binary from hdd
@Pedro_Newbie
Maybe it's better do not create an extra vuplus folder on /hdd for vu+solo2 using Your Backupsuite?
Re: BackupSuite #86
Posted 19 January 2013 - 09:10
The box flashes fine without the initrd-file. As far as I know nobody knows why that file would be needed for a backup (or any other flash).Just a note for info:
Also, if the vuplus folder on the USB have some missing from vuplus folder on HDD files (f.e. initrd_cfe_auto.bin, splash_cfe_auto.bin) during upgrade, missed files installs from USB, and kernel with image binary from hdd
Re: BackupSuite #87
Posted 19 January 2013 - 16:40
@Pedro_Newbie
Maybe it's better do not create an extra vuplus folder on /hdd for vu+solo2 using Your Backupsuite?
Why not, if you don't want it on your HDD you'll have to choose for the USB only option.
I think there are plenty Solo2 users who like the ability to flash from the last working back-up from harddisk.
I'm glad there is no big f*ck up with the BackupSuite.
Here's the last version with the correct naming of the root_cfe_auto.bin.
All thanks for testing!
Attached Files
Re: BackupSuite #88
Posted 18 February 2013 - 12:05
PLS fix !!!
Edited by vu+uno, 18 February 2013 - 12:09.
Vu+Uno > OpenPLi-3.0-beta > Wicardd-1.14
Re: BackupSuite #89
Re: BackupSuite #90
Re: BackupSuite #91
Re: BackupSuite #92
Posted 18 February 2013 - 19:31
As far as I know if you place an USB-stick with an image and restart your receiver then the image on the HDD is used to flash.so lets say i ever wanna restore the backuo thats located on my harddisk duo + solo2
how i would then start restoring from the harddisk?
I saw that at VU+ they made a commit with the description:
fix update problem(solo2:skip HDD when checking update file)
So I don't know if it is fixed (and if so if it is only for the OI)
Re: BackupSuite #93
Re: BackupSuite #94
Posted 19 February 2013 - 09:11
hi @Pedro,Are you sure that 11.8 does not work correct, because between 11.7 and 11.8 there are no big differences.
I will try to look into it tonight or tomorrow night.
Are there any other users experiencing this problem?
didn't test it myself on my duo, but on another forum I saw several complaints concerning an unbootable /?/ or 'freezing after some time after restoring' backup made with 11.9 version (for ultimo), so it looks like a general issue...
and concerning your dutch section question:
http://openpli.org/f...fs-f-parameter/
I think you might be onto something...
What is the the purpose of the -F (--space-fixup) mkfs.ubifs option?
Because of subtle ECC errors that can arise when programming NAND flash (see here), ubiformat is the recommended way of flashing a UBI image which contains a UBIFS file system. However, this is not always possible - for example, some embedded devices are manufactured using an industrial NAND flash programmer which has no knowledge of UBI or UBIFS.
The -F option causes mkfs.ubifs to set a special flag in the superblock, which triggers a "free space fixup" procedure in the kernel the very first time the filesystem is mounted. This fixup procedure involves finding all empty pages in the UBIFS file system and re-erasing them. This ensures that NAND pages which contain all 0xFF data get fully erased, which removes any problematic non-0xFF data from their OOB areas.
Of course it is not possible to re-erase individual NAND pages, and entire PEBs are erased. UBIFS performs this procedure by reading the useful (non 0xFF'ed) contents of LEBs and then invoking the atomic LEB change UBI operation. Obviously, this means that UBIFS has to read and write a lot of LEBs which takes time. But this happens only once, and the "free space fixup" procedure then unsets the "fixup" UBIFS superblock flag.
This option is supported if you are running a kernel version 3.0 or higher, or if you have pulled the changes from a UBIFS back-port tree. Note that ubiformat is still the preferred flashing method if the image is not being flashed for the first time, since it preserves existing erase counters (while using nandwrite or its equivalent does not).
Re: BackupSuite #95
Posted 19 February 2013 - 09:17
I also had a few issues with the restore of images made with 11.9
Re: BackupSuite #96
Re: BackupSuite #97
Re: BackupSuite #98
Re: BackupSuite #99
Re: BackupSuite #100
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users