592 replies to this topic

[dpeddi]

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 

3 /proc/stb/fp/boot_mode

 

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. 

And least but not last, it required a complete implementation of the flash image routine.

 

kexec multiboot reuse the 100% of the code for 2 category. I consider that a GOAL and the best solution possible!

 

And it is not only openpli here that acknowledge it it suboptimal. As this is simply a fact!

 

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

Edited by dpeddi, 31 May 2023 - 23:11.

[dpeddi]

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...

[littlesat]

There is a difference of user experience and implementation…. Slot 1 can stay in /linuxrootfs1 etc…. A lot 0 can also be a slot 4 when you think out of the box then the user has 4 slots and slot 4 needs special treatement. But you and now also me are already thinking about the implementation and that is a step too soon.
The user wants to see 4 slots… and slot 0 which is also now listed at the end has a special thing in the fexec solution. A user does not care….
And I already understand for the current slot 0 Huevos for vix made already something special that you can backup all the other slots and restore them etc.
Note I’m only looking from user perspective…and that is trying to get the look and feeling the same.

Edited by littlesat, 31 May 2023 - 23:16.

[dpeddi]

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.

[littlesat]

It sounds like the door is closed and decisions are made cannot be compromised and are taken as critic… instead of leave the door open for improvements, suggestions and open discussions. Openbh and openvix did curve it in stones. The solutions seems to be perfect balanced. No comments to the solutions will be accepted! That is how it sounds like from my personal perspective.

that a real recovery system was missing was my first comment. But unless this I gave it a go, tested it, made small changes to it, in a hope together it can still be optimized. But now it is kind of personal attack. 
For now I need to take a break with this discussion…. In the past I just made it better and optimize stuff, but today it cost me to much energy. So I live for a while as it is now.

Edited by littlesat, 1 June 2023 - 08:49.

[Huevos]

It sounds like the door is closed and decisions are made cannot be compromised and are taken as critic… instead of leave the door open for improvements, suggestions and open discussions. Openbh and openvix did curve it in stones.

That's not true. We are completely open to changes, but currently no one has brought any code to the table.

Edited by Huevos, 1 June 2023 - 09:32.

[littlesat]

I first prefer to discuss to get things allowed before put code on the table….

Edited by littlesat, 1 June 2023 - 10:11.

[neo]

So, the stripped down slot 0 is the only possible good idea... or new recovery menu that replace enigma on a stripped down image. I considered both options but i just decided to don't waste more time. Feel free to implement it.

 

Like Littlesat I also look at it from an end-user perspective, but I don't agree with him using slot 0 (or whatever) as a normal slot. Give a user a hammer, and they'll find something to hit...

 

Holiday's coming up, but I'm willing to look at the partitioning and the stripped down slot 0.

 

They only thing we're missing compared to the boxes that support this by default is the forced trigger (reset button, pressed-down power button, etc) to start the recovery image. That would require changes to the bootloader, which we can't make. So be it.

 

@dpeddi,

 

I think your work sofar is brillant, we should have had this years ago !

 

But I think you need to keep in mind the difference in perspective between image (makers). When OpenPLi talks about end-users, we talk about users just about able to use the remote. They can't play with files, they don't visit forums like this, etc. We would like solutions to be stable and workable for those users too... One could argue that those users shouldn't use multiboot, but as it is an available feature, you can't block them from doing so. So it better be fool-proof...

Edited by neo, 1 June 2023 - 10:53.

[littlesat]

Partitioning is not needed and might break a manufacturer’s/flash via usb to restore the box flash.
But having a ‘slot 0’ that behaves as a recovery image where you can (re)flash slots and start slots without a real enigma 2 is a lot of work and not made yet…

[neo]

A separate partition would remove the need to backup and restore up to 4Mb of slot files when you want to flash the "slot 0" image. But yes, you might run into compatibilty issues.

 

But having a ‘slot 0’ that behaves as a recovery image where you can (re)flash slots and start slots without a real enigma 2 is a lot of work and not made yet…

 

I'm willing to have a look at this after my holidays, I already have a stripped down image, see how far enigma can be stripped, and make a recipe for it, might indeed be a challenge, but that is what makes it fun .

[littlesat]

I agree but it can only be done when it is safe and does not break a manufacturers flash via usb.

[littlesat]

When you have the time to help here than thanks in advance!

[neo]

Will be towards the end of the month.

[littlesat]

Totally no issue….

[Huevos]

Rather than create multiple images just strip the slot 0 image with OPKG (about 30 lines of code). We have experimented with this on first install and are able to strip more than 60 MB from the recovery image and it still works fine for the purpose.

 

https://github.com/O...c69ced6b7ada60c

Edited by Huevos, 8 June 2023 - 21:44.

[littlesat]

Nice to understand what I meant. But why not work together with Neo? Sounds like we finally get some kind of recovery image?

[neo]

I personally think it is absurd to implement something like this in Enigma.

[Pr2]

My opinion, it is really touchy to resize the slot 0 and create partition in the flash. This will prevent the official image to be reinstalled easily for example someone that is selling the box as a second hand and want to provide it with stock image.

And if your recovery specific image is corrupted you will never be able to flash an image on the box.

I think that the current implementation is the safest one, the flash remains untouched. The only drawback is that if people flash from USB all the multiboot images are lost, but this can also be the expected action of the end-user.

Is backupsuite capable to create fully working image for the multiboot images? I didn't test is yet myself.

 

If you create your own recovery small footprint image into slot 0, how to delete all the partition and retrieve the full flash?

 

The current approach of other teams that backup and restore the multiboot images installed seems to me the safest approach.

 

My personal request would be to be able to create the slot on my internal HDD (I have SSD in all my VU+ boxes) not as a partition but as a sub-folders we can hide it with a .multiboot_slots root folder for example, so by flashing the box I won't lose the image an no directory slots backup/restore needed.

[Ev0]

My opinion, it is really touchy to resize the slot 0 and create partition in the flash. This will prevent the official image to be reinstalled easily for example someone that is selling the box as a second hand and want to provide it with stock image.

And if your recovery specific image is corrupted you will never be able to flash an image on the box.

I think that the current implementation is the safest one, the flash remains untouched. The only drawback is that if people flash from USB all the multiboot images are lost, but this can also be the expected action of the end-user.

Is backupsuite capable to create fully working image for the multiboot images? I didn't test is yet myself.

 

If you create your own recovery small footprint image into slot 0, how to delete all the partition and retrieve the full flash?

 

The current approach of other teams that backup and restore the multiboot images installed seems to me the safest approach.

 

My personal request would be to be able to create the slot on my internal HDD (I have SSD in all my VU+ boxes) not as a partition but as a sub-folders we can hide it with a .multiboot_slots root folder for example, so by flashing the box I won't lose the image an no directory slots backup/restore needed.

Again there is no partition or repartitioning of flash with this multiboot.

[Pr2]

I know that with the current implementation there is no partitioning.

But OpenPLi is talking of a small footprint recovery image, isn't it the goal with this recovery image to create real slots (partition) in the flash?

If not what is the interest of this recovery image?

Edited by Pr2, 9 June 2023 - 14:43.