[VU+ Ultimo4K] Image Backups

[lincsat]

Having recently updated to a self-built 6.0.008 build, I notice the ViX Image manager isn't displaying my image backups. With some experimentation, it only displays files that end -

release-vuultimo4k_usb.zip

The images created by the image manager are in the format

PREFIX-release-BUILD-DATE_TIME.zip

So, as an example a backed-up image (with my prefix) would have the name -

ViX-Ultimo4K-release-6.0.008-20220216_175143.zip

That is NOT displayed, but does display if I change the name to -

ViX-Ultimo4K-release-6.0.008-20220216_175143.release-vuultimo4k_usb.zip

or anything ending -

release-vuultimo4k_usb.zip

 

[Huevos]

In the current code the machine name is required to display a file. As far as I remember only the prefix is custom. The machine name is always present in image backups created by our system.

 

[birdman]

In the current code the machine name is required to display a file. I am going to look into this. As far as I remember only the prefix is custom. The machine name is always present in image backups created by our system.

Isn't this a problem if you have a multiboot system? It would mean you'd never find an image to restore from a different distro if they don't do the same.

And whereas it might be the case for built images, it isn't (or wasn't) the case for ImageManager ones.

The one I have is:

myimage-developer-6.0.007.001-20220114_180236.zip
​

no sign of "et8000" in that.

 

[lincsat]

I've just removed my custom prefix and the backup has the name -

openvix-vuultimo4k-release-6.0.008-20220216_183053.zip

This can be viewed, so looks like the problem is that adding a custom prefix removes the machine name from the file name

 

[ccs]

Ultimo4K, standard prefixes.

It's working ok for me running 6.0.008.005 (Dev).

I've just flashed 6.0.008.006 (Dev) for the first time and it's ok as well.

-rw-r--r--    1 root     root     120947844 Feb  9 14:09 openvix-vuultimo4k-developer-6.0.008.005-20220209_140647.zip
-rw-r--r--    1 root     root     130252533 Feb  9 19:35 openvix-6.1.000.000.developer-vuultimo4k_usb.zip
-rw-r--r--    1 root     root     121764264 Feb  9 20:00 openvix-vuultimo4k-developer-6.1.000.000-20220209_195653.zip
-rw-r--r--    1 root     root     121770256 Feb 10 15:44 openvix-vuultimo4k-developer-6.1.000.000-20220210_154143.zip
-rw-r--r--    1 root     root     129392668 Feb 10 18:52 openvix-6.0.008.006.developer-vuultimo4k_usb.zip
-rw-r--r--    1 root     root     121761677 Feb 16 10:07 openvix-vuultimo4k-developer-6.1.000.000-20220216_100437.zip
-rw-r--r--    1 root     root     120758338 Feb 16 18:51 openvix-vuultimo4k-developer-6.0.008.006-20220216_184833.zip
root@vuultimo4k:/media/hdd/imagebackups#

 

[Huevos]

Isn't this a problem if you have a multiboot system? It would mean you'd never find an image to restore from a different distro if they don't do the same.

And whereas it might be the case for built images, it isn't (or wasn't) the case for ImageManager ones.

The one I have is:

myimage-developer-6.0.007.001-20220114_180236.zip
​

no sign of "et8000" in that.

Why does that file not contain the machine name? How was it created?

Please tell me which distro does not contain the machine name in the filename.

 

[Huevos]

All OE-A distros and OpenPLi contain ${MACHINEBUILD} in IMAGE_NAME.

OpenPLi, OpenATV and OpenBH filter the image file in their respective versions of ImageManager checking that the filename contains ${MACHINEBUILD}.

OpenViX image files created by ImageManager have always contained ${MACHINEBUILD}.

So where is the problem? Are people now just giving their image files random names?

 

[lincsat]

In my case, I set the prefix as ViX-Ultimo4K in the image manager menu, it then created the backup with that and didn't add vuultimo4k

 

[birdman]

OpenViX image files created by ImageManager have always contained ${MACHINEBUILD}.

So where is the problem? Are people now just giving their image files random names?

No. I set a prefix (so I know that I created it) and that is what ImageManager creates.
So, clearly, ImageManager does not put ${MACHINEBUILD} in the name.

I have a vague memory of a discussion a year or so ago about these names. If you put everything in the name becomes so long that various "important" parts of the name don't get displayed in the GUI list.

 

[birdman]

The code in ImageManager.py (so, easy to actually check) has:

defaultprefix = getImageDistro() + "-" + getBoxType()

config.imagemanager.folderprefix = ConfigText(default=defaultprefix, fixed_size=False)

        def keySave(self): 
                if config.imagemanager.folderprefix.value == "": 
                        config.imagemanager.folderprefix.value = defaultprefix

The default prefix contains getBoxType(), but this is configurable and allows you to put anything you wish into it.

My settings contain:

 config.imagemanager.folderprefix=myimage

EDIT:
The BackupManager.py code contains code to check that "vix" is in the prefix, and if not treats it as a tag.
Which might have been what I remember being discussed.
Further EDIT:
Actually two years ago. This was the commit:

https://github.com/OpenViX/vix-core/commit/fb10c855362b47ae551c53fffd726a610ba06ded

and this was the discussion thread (link is to the PR submission near the end of the thread):

https://www.world-of-satellite.com/showthread.php?62084-Problems-with-backup-and-restore&p=491346&viewfull=1#post491346

 

[alexwilmac]

I frankly think that what happened after last updates, that the image does not list full backups if the option that allows user to customize its filenames is changed, has no logic: if an option exists it must be possible to use otherwise, if it causes issues, like in this case, just simply remove it.
But it's very comfortable to customize it. If the problem is that NOW (before it was not a problem) it must contain also some compulsory parts, well.. just let us customize what is possible to customize and then automatically add the rest.
I repeat, an option that is not possible to use is not an option.

 

[Huevos]

I frankly think that what happened after last updates, that the image does not list full backups if the option that allows user to customize its filenames is changed, has no logic: if an option exists it must be possible to use otherwise, if it causes issues, like in this case, just simply remove it.
But it's very comfortable to customize it. If the problem is that NOW (before it was not a problem) it must contain also some compulsory parts, well.. just let us customize what is possible to customize and then automatically add the rest.
I repeat, an option that is not possible to use is not an option.

The model name is now mandatory so if your filenames don't contain this you will have to modify them. In the current code the model name is added automatically.

 

[lincsat]

In the current code the model name is added automatically.

In my case it wasn't. I've changed the backup prefix in the Image manager now so I can see backups again

 

[Huevos]

In my case it wasn't. I've changed the backup prefix in the Image manager now so I can see backups again

In the current code it is added automatically.

 

[lincsat]

In the current code it is added automatically.

Sorry, didn't realize you meant it had just been updated

 

[Huevos]

I updated it yesterday morning. If people report bugs we try to fix them as quick as possible. Getting into the current image takes longer as that requires a rebuild.

 

[alexwilmac]

OK but, as someone has told me: "I don't see the reason to remove the prefix...", well... there are two errors in this: one is the obvious we said above, that a user can't know he's travelling on a mined camp changing an innocuous option.

The second is that Image manager, before this last update, had always ADDED the box and image to the file name, just to distinguish the backups when saved from many boxes! I also use a NAS and I need to distinguish my four boxes' backups.

Now, instead, the bug is just this: you change the option and this you choose is the filename.
But, in case... what? it's a user problem: why not to show in the backup list?
It's absurd: image manager doesn't add the compulsory part and then "blames" the user for this mistake, not showing the saved backups!

 

[twol]

OK but, as someone has told me: "I don't see the reason to remove the prefix...", well... there are two errors in this: one is the obvious we said above, that a user can't know he's travelling on a mined camp changing an innocuous option.

The second is that Image manager, before this last update, had always ADDED the box and image to the file name, just to distinguish the backups when saved from many boxes! I also use a NAS and I need to distinguish my four boxes' backups.

Now, instead, the bug is just this: you change the option and this you choose is the filename.
But, in case... what? it's a user problem: why not to show in the backup list?
It's absurd: image manager doesn't add the compulsory part and then "blames" the user for this mistake, not showing the saved backups!

Post an example . The new code forces the boxname into the filename so its identified, the prefix is either now openvix or user defined….. so I don,t understand your issue

 

[ccs]

Before 008, user defined prefixes were seen in image manager (prefix=xxx).
In 008, user defined prefixes could be used to create a backup, but were not seen in image manager (prefix xxx).

In this commit, mentioned earlier, the model name is a mandatory part of the filename, and is visible in image manager with a user defined prefix (yyy).

https://github.com/OpenViX/vix-core/commit/3ecf01aeed2b2e6fe906a028aab195516a54dc90

Note: prefix xxx will still not be seen (post #12).

-rw-r--r--    1 root     root     121746903 Feb 20 10:54 xxx-developer-6.1.000.000-20220220_105105.zip

-rw-r--r--    1 root     root     121809508 Feb 20 11:17 yyy-vuultimo4k-developer-6.1.000.000-20220220_111407.zip

 

[twol]

So this is current ImageManager setup - attached is a screenshot showing a backup with default prefix and a test with user defined prefix.(ignore my non-standard release version identifiers)

Both show in the ImageManager list - so do not see any issue.