592 replies to this topic

[littlesat]

When you flash slot 0 and the other slots are backed up via ofgwrite so it behaves stealthy is a good idea I think.
But I do not see something here and when this is done we should also get it.

[rantanplan]

I didn't say that was the sole reason. We inspected the PLi image and know where the size differences are.

 

 

Excuse me?
Yes, that's exactly what you said and it's wrong.

Besides that, you can't compare a pli image to the OE Alliance, there are a few other things that are built differently here.

However, when I look at the OE-Alliance images, they got bigger in between and seem to have gotten a little smaller again with the last update of python and the environment.

So please again, your statement that an image will be 30mb larger because of a python update to 3.11 is not correct.
 

[Huevos]

 

I didn't say that was the sole reason. We inspected the PLi image and know where the size differences are.

 

 

Excuse me?
Yes, that's exactly what you said and it's wrong.

Besides that, you can't compare a pli image to the OE Alliance, there are a few other things that are built differently here.

However, when I look at the OE-Alliance images, they got bigger in between and seem to have gotten a little smaller again with the last update of python and the environment.

So please again, your statement that an image will be 30mb larger because of a python update to 3.11 is not correct.
 

 

Maybe you should go back and read again.

[babsy98]

what you saw with small was for the models with 128 MB flash there we have the install size only reduced to 50 mb
so that vu vusolo vuduo and vuuno can live on

 

the solution with usb-slot I must say, find that not bad, I have there now connected a usb 3 key with 250 GB and there are my guests in it, and everything is preserved even after updating the root image

 

then the size of the image in the flash is also irrelevant
 

[Dimitrij]

 

 

 

 

                if self.multibootslot == 0 and SystemInfo["HasKexecMultiboot"]:        # reset Vu Multiboot slot0
                    kz0 = getMachineMtdKernel()
                    rz0 = getMachineMtdRoot()
                    CMD = "/usr/bin/ofgwrite -kkz0 -rrz0 '%s'" % MAINDEST  

 

 

 

 

Huevos

Is this code correct?

https://github.com/O...Manager.py#L599

+CMD = "/usr/bin/ofgwrite -k%s -r%s '%s'" % (kz0,rz0,MAINDEST) 

 

 

Or maybe(simple) it should?

FlahManager fix Slot R cmdargs for kexecmultiboot

                    cmdArgs = ["-r", "-k", "-f"]
                    Console().ePopen("umount /proc/cmdline")

 

[littlesat]

I prefer to have it without changes in enigma2.

[Huevos]

 

 

 

 

 

                if self.multibootslot == 0 and SystemInfo["HasKexecMultiboot"]:        # reset Vu Multiboot slot0
                    kz0 = getMachineMtdKernel()
                    rz0 = getMachineMtdRoot()
                    CMD = "/usr/bin/ofgwrite -kkz0 -rrz0 '%s'" % MAINDEST  

 

 

 

 

Huevos

Is this code correct?

https://github.com/O...Manager.py#L599

+CMD = "/usr/bin/ofgwrite -k%s -r%s '%s'" % (kz0,rz0,MAINDEST) 

Yes, it is an error, but because ofgwrite ignored it and worked ok it was not obvious.

[littlesat]

https://github.com/O...92f0f6ebfb03c7b

 

This is what I think bot the idea to go. It looks for my like stripping an image after it is flashed.

 

Image in Slot 0 can still be a real image that can be overwritten when the subdirs are backed up... To add Multiboot in the wizard can be done in a much easier way. Having Screens in standard enigma for VU is also not a real good structured idea... but when you want to do it, you just do it... At least this is something in PLi's 'PEP' we tried to avoid. I was thinking about a mechanism where the slot directories when they are on flash are backed up on the USB or so and moved back to the slot 0 once it is flashed. so to do it in a kind of 'stealthy' way.

 

-or-

 

Together we decide to make a small 'mechanism' that slot 0 will be a real 'recovery' slot.... Then I prefer a small binary that can be executed like ofgwrite with remote control input where you are able to select a slot, download and flash an image via ofgwrite....

 

I do not like that this is getting a person-to-person round instead of cooperative working somehow together.

Please note that this is also something that depends on cross-image stuff....

It is also a bit pitty that some start to code something without getting any agreement.

Edited by littlesat, 11 June 2023 - 13:47.

[Huevos]

https://github.com/O...92f0f6ebfb03c7b

 

This is what I think bot the idea to go. It looks for my like stripping an image after it is flashed.

 

Image in Slot 0 can still be a real image that can be overwritten when the subdirs are backed up... To add Multiboot in the wizard can be done in a much easier way. Having Screens in standard enigma for VU is also not a real good structured idea... but when you want to do it, you just do it... At least this is something in PLi's 'PEP' we tried to avoid. I was thinking about a mechanism where the slot directories when they are on flash are backed up on the USB or so and moved back to the slot 0 once it is flashed. so to do it in a kind of 'stealthy' way.

We already move slots 1, 2 and 3 to HDD when flashing slot 0, and then back to flash after.

[Ev0]

It is also a bit pitty that some start to code something without getting any agreement.

Maybe some of us would rather get on and actually try to do something, instead of talk about things for 4 months and do nothing but go round in circles.

[littlesat]

We already move slots 1, 2 and 3 to HDD when flashing slot 0, and then back to flash after.
-
Sounds like an idea/solution indeed, but not for the boxes that do not have an hdd so maybe something should also be done in a different way eg with sufficient space on usb. And I think the best place it doing it ‘stealthily’ in ofgwrite.

[littlesat]

I prefer to get agreements first and then when we have a kind of detection try something. But most times it is first tried, then we get discussions and then some are angry that something that was tried get arguments. Which then exactly describes why we get discussions person to person for months.

[twol]

 

I didn't say that was the sole reason. We inspected the PLi image and know where the size differences are.

 

 

Excuse me?
Yes, that's exactly what you said and it's wrong.

Besides that, you can't compare a pli image to the OE Alliance, there are a few other things that are built differently here.

However, when I look at the OE-Alliance images, they got bigger in between and seem to have gotten a little smaller again with the last update of python and the environment.

So please again, your statement that an image will be 30mb larger because of a python update to 3.11 is not correct.
 

 

I spent a lot of time last week, comparing the size of the .pyc files on a Vu+ Uno4k SE with the installed OpenPli (python 3.9) and OpenViX/OpenATV (python 3.11) images.
Apart from really small python modules, typically the OE-A .pyc modules were 1.7 ---> 2.0 times the size of comparative OpenPli modules.

Obviously both the python developers and myself could be wrong, so I would ask that you post your comparative results from a Vu+ 4K receiver so they can be sent to the python developers for clarification.  

[Huevos]

We already move slots 1, 2 and 3 to HDD when flashing slot 0, and then back to flash after.
-
Sounds like an idea/solution indeed, but not for the boxes that do not have an hdd so maybe something should also be done in a different way eg with sufficient space on usb. And I think the best place it doing it ‘stealthily’ in ofgwrite.

Yes and some boxes might not have a USB... And the USB is used as a system device if the user wants so probably not a good idea using that. I don't think ofgwrite is the place for this. When you make standard backups you don't use ofgwrite so why should this be any different? It is just a case of moving a folder and then moving it back. No reason why ofgwrite should be involved.

 

Also the ImageManager/FlashManager is different in all images so we are never going to do the same in that area.

 

Anyway one team or another handles image flashing and backups is not important to how Kexec multiboot works, which is the same in all images.

Edited by Huevos, 12 June 2023 - 12:22.

[rantanplan]

@twol

To be honest, I've lost my interest a little, so I just let it rest.

A careful test on your part would only make sense if you were to update the python version separately in the Hardknott branch.
This is possible, just like you can update a gst or ffmpeg.

OE Alliance is chasing after the 'master branch' of OE core.
This is not a good idea from a stable image point of view.
At least that's how I see it.
Errors are not fixed, but constantly updated in order to find them as new errors.

They are receivers that we should provide with software here.
Stable and bug-free software.
The latest version of Python is of no use to users if the entire basis is faulty.

I've been very active in updating Hardknott, and can only say that VU+ has always responded to inquiries.
Unfortunately, that is not the case here.

As far as python3.11 and the 'size' in the OE-Alliance are concerned, I would assume the 'installed-vs-skipped' files in the 'site-package', most of which are not required, but have been installed.

The problem with this is that one tends to turn off the error messages instead of editing them following them.

[Persian Prince]

Using master branch of OE requires weekly maintenance sometimes and not recommended.

 

But "Hardknott" is EOL and won't receive any important updates, keeping an EOL up-to-date is similar to keep master happy with all changes so it requires more maintenance, check https://wiki.yoctopr...g/wiki/Releases for using a stable and up-to-date one like "Kirkstone".

[rantanplan]

Using master branch of OE requires weekly maintenance sometimes and not recommended.

 

But "Hardknott" is EOL and won't receive any important updates, keeping an EOL up-to-date is similar to keep master happy with all changes so it requires more maintenance, check https://wiki.yoctopr...g/wiki/Releases for using a stable and up-to-date one like "Kirkstone".

That is your opinion'.
I think hardknott is currently a very good solution for a stable image, especially with the bitbake used.

From this branch, many updates regarding individual required things such as Mediaframwörk and QT can be made without detours.

The branch is open for both solutions of the 'style' used and you don't have to additionally install clang as the next language.

But, as already mentioned, it doesn't seem to be about stability, but rather something else.

[littlesat]

That is your opinion'.
I think hardknott is currently a very good solution for a stable image, especially with the bitbake used.

From this branch, many updates regarding individual required things such as Mediaframwörk and QT can be made without detours.

The branch is open for both solutions of the 'style' used and you don't have to additionally install clang as the next language.

But, as already mentioned, it doesn't seem to be about stability, but rather something else

+1 ...

Edited by littlesat, 12 June 2023 - 14:34.

[littlesat]

Also the ImageManager/FlashManager is different in all images so we are never going to do the same in that area.

 

Anyway one team or another handles image flashing and backups is not important to how Kexec multiboot works, which is the same in all images.

But to 'streamline' things with the slot 0 mechanism we should prefer to get it re-aligned.... I think backing-up the other slots when flashing slot 0 belongs to ofgwrite principaly and not by making changes to enigma2 (which is the easiest possible way). For online flashing having a hdd or USB with sufficiant free room is mandatory. So I'm afraid we should wait for the creator of ofgwrite -and/or- someone will create a real extreem small recovery image thing so the discussion can be closed at least with a real structured solution and not something that have the feel and look like a work-a-round....

[dpeddi]

 

Also the ImageManager/FlashManager is different in all images so we are never going to do the same in that area.

 

Anyway one team or another handles image flashing and backups is not important to how Kexec multiboot works, which is the same in all images.

But to 'streamline' things with the slot 0 mechanism we should prefer to get it re-aligned.... I think backing-up the other slots when flashing slot 0 belongs to ofgwrite principaly and not by making changes to enigma2 (which is the easiest possible way). For online flashing having a hdd or USB with sufficiant free room is mandatory. So I'm afraid we should wait for the creator of ofgwrite -and/or- someone will create a real extreem small recovery image thing so the discussion can be closed at least with a real structured solution and not something that have the feel and look like a work-a-round....

 

 

From a private conversation with Betacentaury on 10-Oct-2022, it appear that he have few spare time. 

 

On 20-Jan-2023 i asked him to validate my ofgwrite patches and he never answered nor approved the PR on oe-alliance/ofgwrite repository. 

Indeed the PR has been accepted by someone else...

 

Feel free to write your code to backup the slot into ofgwrite... someone will approve your PR.