Testers required for OpenViX Python 3 images

ccs · Jul 15, 2021

5.5.013.016 works ok.

ccs · Jul 16, 2021

5.5.014.004...

Code:

root@vuultimo4k:~# opkg list-installed| grep nfs
nfs-utils - [COLOR="#FF0000"]2.5.4-r1[/COLOR]
nfs-utils-client - [COLOR="#FF0000"]2.5.4-r1[/COLOR]
packagegroup-base-nfs - 1.0-r83
root@vuultimo4k:~#

5.5.013.016...

Code:

root@vuultimo4k:~# opkg list-installed | grep nfs
nfs-utils - [COLOR="#FF0000"]2.5.3-r1[/COLOR]
nfs-utils-client - [COLOR="#FF0000"]2.5.3-r1[/COLOR]
packagegroup-base-nfs - 1.0-r83
root@vuultimo4k:~#

ccs · Jul 16, 2021

Code:

https://bugzilla.redhat.com/show_bug.cgi?id=1979816

BrokenUnusableAccount · Jul 16, 2021

ccs said:
Code:

https://bugzilla.redhat.com/show_bug.cgi?id=1979816

Good detective work.

white_westie · Jul 16, 2021

As expected nfs server is broken on P3 version, client works okay.
Manual mount or 'showmount -e 1.2.3.4' returns a 'connection error'
I see @ccs has found the source - well done.

Ran into a problem with 'restore settings' on the 5.5.014.004, and surprisingly with 5.5.013.016
Getting a message about "Sorry, but the file is not compatible with this image version."
Anyone getting this, or have I missed something?

Just looked at the code in BackupManager.py on my box, and I do not understand how it has ever worked!`

Code:

        def keyResstore(self):
                self.sel = self["list"].getCurrent()
            
                        if self.sel:
                                if path.exists("/tmp/ExtraInstalledPlugins"):
                                        remove("/tmp/ExtraInstalledPlugins")
                                if path.exists("/tmp/backupkernelversion"):
                                        remove("/tmp/backupkernelversion")
[B]                                self.Console.ePopen("tar -xzvf "  + self.BackupDirectory + self.sel + " tmp/ExtraInstalledPlugins tmp/backupkernelversion tmp/backupimageversion -C /", self.settingsRestoreCheck)
[/B]                        else:
                                self.session.open(MessageBox, _("There is no backup to restore."), MessageBox.TYPE_INFO, timeout=10)
                else:
                        self.session.open(MessageBox, _("Backup in progress,\nPlease wait for it to finish, before trying again."), MessageBox.TYPE_INFO, timeout=10)

        def settingsRestoreCheck(self, result, retval, extra_args=None):
[B]                if path.exists("/tmp/backupimageversion"):
                        with open("/tmp/backupimageversion", "r") as fd:
                                imageversion = fd.read()
[/B]                        print("[BackupManager] Backup Image:", imageversion)
                        print("[BackupManager] Current Image:", about.getVersionString())
                        if imageversion == about.getVersionString() or isRestorableSettings(imageversion): 
                                print("[BackupManager] Stage 1: Image ver OK")
                                self.keyResstore1()
                        else:
                                self.session.open(MessageBox, _("Sorry, but the file is not compatible with this image version."), MessageBox.TYPE_INFO, timeout=10)
                else:
                        self.session.open(MessageBox, _("Sorry, but the file is not compatible with this image version."), MessageBox.TYPE_INFO, timeout=10)

The 'tar -xzvf...." command is extracting 3 files from the tmp directory from the .gz file, and looks like they should go to the '/' directory.
That's not what happens - as the backup was created using relative filenames, the files will be restored into the current directory - which is the root users home dir, so they end up in '/home/root/tmp'.

In the next section, the code is checking using absolute filenames - '/tmp/backupimageversion', and of course finds nothing, hence the error.

I don't know where the git for the code is, so cannot see if this changed recently!
Dont see any reports of this listed, and I assume ye guys at the coldface, use the settings backup/restore function in the images, so would have noticed!
Could this be only specific to the GigaBlue builds?

WW

ccs · Jul 16, 2021

"tar -xzvf " + self.BackupDirectory + self.sel + " tmp/ExtraInstalledPlugins tmp/backupkernelversion tmp/backupimageversion -C /"

The -C option puts them in / if my limited unix knowledge is correct.

I always restore settings after flashing and never see the problem you describe.

white_westie · Jul 16, 2021

more info

ccs said:
"tar -xzvf " + self.BackupDirectory + self.sel + " tmp/ExtraInstalledPlugins tmp/backupkernelversion tmp/backupimageversion -C /"

The -C option puts them in / if my limited unix knowledge is correct.

I always restore settings after flashing and never see the problem you describe.

Never seen it before, but you are correct - the '-C' should do a cd to the dir before executing the main command.
However not working on my box - files not extracted to '/' but to '/home/root/tmp' - verified using find command after getting message on screen.
[STRIKE]Wonder is it something to do with the Console command or something.[/STRIKE]

This is what happens for me

Code:

root@gbue4k:/media/hdd/backup/tt# tar -xzvf ./z1.tar.gz tmp/backupimageversion -C /
tmp/backupimageversion

root@gbue4k:/media/hdd/backup/tt# ls -l tmp/backupimageversion
-rw-r--r--    1 root     root             3 Jul 15 22:29 backupimageversion

root@gbue4k:/media/hdd/backup/tt# ls -l /tmp/backupimageversion
ls: /tmp/backupimageversion: No such file or directory

white_westie · Jul 16, 2021

Think I found the issue!!

In the P2 version, the tar command is built into busybox, and the syntax in the code works.
In the P3 version, the tar command is from GNU Version 1.30, with possible syntax change.

Code:

root@gbue4k:/media/hdd/backup/tt# ls -l /tmp/backupimageversion tmp/backupimageversion
ls: /tmp/backupimageversion: No such file or directory
ls: tmp/backupimageversion: No such file or directory

root@gbue4k:/media/hdd/backup/tt# [B]tar -C / -xzvf ./z1.tar.gz tmp/backupimageversion[/B]
tmp/backupimageversion

root@gbue4k:/media/hdd/backup/tt# ls -l /tmp/backupimageversion tmp/backupimageversion
ls: tmp/backupimageversion: No such file or directory
-rw-r--r--    1 root     root             3 Jul 15 22:29 /tmp/backupimageversion

Looks like parameter position is important now!
Does that make sense ?

Code:

tar -xzvf ./z1.tar.gz tmp/backupimageversion -C /           <<<< does not work
tar -C / -xzvf ./z1.tar.gz tmp/backupimageversion           <<<< works

Maybe when extracting you have to use the '-C dir' option before defining the other actions, whereas you use it at the end of the command, when creating a tar!

Joe_90 · Jul 17, 2021

white_westie said:
...

Ran into a problem with 'restore settings' on the 5.5.014.004, and surprisingly with 5.5.013.016
Getting a message about "Sorry, but the file is not compatible with this image version."
Anyone getting this, or have I missed something?

Just looked at the code in BackupManager.py on my box, and I do not understand how it has ever worked!`

The first time I flashed a 5.5 image, it offered to restore a backup, but then I got that exact message when I selected a 5.4 backup file. I ended up not restoring and set up from scratch.

Huevos · Jul 17, 2021

@white_westie, Have you tested this in the file? Will need testing in Py2 and Py3?

Huevos · Jul 17, 2021

Joe_90 said:
The first time I flashed a 5.5 image, it offered to restore a backup, but then I got that exact message when I selected a 5.4 backup file. I ended up not restoring and set up from scratch.

I don't understand this. I just tried 5.3 and 5.4 backups and they work. Should be able to restore any backup from 4.2 onwards.
https://github.com/OpenViX/vix-core/blob/master/src/BackupManager.py#L74

white_westie · Jul 17, 2021

Huevos said:
@white_westie, Have you tested this in the file? Will need testing in Py2 and Py3?

Yes, works perfectly on P2 version - it uses busybox tar, whereas P3 version uses GNU tar!

I just fresh flashed 5.5.014.004 again, and ANY settings backup I select I get the incompatibly message, either from the initial restore wizard, or a manual restore.

Just for reference, the z1.tar.gz file I referenced for my test is just a renamed settings file!

white_westie · Jul 17, 2021

Huevos said:
I don't understand this. I just tried 5.3 and 5.4 backups and they work. Should be able to restore any backup from 4.2 onwards.
https://github.com/OpenViX/vix-core/blob/master/src/BackupManager.py#L74

Fully agree with you - it should work!
Its not an actual compatibility issue as such, the code initially restores 3 files to /tmp, then it checks the image version by comparing the contents of the backupimageversion file to the actual image version, if they match it attempts to restore. In my case the file is not restored to /tmp, so the comparison check fails and I get the compatibility message.

Any idea when GNU tar was introduced to the images?

ccs · Jul 17, 2021

white_westie said:
Yes, works perfectly on P2 version - it uses busybox tar, whereas P3 version uses GNU tar!

How do you work that out, this is what I get (2 different boxes with slightly different usage lines)....

P3

Code:

root@vuultimo4k:~# which tar
/bin/tar
root@vuultimo4k:~# ls -l /bin/tar
lrwxrwxrwx    1 root     root            19 Jul 16 09:12 /bin/tar -> /bin/busybox.nosuid
root@vuultimo4k:~# tar
BusyBox v1.33.1 (2021-07-10 12:00:30 UTC) multi-call binary.

Usage: tar c|x|t [-ZzJjahvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [OPTION]... [FILE]...

Create, extract, or list files from a tar file

P2

Code:

root@et10000:~# which tar
/bin/tar
root@et10000:~# ls -l /bin/tar
lrwxrwxrwx    1 root     root            19 Jun 24 17:18 /bin/tar -> /bin/busybox.nosuid
root@et10000:~# tar
BusyBox v1.31.0 (2021-05-18 20:24:21 UTC) multi-call binary.

Usage: tar c|x|t [-ZzJjahvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [--exclude PATTERN]... [FILE]...

Create, extract, or list files from a tar file

ccs · Jul 17, 2021

Huevos said:
I don't understand this. I just tried 5.3 and 5.4 backups and they work. Should be able to restore any backup from 4.2 onwards.
https://github.com/OpenViX/vix-core/blob/master/src/BackupManager.py#L74

I've just flashed 5.5.014 and used a settings backup from 5.4.007 (release) and it worked fine.

twol · Jul 17, 2021

I can confirm that changing that parameter's position in the tar does work and it restores setting ... unfortunately it doesn't restore plugins so need to find out why that doesn't work (and I changed the -C on that as well)
Its a pain, I have to crash the wizard to get dumps and information ... takes time.

twol · Jul 17, 2021

Ok - that change all works (I had left a hook in the wizard)
I will post the changes later if not done before by someone

Thanks White_Westie!!

I am assuming it will be backward compatible!

white_westie · Jul 17, 2021

ccs said:

How do you work that out, this is what I get (2 different boxes with slightly different usage lines)....

P3

Code:

root@vuultimo4k:~# which tar
/bin/tar
root@vuultimo4k:~# ls -l /bin/tar
lrwxrwxrwx    1 root     root            19 Jul 16 09:12 /bin/tar -> /bin/busybox.nosuid
root@vuultimo4k:~# tar
BusyBox v1.33.1 (2021-07-10 12:00:30 UTC) multi-call binary.

Usage: tar c|x|t [-ZzJjahvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [OPTION]... [FILE]...

Create, extract, or list files from a tar file

P2

Code:

root@et10000:~# which tar
/bin/tar
root@et10000:~# ls -l /bin/tar
lrwxrwxrwx    1 root     root            19 Jun 24 17:18 /bin/tar -> /bin/busybox.nosuid
root@et10000:~# tar
BusyBox v1.31.0 (2021-05-18 20:24:21 UTC) multi-call binary.

Usage: tar c|x|t [-ZzJjahvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [--exclude PATTERN]... [FILE]...

Create, extract, or list files from a tar file

The joys of linux...

P2 (et8000) tar is busybox

P3 Gigablue UE

Code:

root@gbue4k:~# which tar
/bin/tar
root@gbue4k:~# ls -l /bin/tar
lrwxrwxrwx    1 root     root            12 Jul 17 08:22 /bin/tar -> /bin/tar.tar
root@gbue4k:~# tar --version
tar (GNU tar) 1.30
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

ccs · Jul 17, 2021

So it's down to the boxes we're using.

white_westie · Jul 17, 2021

ccs said:
So it's down to the boxes we're using.

No its not the boxes, it's what sources are being used for the builds.
Think it might be down to the fact that the guys building/hosting the images are using their own servers, so probably their own sources as well.
Given that this is alpha/beta testing, then things might be different.

Speaking of sources, is the update to P3 a cross team approach?
Is there a public GIT for the P3 build for VIX?
Also, going forward, will the python source files be part of the finished build, or is that just a temp thing during testing?

Testers required for OpenViX Python 3 images

ViX Beta Tester

ViX Beta Tester

ViX Beta Tester

BrokenUnusableAccount

Guest

Forum Supporter

ViX Beta Tester

Forum Supporter

Forum Supporter

Moderator

Administrator

Administrator

Forum Supporter

Forum Supporter

ViX Beta Tester

ViX Beta Tester

Moderator

Moderator

Forum Supporter

ViX Beta Tester

Forum Supporter

Similar threads

OpenViX Feeds Status