1308 replies to this topic

[Pedro_Newbie]

What version are you using, the plugin seeks for oe_kernel.bin and oe_rootfs.bin.
The plugin produces according the lookuptable.txt rootfs.tar.bz2 and kernel.bin
So which files are in your backup folder.

Again, please post the BackupSuite.log file

[isteric2005]

Make a backup and copy the BackupSuite.log from /tmp/
Also make a screenshot of the completed backup sequence

 

here is attached as required

ecco in allegato quanto richiesto

Attached Files

•  screenshot.jpg   107.06KB   3 downloads
•  screenshot1.jpg   44.64KB   3 downloads
•  screenshot2.jpg   36.85KB   3 downloads
•  BackupSuite.log   16.52KB   3 downloads

Edited by isteric2005, 15 January 2018 - 21:07.

[Pedro_Newbie]

I think there is a problem in identifying your H7 in the part which takes care of the restore. Persian Prince could take a look in the part

def showparameterlist(self):

at the lines 349 and further and 383 and further
The backup seems fine and no errors are found in the process

[Persian Prince]

Thanks Pedro

 

It seems his box detected as another box instead of h7 in plugin.py which is weird, I did update the plugin hope to fix the problem

 

Please use latest version from develop: https://github.com/p...ros/BackupSuite

[Persian Prince]

First attachment is the normal version compiled from latest sources.

 

And the next two are the test versions for mmc support, Please test mmc versions as I can't.

 

Let me know if it works ...

 

These are zipped files so copy the contents using a FTP program like FileZilla

Edited by Persian Prince, 16 January 2018 - 11:54.

[sergiodi]

On H7 C I tried to replace via FTP the first 2 changes
The backup ends with the creation of a zgemma folder
Restore using the fat32 key and the zgemma folder does not work.
Restore with the blue backupsuite button appears to work, but on reboot the box dies with "boot" on the display.

Nothing seems changed, I'm sorry.

Edited by sergiodi, 16 January 2018 - 19:41.

[isteric2005]

I confirm what has already been reported.

The backup upload procedure is performed differently than before it did not start.

However, the result is a decoder stuck to the reboot with the wording on the boot display

 

confermo quanto già segnalato.

La procedura di caricamento del backup viene eseguita diversamente da prima che non partiva.

Il risultato però è di decoder bloccato al reboot con la dicitura sul display boot

Attached Files

•  screenshot.jpg   107.08KB   1 downloads
•  screenshot1.jpg   59.03KB   1 downloads
•  screenshot2.jpg   104.08KB   1 downloads

Edited by isteric2005, 16 January 2018 - 20:41.

[Persian Prince]

Ok it seems the plugin won't show .tar.bz2 files for you, Please use this new plugin.py: https://raw.githubus...lugin/plugin.py

First remove the "plugin.pyo" in your STB then overwrite and reboot.

[sergiodi]

I diligently followed the instructions by deleting the file.pyo and overwriting the new file.py, but the result does not change.
Backup ok
With restore of backup with backupsuite blue button the box to reboot dies
With the restore of the backup with usb the box ignores the folder

 

However, I thank you for the attempt.

[sergiodi]

I don't know if what was written could serve.

 

On zgemma h7 I installed OpenAtv 6.2 and with backupsuite I performed a full backup.
Then I installed Openpli 6.1 and with backupsuite I perfectly restored the total backup done with OpenAtv.
In fact, the box has restarted with the OpenAtv 6.2 on board.

 

I gather that the problem to be solved is the preparation of total backup because the restore is ok

Edited by sergiodi, 17 January 2018 - 21:14.

[Persian Prince]

So BackupSuite works on ATV and restores correctly on PLi right?
It means it can not do the corrrct backup on PLi for h7 ...
We need to fix this and maybe it's binary related.

Edited by Persian Prince, 17 January 2018 - 21:39.

[isteric2005]

 

I hope that someone from the team verify this situation ... it's a real shame I can not use this great plugin in combination with openpli and H7

 

spero che qualcuno del team verifichi questa situazione ....è un vero peccato non poter utilizzare questo ottimo plugin in abbinamento a openpli ed H7

[sergiodi]

So BackupSuite works on ATV and restores correctly on PLi right?
It means it can not do the corrrct backup on PLi for h7 ...
We need to fix this and maybe it's binary related.

Of course.

You understand perfectly: with box H7 + openpli 6.1 you can restore an openAtv full backup.

[Persian Prince]

Don't worry with the help of each other we will fix this, It takes time but I think it's not just h7 and it effecta tar.bz2 images ...

[sergiodi]

Don't worry with the help of each other we will fix this, It takes time but I think it's not just h7 and it effecta tar.bz2 images ...

Fine!

[Pedro_Newbie]

The following comes to my attention:
When dumping the kernel the kernelsize is 3 MB, it seems rather small
and
on what place is the kernel, the backupsuite.sh assumes now on /dev/mmcblk0p1 but is this the case?

 

Maybe there should be looked at the part (from line 344 in the backupsuite.sh)

    if [ $SEARCH = "hd51" ] ; then
        python /usr/lib/enigma2/python/Plugins/Extensions/BackupSuite/findkerneldevice.py
        KERNEL=`cat /sys/firmware/devicetree/base/chosen/kerneldev`
        KERNELNAME=${KERNEL:11:7}.bin
        echo "$KERNELNAME = STARTUP_${KERNEL:17:1}"
        log "$KERNELNAME = STARTUP_${KERNEL:17:1}"
        dd if=/dev/kernel of=$WORKDIR/$KERNELNAME > /dev/null 2>&1
    elif [ $SEARCH = "sf4008" -o $SEARCH = "et11000" ] ; then
        dd if=/dev/mmcblk0p3 of=$WORKDIR/$KERNELNAME
        log "Kernel resides on /dev/mmcblk0p3"
    else
        dd if=/dev/mmcblk0p1 of=$WORKDIR/$KERNELNAME
        log "Kernel resides on /dev/mmcblk0p1"
    fi

Maybe the part

        python /usr/lib/enigma2/python/Plugins/Extensions/BackupSuite/findkerneldevice.py
        KERNEL=`cat /sys/firmware/devicetree/base/chosen/kerneldev`

can be used to determine the kernel part?

Edited by Pedro_Newbie, 18 January 2018 - 17:50.

[Persian Prince]

Well done Pedro
Soon I will update the shell scripts and let you know to test again

[Persian Prince]

Maybe I change the lookuptable.txt structure and add a new section "Kernel-MTD" with correct values for all

[betacentauri]

Problem is that the box afaik has the same multiboot feature as the hd51. So you don't have 1 kernel partition. You have 4. I guess findkerneldevice.py or similar is the way to go to find out which MMC kernel partition is used from current running image.

[Persian Prince]

Ok I will take a look at it soon