592 replies to this topic

[Frenske]

@all

My experience is based on Multiboot on an internal harddisk and not on an USB stick. I never experienced that the image halts after the blue screen and all images ran without issues as far as tested on two Ultimo 4K boxes.

[littlesat]

The same I experience. No issue so far. So the Q is what happened when you are stuck on a dark blue screen?
Still it would be helpfull to have a mechanism to start a slot you want… and not only slot 0. And have a mechanism to replace slot 0 without loosing slot 1, 2, 3…

Edited by littlesat, 21 May 2023 - 07:44.

[Frenske]

The same I experience. No issue so far. So the Q is what happened when you are stuck on a dark blue screen?
Still it would be helpfull to have a mechanism to start a slot you want… and not only slot 0. And have a mechanism to replace slot 0 without loosing slot 1, 2, 3…

 

Regarding the last points, I fully agree.

[dpeddi]

The same I experience. No issue so far. So the Q is what happened when you are stuck on a dark blue screen?
Still it would be helpfull to have a mechanism to start a slot you want… and not only slot 0. And have a mechanism to replace slot 0 without loosing slot 1, 2, 3…

You can flash the new image on slot1, another image on another slot, 2 for example.

You can boot the slot 2, mkdir /tmp/swpimg, mount /dev/mmcblk0p?(depends on the box you are using) /tmp/swpimg, mkdir /tmp/swpimg/slot0, cd /tmp/swpimg; mv boot etc bin sbin tmp usr lib zImage mnt var opt home slot0, mv linuxrootfs1/* ..; rmdir linuxrootfs1 ; mv slot0 linuxrootfs1.

 

I did this trick on my box and it worked, but is too complicated even with if a plugin would automate the procedure.

Edited by dpeddi, 22 May 2023 - 06:19.

[littlesat]

When it does not boot through you cannot do anything????

[rantanplan]

So, regardless of the box, I only think logically about the handling via kexec and USB connection.
There seems to be a possible problem here.
OK?

Taking this further, the thoughts were to add 'delays' to the USB, or disable it altogether.

Thinking about it further, I see another problem that has not yet arisen.

If, for whatever reason, the kexec causes the activation of the USB to be deactivated, then a 'great Accident' occurs.
It hangs within the kexec and a flash via USB would not be possible.

I put these thoughts in the room and hope that this is also taken seriously.

[littlesat]

And so we’re almost back to what I said int be beginning that we need to have a good recovery mechanism. And not work-a-round with a file on an usb stick.

[Huevos]

So there might be a possible "problem here." And another one "that has not yet arisen". No one has seen it. No one has encountered it. No one can describe how to reproduce it. But somehow it needs to be fixed?

Edited by Huevos, 22 May 2023 - 18:14.

[dpeddi]

And so we’re almost back to what I said int be beginning that we need to have a good recovery mechanism. And not work-a-round with a file on an usb stick.

Gigablue boxes have what you are asking?

[rantanplan]

No.
We are talking about Vu+Multiboot solution.

[dpeddi]

No.
We are talking about Vu+Multiboot solution.

Since you (openpli) get in contact with vuplus, then complaints with them. They have the NDA code and the source of their implementation and can implement a proper multiboot and recovery.

A proper recovery require all the implementation already available on enigma2 (Multiboot selection, online flash, usb flash). Reimplement that is just a loss of time.

[WanWizard]

Proper implementation requires access to the source of the bootloader, as recovery integrates with that. It would also allow the creation of a small separate partition for the recovery code.

 

This is how HiSilicon has implemented it. We have discusses the possibility to get this (and their recovery app) ported to VU+ hardware, but we don't see a solution without access to the bootloader.

 

VU+ will never release their source (afaik there is no NDA on the bootloader), and given the comatose state of VU+ at the moment, don't expect any new development from them.

[rantanplan]

@ WanWizard

If we can't design it carefully, then it's better not to put it in the image via kernel manipulation at the moment.

Again, I don't have this VU+.
But such a blue screen with the background that the Kexec itself as a preloading file can also be destroyed could lead to a flash loss also via USB can not be in the sense of an image.

Somehow I feel so frighteningly alone and I know that the sf4008 offers just such catastrophes.

That's the end of the receiver, just because of a 'gimmick'

Edited by rantanplan, 22 May 2023 - 20:51.

[Huevos]

@ WanWizard

If we can't design it carefully, then it's better not to put it in the image via kernel manipulation at the moment.

Again, I don't have this VU+.
But such a blue screen with the background that the Kexec itself as a preloading file can also be destroyed could lead to a flash loss also via USB can not be in the sense of an image.

Somehow I feel so frighteningly alone and I know that the sf4008 offers just such catastrophes.

That's the end of the receiver, just because of a 'gimmick'

So you are commenting on a failure that hasn't ever happened? And you can't test it because you don't have the hardware? And, BTW, any file could get corrupt and stop the box.

 

Kexec multiboot has been in OpenViX, and OpenBh public images since February without a single user reporting a lock up. Some displays show a blue screen for a few seconds after the splash screen but no side effects reported.

 

If you want a more conventional implementation you better get on to Vu+ like we did several years ago, but after discussing with them nothing was ever implemented, so good luck with that.

Edited by Huevos, 22 May 2023 - 22:30.

[babsy98]

i have multiboot with openatv since we have it active,

so far no problems and i switch between openatv versions all the time,

i never saw a blue screen,

but i don't use usb slots and only have oe-a images in multiboot

[littlesat]

The blue screen has everyone, but not all TVs may show it as it is short…

when you never experience an issue does not mean there is no problem.

The solution from the problem is something we cannot solve or is complicated. I already mentioned it from the beginning. There is no real proper recovery mechanism. When it happens you can always flash all and loose all via the normal flash mechanism.

it is what it is as for VU this multiboot is the best we can get! But we have to realize it is not optimal.

Edited by littlesat, 23 May 2023 - 08:10.

[babsy98]

you just have to live with it, unfortunately vu has no interest,

the multiboot we have already requested in 2016 there was only one response,

3rd party images are not supported.

 

for my purposes this is such a good solution

 

next vu images, i remove the chrome from the standard image this makes the base image x times smaller

Edited by babsy98, 23 May 2023 - 09:03.

[littlesat]

Yea indeed. Not perfect and 100% safe but at this moment the only we get thanks to those who created it. I’m looking for a more safe method but I have no idea yet how. First issue I get is getting control from the remote in an executable like ofgwrite… that would be a nice ‘tool’ and solution when we get an user interface with remote control around it.

[WanWizard]

@ WanWizard

If we can't design it carefully, then it's better not to put it in the image via kernel manipulation at the moment.

 

True.

[rantanplan]

 

@ WanWizard

If we can't design it carefully, then it's better not to put it in the image via kernel manipulation at the moment.

Again, I don't have this VU+.
But such a blue screen with the background that the Kexec itself as a preloading file can also be destroyed could lead to a flash loss also via USB can not be in the sense of an image.

Somehow I feel so frighteningly alone and I know that the sf4008 offers just such catastrophes.

That's the end of the receiver, just because of a 'gimmick'

So you are commenting on a failure that hasn't ever happened? And you can't test it because you don't have the hardware? And, BTW, any file could get corrupt and stop the box.

 

Kexec multiboot has been in OpenViX, and OpenBh public images since February without a single user reporting a lock up. Some displays show a blue screen for a few seconds after the splash screen but no side effects reported.

 

If you want a more conventional implementation you better get on to Vu+ like we did several years ago, but after discussing with them nothing was ever implemented, so good luck with that.

 

I don't understand your attacks against me.
What shoud that?

If you feel that your discrediting is the only way to get factually worded things out of the way, then I apologize.

I also don't forbid 'multiboot' in OpenBH or OpenVix.
From the beginning I refer to the low interest of the users on the one hand and to the questionable pressure like you on the other.

My questions regarding the 'security' of the kexec are simply not answered, but simply wiped away for the most part.
It's no secret that the VU+ has USB ports, and if you're tinkering with multiboot, then they have to work properly.
It is of little use to me and the users if they have a destroyed box afterwards and you say that this was not tested at all.

You don't go into the problem and then expect feedback from the user?
You simply insult the user for having caused something yourself beforehand and don't even bother with which user you are dealing with.
What would you say to me if I did a stress test using the available USB ports and then the VU+ was destroyed?

What would be the answer then?
Shit happens?
That's not serious.

pli is expected to provide its image with the hidden patch in the kernel.
Maybe VU+ has good reasons not to use it, who of you knows?

From my point of view, the manipulation is currently not safe.

Convince me of the opposite factually, but not with provocations.

I don't see myself as a 'decision-maker' for pli, but I would free the VU+ branch from kexec again from my point of view.
If User still want it, User are welcome to use what you consider to be a safe image from OpenVix or OpenBH.

The implementation of the image in a different slot was implemented in the enigma2.

A VU+ is too expensive for that and too valuable to be destroyed just because of a 'nice to have' feature.

my opinion