592 replies to this topic

[dpeddi]

Although I am not a developer I wonder what might be the purpose of this fairy tail like respond. 
In general, I believe that if someone does not make a pertinent comment, it is better to refrain from making nonsensical comments. This makes no sense and as a result only members get frustrated. Hereby a request to Huevos to limit yourself to substantive technical comments from now on. Whether or not you agree with each other's point of view is no reason to respond cynically to each other. Thanks for understanding.

 

Huevos comment is at the same level of most of other posts of this thread.

Impossible requests, double requests, requests about feature that other boxes doesn't have, and most of the answer were written on my readme. 

And nobody attempted to understand how kexec Multiboot works even if I provided the sources.

I think that this thread could be closed.

[Frenske]

To prevent that this topic escalates it might be good to close it temporarily so people might think twice before they add a non technical reply that triggers others. I will close it for now and open it somewhere in the coming days.

[Pr2]

Sorry if I hurt anybody with my questions/remarks I follow this thread but at the end since it goes into different direction I was just asking a summary to be sure to perfectly under what it is doing (and I guess that it might help others that read this thread to have a clear summary at some stage).

 

True multiboot solution was really missing in the Vu+ STB and this is clearly a big improvement brings by the community and I would like to thanks everybody involved on it.

 

I am testing it right now I could not find any problem while using it. While indeed OpenMultiboot was a total nightmare that lead me to reflash my box and no longer play with it and discourage other to do so. I don't think that the current implemenation will lead to the same issues as Open Multiboot.

 

Everybody is free to use it or not, the kexec multiboot is for me a real improvement and should stay in the image.

 

I have no problem with the current "slot 0" decision choosed by OpenPLi it was just a remark, every image maker is free to let user online flash it or not.

 

Again big thanks to everybody involved in this.

[rantanplan]

https://github.com/B.../main/README.md

 

I ask myself all the time whether nobody, really nobody, reads what their write there themselfself.

 

Split Out Main
 

 

I started modifying openmultiboot some time ago since as I wasn't happy with it. I started modifying it by wrapping it with kexec to load a kernel instead of flashing the box every time.

and
 

 

Note that kexec may not work correctly for you due to devices not fully re-initialising when using this method, however this is rarely the case. (source: ArchLinux wiki)

and

 

It seems that the broadcom driver doesn't have issues with loading if the box hasn't been initialisated yet. I've started testing this new "headless" approach.

That means you assume that there are no problems, but you don't know.
Furthermore, problems are not addressed when they arise.
Although even Ev0 assumes that the problem mentioned here is that the USB was not or is not loaded correctly.

My criticism is factual and understandable.
I don't understand the personal attacks.
That's not okay.

@Pr2
You weren't meant, nobody feels attacked by you.
Your questions are all legitimate and everything is ok.
The determination of the positive added value is also perfectly fine.

Because of me, some team members from OpenVix and OPenBH are supposed to berate me just because I don't obediently jump on the train of euphoria.
I wasn't expecting that, but I'll have to live with it.

I would have expected more analysis and possibly adjust the possible errors.
But this does not happen.

I really think I should probably pull myself out.
 

[Dimitrij]

What specifically needs to be added / corrected in openPli (point 1 and etc...)?

[littlesat]

It would be nice to have simply 4 slots… so slot 0 (may become slot 1) can be flashed while the other slots are not deleted. Preferably without making any changes to enigma2.

Edited by littlesat, 31 May 2023 - 17:06.

[Dimitrij]

slot0 need rename slot R

[littlesat]

Why slot R when it can be made transparant…

[neo]

Slot 0 is not a normal slot, it can be compared to the recovery image partition.

 

For users it would be logical and safer if:

• slot 0 is a separate partition (would also solve the problem of backup / restore of slots, no longer needed
• slot 0 would run a stripped down E2 (with only flash image and multiboot options)
• slot 0 would be called recovery image, like all other multiboot-capable boxes

It would also solve the "use slot 0 as a normal image or not" dilemma, as it would no longer contain a usable image.

 

It would also provide two image files: an USB one containing the recovery image which wipes the entire flash, and a EMMC one containing an image that can be flashed using flash image.

 

This way VU+ would behave exactly like all other boxes for users, with the limitation of 4GB flash instead of more...

Edited by neo, 31 May 2023 - 20:08.

[Huevos]

https://github.com/B.../main/README.md

 

I ask myself all the time whether nobody, really nobody, reads what their write there themselfself.

 

Split Out Main
 

 

I started modifying openmultiboot some time ago since as I wasn't happy with it. I started modifying it by wrapping it with kexec to load a kernel instead of flashing the box every time.

and
 

 

Note that kexec may not work correctly for you due to devices not fully re-initialising when using this method, however this is rarely the case. (source: ArchLinux wiki)

and

 

It seems that the broadcom driver doesn't have issues with loading if the box hasn't been initialisated yet. I've started testing this new "headless" approach.

That means you assume that there are no problems, but you don't know.
Furthermore, problems are not addressed when they arise.
Although even Ev0 assumes that the problem mentioned here is that the USB was not or is not loaded correctly.

My criticism is factual and understandable.
I don't understand the personal attacks.
That's not okay.

@Pr2
You weren't meant, nobody feels attacked by you.
Your questions are all legitimate and everything is ok.
The determination of the positive added value is also perfectly fine.

Because of me, some team members from OpenVix and OPenBH are supposed to berate me just because I don't obediently jump on the train of euphoria.
I wasn't expecting that, but I'll have to live with it.

I would have expected more analysis and possibly adjust the possible errors.
But this does not happen.

I really think I should probably pull myself out.
 

@rantanplan, I don't understand why you playing the victim. You came into this thread ranting about the lack of usefulness of multiboot even though it had already been implemented in PLi for years. The real victim here is the guy who provided the patch. It was a simple patch to allow PLi to run as a multiboot image in distros that support Kexec multiboot. The rest of the changes in PLi have been done by the PLi team. I don't understand why you want to attack the other teams who tirelessly provide so many patches for PLi. All a one way street. Never reciprical. And what do we get for our efforts? Criticism and not much else.

[littlesat]

For the user slot 0 should not be something special. It should behave as slot 1. For the user at least… and that was from the beginning the missing thing of the kexec multiboot ‘feature’… and I know it can be done! Maybe with some help for the creator of ofgwrite. I think here we have the biggest design flow how kexec was made… on the story board there was something missing that we have four slots where we can install images on…. (That we have directories for slot 2, 3, 4 on slot 1 is implementation)… to call it slot 0 because it is special with subdirectories for other slots is no reason to call it slot 0, recovery, or something else. I hope someone understands what I mean….

this is no attack to other teams. This is just point to something that can be improved in the design. And as it is somehow cross image we should be open for discussion to align it. The first thing I prefer is call it slot 1, 2, 3, 4… where slot 1 is the current slot 0. And arrange somehow eg via ofgwrite that the directories from a the other slots are backed up somehow when we flash slot 1 (current slot 0)… so for the user it are just 4 independed slots.

Edited by littlesat, 31 May 2023 - 21:21.

[neo]

Downside is that the user can f that up, and if that happens, only an USB flash will fix it, which will also destroy the other slots. So I prefer a recovery slot where the user can not break anything.

[Huevos]

For the user slot 0 should not be something special. It should behave as slot 1. For the user at least… and that was from the beginning the missing thing of the kexec multiboot ‘feature’… and I know it can be done! Maybe with some help for the creator of ofgwrite. I think here we have the biggest design flow how kexec was made… on the story board there was something missing that we have four slots where we can install images on…. (That we have directories for slot 2, 3, 4 on slot 1 is implementation)… to call it slot 0 because it is special with subdirectories for other slots is no reason to call it slot 0, recovery, or something else. I hope someone understands what I mean….

this is no attack to other teams. This is just point to something that can be improved in the design. And as it is somehow cross image we should be open for discussion.

So forget about the how for the moment. Please describe the mounts. Are you talking about splitting up the flash?

[Ev0]

For the user slot 0 should not be something special. It should behave as slot 1. For the user at least… and that was from the beginning the missing thing of the kexec multiboot ‘feature’… and I know it can be done! Maybe with some help for the creator of ofgwrite. I think here we have the biggest design flow how kexec was made… on the story board there was something missing that we have four slots where we can install images on…. (That we have directories for slot 2, 3, 4 on slot 1 is implementation)… to call it slot 0 because it is special with subdirectories for other slots is no reason to call it slot 0, recovery, or something else. I hope someone understands what I mean….

this is no attack to other teams. This is just point to something that can be improved in the design. And as it is somehow cross image we should be open for discussion to align it. The first thing I prefer is call it slot 1, 2, 3, 4… where slot 1 is the current slot 0. And arrange somehow eg via ofgwrite that the directories from a the other slots are backed up somehow when we flash slot 1 (current slot 0)… so for the user it are just 4 independed slots.

If you know it can be done, then just do it and stop going round in bloody circles.

[littlesat]

I do not know how it should be done. I only describe the user experience, so how the user feels it should behave and how the user should experience it. The how is exactly that try to discus. I have no idea how to solve it yet that is fully open. My meaning is simply by design we should have 4 slots… 1, 2, 3, 4… we should be able to flash independently as ‘spec’ or ‘story’. I’m not thinking about any solution or implementation.

Edited by littlesat, 31 May 2023 - 22:10.

[Ev0]

So as far as I can see, every other image team has accepted Kexec as it currently is.

Only OpenPLi has a problem with the current implementation.

You say you know it can be done, but you don't know how.

You want a slot 1,2,3,4 that can be used fully.

But in doing so, you then have nothing for recovery, because if slot 1 is corrupted then you have to wipe slots 1 - 4.
 

Gigablue UHD Quad 4K and UE 4K only have slots 1 - 3, so why does Vu+ need slots 1 - 4 ?

 

Only the HiSi boxes with 8gb flash (or more) have 4 slots but then they also have a full and proper recovery image provided by the manufacturer which once again isn't possible on Vu+ hardware.

The current implementation gives a recovery option incase the end user does something silly, it gives access to install more images and it gives the option to use the extra 2.5+ GB of flash space that most would not have used on these boxes, but still it's not good enough for OpenPLi.

As I said a few posts ago, I think it is better if OpenPLi do not continue using this Vu+ / Kexec / Whatever you want to call it Mulitboot, and instead create your own version from scratch so you can have it exactly as you expect it to be.

[littlesat]

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!
Unless you are not willing to improve it it stays as is. I have no time to improve this, I only try to give some advice here. And I’m not OoenPlI I’m just a member of it and happy that we finally have something that does a relatively and real good multiboot for VU…. Striving to get it improved which only works when all work together. And when you define this is the best it can get then so be it. I don’t worry.

Edited by littlesat, 31 May 2023 - 22:43.

[dpeddi]

Thanks Ev0, I couldn't explain that better then you!

 

@Openpli team and contributors:

 keep in mind that Kexec-multiboot consists of a kernel with a ramdisk containing kexec and few instruction to start up and a ramdisk appended to the guest image kernel to supports the subdirectory.

 

Kexec-multiboot installation procedure consists on:

- kernel partition is backupped into /zImage

- kexec-multiboot is flashed it into kernel partition. 

- kexec-multiboot-initrd is copied into /STARTUP.cpio

slot 0 is exactly the image that would be booted if you restore original kernel.

 

You can name slot0 as recovery, main image, base image, non multiboot image... but that's how i designed the solution. Is not identical to the other multiboot solution and can't be identical. You have to accept this.

 

I don't intend to implement repartitioning of the box because the solution have to be safe. You can restore the box and save yours image in multiple way if slot0 is working (maybe some knowledges is required... or someone might implement an extended recovery plugin)

 

Quicker way is always the file on the root of the usb stick that force you to slot0.

If you restore the original kernel vuplus kernel into kernel partition by putting kernel_auto.bin into USB:/vuplus/<boxname/ you get the original box state with the multiboot images into /linuxrootfs<slotnumber>

If you mess up with slot0, restoring the original kernel the box won't boot.

 

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.

[littlesat]

There is a difference of implementation and how the user might experience it…. It sounds like some cannot these as for the implementation slot 0 is something special. I think for the user it shouldn’t and I understand Huevos has in vix
Added already something to work-a-round it… so you can flash slot 0, backup
It etc without loosing other slots.
Indeed making something that is a real ‘recovery’ mechanism is also a solution but a difference solution.
And I also described before someone should be able to make it or is willing to make it.
For now I personally acknowledge as it is now is a good solution and for the time being the best we have…
Unless it is sub-optimal. So personally I do not worry.

Edited by littlesat, 31 May 2023 - 22:53.

[littlesat]

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…

Edited by littlesat, 31 May 2023 - 22:55.