dpeddi

https://github.com/o...d6f2f9248d33ea9

for weeks?
https://github.com/O.../commits/master
https://github.com/B...mits/Python3.11

 

and everyone claims that everything has been going perfectly for months.
and everyone here is complaining about here some critical thoughts.

It's all a little strange.

You complaint about the UI. The UI os pure phylosophy.

 

During these months have been added some functionality on enigma2.

 

..But the multiboot selector and the kexec multiboot kernel had no changes since february.

 

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.

Do you thin I haven't considered all this condition, ideas etc?

1) I already did that 1 time in my mind,
2) a second time when I presented the solution to the opening team
3) A tied time when we presented it to the openvix team.

Most of the requests and proposal I have seen on openbh board thread and here were already considered or already discarded on step 1.
Complaints about recovery / slot 0 already appeared on step2, but at the end has been accepted.
If you think out of the scheme will see that naming the image on the root of the flash slot 0 and consider it a recovery is the best solution.

Having it smaller and leave that unused could be a desiderata, but having it as a normal image isn't a show stopper.

Finally if an advanced user wants something different, he could always play with startup file in /.
He can create copy STARTUP_REECOVERY to STARTUP_4, create multiple slots to use images on HDD or SSD, create extra slot on flash.
The gui is stupid enough to manage all the startup file and the STARTUP_RECOVERY on usb is smart enough to go back to the master image if something go wrong.
But we decided that the 3 extra slots on flash are enough for most user.

I think that if OpenPli would decide that can fit 4 images we wouldn't complaint... If you decide to name the slot0/recovery as "Bob" or "Mike", we wouldn't complaint (even if it will confuse our users).
If you decide to prepare a smaller image with a stripped down enigma we could adopt it... But develop such image isn't in our plan. If you want to create modification of ofgwrite betacentauri wouldn't help. He haven't spare time.

Unless all calling the special slot slot zero 0 was not a good idea by design…. Better call it just slot 1…. It this is something that needs to be defined cross image… but note this statement is my meaning…

 

slot1 is /linuxrootfs1, slot2 is /linuxrootfs2 in every implementation.

 

the original image can't be slot1... if you want you can name it slot-1... (slot minus one) but not slot 1...

We or I do not have any problem. We’re just suggest improvements. It is already better than having nothing as we had before.
Please do not feel attacked. Please stay open for improvements. Please accept and acknowledge the solution as we have now is somehow suboptimal and not fully transparant/comparable with the other multiboot solution.
And to get it improved we should work together as it is cross image. And when not that it stays as it is….
And it is not only openpli here that acknowledge it it suboptimal. As this is simply a fact!

 

Currently every vendor have his implementation but more or less there are 3 categories:

1  /dev/block/by-name/flag (qviart dual and maybe others)

2  STARTUP file reading 

 

In the past i've considered also kexecboot.. I've tried that and already patched for vuplus: https://github.com/dpeddi/kexecboot

That solution provides a menu itself, it doesn't need for any recovery but it needs broadcom driver on the initrd so is really difficult to make them to fit on the kernel partition. 

Forgot to wrote that i consider this a personal offense to me, Twol and Huevos that worked hard on the Enigma2 side.