View Full Version : [VU+ Ultimo4K] Image Backups
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
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.
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.
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
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#
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.
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?
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
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.
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
18-02-22, 09:54
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.
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.
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
In my case it wasn't. I've changed the backup prefix in the Image manager now so I can see backups againIn the current code it is added automatically.
In the current code it is added automatically.
Sorry, didn't realize you meant it had just been updated
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
20-02-22, 10:56
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!
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
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
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.
So this is current ImageManager setup ....OpenVix 7.1.7103F! Current?
OpenVix 7.1.7103F! Current?
Don't worry about that, it is a personal build.
It is pretty easy. In ImageManager.py you set the default prefix in row 50
In the current version you have change the
defaultprefix = getImageDistro() + "-" + getMachineName()
To
defaultprefix = getImageDistro()
So when a user is renaming the backup to lets say. my-latest the Machine Name is removed and of cause the Backup image is not showing.
Machine Name is used to identify the correct image for your Machine. So you want restore the wrong image.
If you chage back to
defaultprefix = getImageDistro() + "-" + getMachineName()
All works just fine.
Of cause there are other solutions to identify and add the machine name. But at the moment they really don't work proper
At least not for Vu+
It is pretty easy. In ImageManager.py you set the default prefix in row 50
In the current version you have change the
defaultprefix = getImageDistro() + "-" + getMachineName()
To
defaultprefix = getImageDistro()
So when a user is renaming the backup to lets say. my-latest the Machine Name is removed and of cause the Backup image is not showing.
Machine Name is used to identify the correct image for your Machine. So you want restore the wrong image.
If you chage back to
defaultprefix = getImageDistro() + "-" + getMachineName()
All works just fine.
Of cause there are other solutions to identify and add the machine name. But at the moment they really don't work proper
At least not for Vu+
So the machinename is no longer in the prefix - so that cannot happen anymore plus why would you not use the menu key to bring up the options and change teh default prefix?….
Don't understand your answer ..... If I open menu and add my personal prefix the machine name is also removed. Only Image distro and date.
How will the ImageManager now that my backup image suits my Machine when there is no machine name in tha backup image?
I assume that the machine name is there to prevent me from installing a backup image from the wrong machine?
Have you tried creating an image backup to see what name you end up with?
Try your self. Press menu add any prefix and see how it works.
In my test the image backup works just fine, But since the machine name is gone it does not of obviouse reason don't show in the list
.... I don't have a problem...
-rw-r--r-- 1 root root 121747446 Feb 20 10:44 openvix-vuultimo4k-developer-6.1.000.000-20220220_104121.zip
-rw-r--r-- 1 root root 121751201 Feb 22 18:46 openvix-vuultimo4k-developer-6.1.000.000-20220222_184317.zip
-rw-r--r-- 1 root root 121801209 Feb 22 18:52 xxx-vuultimo4k-developer-6.1.000.000-20220222_184909.zip
root@vuultimo4k:/media/hdd/imagebackups#
Try your self. Press menu add any prefix and see how it works.
In my test the image backup works just fine, But since the machine name is gone it does not of obviouse reason don't show in the list
If you have a problem you are not using the current version.
.... I don't have a problem...
-rw-r--r-- 1 root root 121747446 Feb 20 10:44 openvix-vuultimo4k-developer-6.1.000.000-20220220_104121.zip
-rw-r--r-- 1 root root 121751201 Feb 22 18:46 openvix-vuultimo4k-developer-6.1.000.000-20220222_184317.zip
-rw-r--r-- 1 root root 121801209 Feb 22 18:52 xxx-vuultimo4k-developer-6.1.000.000-20220222_184909.zip
root@vuultimo4k:/media/hdd/imagebackups#Well, you might - as that name doesn't mention Vix at all, so you don't know which distro it refers to.
This was mentioned in the discussion about backup names (see this entry (https://www.world-of-satellite.com/showthread.php?62084-Problems-with-backup-and-restore&p=491260&viewfull=1#post491260)). Perhaps we should be doing the same for image backups as for normal backups?
Well, you might - as that name doesn't mention Vix at all, so you don't know which distro it refers to.
This was mentioned in the discussion about backup names (see this entry (https://www.world-of-satellite.com/showthread.php?62084-Problems-with-backup-and-restore&p=491260&viewfull=1#post491260)). Perhaps we should be doing the same for image backups as for normal backups?
Well if somebody is removing the openvix prefix then hopefully they know they are doing it for a reason that identifies the backup to them … or why do it
I think the answer is that we just remove the changeable prefix - then I have no doubt some people will want to argue about that as well
Well if somebody is removing the openvix prefix then hopefully they know they are doing it for a reason that identifies the backup to them … or why do it
I've never changed the prefix, can't really see the point, and if did, like you say, I'd make sure I knew what it referred to.
Well, you might - as that name doesn't mention Vix at all, so you don't know which distro it refers to.
This was mentioned in the discussion about backup names (see this entry (https://www.world-of-satellite.com/showthread.php?62084-Problems-with-backup-and-restore&p=491260&viewfull=1#post491260)). Perhaps we should be doing the same for image backups as for normal backups?If you made the backup with image manager surely it must come from OpenViX.
Anyway the whole point of Image Manager is it can flash images from other distros and even directly download them.
When you start using a multislot box it will all fall into place.
Anyway the whole point of Image Manager is it can flash images from other distros and even directly download them.Good point.
(Meanwhile it's only useful for the BackupManageer to see the Vix ones.)
If you made the backup with image manager surely it must come from OpenViX.
Could be from OpenBh though ;)
abu baniaz
23-02-22, 15:29
So, we need a whitelist for Settings Backup Manager backups that Settings Backup Manager can see for restoration as OBH and ViX should be interoperable
Going back to my rejected suggestion from a long time ago about Image Manager, I would like to re-suggest that we are able to sort the images by name as well as by date. I suppose image types too where they are available.
In ten years we have never had a complaint from a user about this.
This is a solution waiting for a problem.
Do we really need to assume our users are complete cretins?
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.