592 replies to this topic

[littlesat]

Atv is a huge image… twice is size as openpli � I would not recommend to put it in slot 0

[twol]

Have to say that with the original Vu+ multiboot code from OpenViX & Openbh, I have never seen any issues reported with Blue Screens.

Now the original implementation of the code in OpenViX/Openbh has been changed so that flashing the box (new or slot 0) gives users an option to stay with the existing Vu+ image or install multiboot straight into slot 1 (the Recovery image just has a minimal configuration installed).

So users have an immediate choice during the install wizard and if multiboot is chosen, it will boot directly to slot 1.

[littlesat]

Everytime you reboot your have to see a dark blue screen for a moment as this is a part from kexec. Tha Tis not the bug but is Bas been reported for some and we have bonuses what they do it suddenly freezes at this screen. And it looks likenother images worked around something.

Edited by littlesat, 20 May 2023 - 13:15.

[Ev0]

Everytime you reboot your have to see a dark blue screen for a moment as this is a part from kexec. Tha Tis not the bug but is Bas been reported for some and we have bonuses what they do it suddenly freezes at this screen. And it looks likenother images worked around something.

Doesn't happen in OpenBh and afaik does not happen in OpenViX either, so this blue screen and sudden freezes seem to be something either yourselves or OpenATV (can't workout if the user is complaining about OpenPLi or OpenATV), have created with your implementations / modifications.

The only time I have seen that blue screen is if I have used the STARTUP_RECOVERY file and iirc even then, only if it has been used on a fat32 usb stick inserted in the front usb port.

Also the user that reported freezing during bootup, also stated his box was doing this without multiboot too, so maybe he simply has a box that is slowly failing ?

[Frenske]

I can confirm that during booting (OpenPLi in slot 0) a dark blue screen appears which didn’t really bother me. As far as I’ve tested the chosen image works as it should. This is with my Vu+ Ultimo 4K. As this is my most used box it wouldn’t be accepted by my wife and by me if we actually noticed daily issues. Also my second Ultimo 4K, I bought this on purpose to test with before I flash my daily used box, hardly ever noticed real issues.
I will test with another image in slot 0 on my Duo 4K de tomorrow and see what happens.

[littlesat]

The dark blue screen is something that is expected behavior with kexec. When it does not occur then the other images ‘patched it somehow away’. Actually instead of that screen we actually should get a recovery thing that should be shown with a small user interface, but as it also needs input from a remote it is not easy to make. I thought openatv en vix were oe-a images so why would it behave different here might be interesting.
Having no real recovery mechanism means when something happens with slot 0 the whole thing may become unstable/locked.

[Ev0]

The dark blue screen is something that is expected behavior with kexec. When it does not occur then the other images ‘patched it somehow away’. Actually instead of that screen we actually should get a recovery thing that should be shown with a small user interface, but as it also needs input from a remote it is not easy to make. I thought openatv en vix were oe-a images so why would it behave different here might be interesting.
Having no real recovery mechanism means when something happens with slot 0 the whole thing may become unstable/locked.

So we "patched it away", pushed the code to you, and you have then somehow "unpatched it", is that what your saying ?

[littlesat]

Nope we get the merge request from you somehow or it looks like it was taken from Openatv end then pushed to us from there… and then we merged it. And maybe somehow openatv is also missing something as only we and them have that blue screen.
But the blue screen itself does not harm at all here…

[Huevos]

Nope we get the merge request from you somehow or it looks like it was taken from Openatv end then pushed to us from there… and then we merged it. And maybe somehow openatv is also missing something as only we and them have that blue screen.
But the blue screen itself does not harm at all here…

Now I'm confused. The commits came from us, not ATV.

[Ev0]

Ok, I found a way to be able to see the blue screen.

If I turn off my tv, and then turn it back on, when the splash screen is on the Ultimo4K display, then I can see the blue screen after the splash.

Otherwise my tv doesn't show it, so it must be to do with the resolution change and my tv deciding not to bother switching.

Either way, as already said, it's not a bug and it's not an issue either.

[rantanplan]

It's a question of how to deal with problems that users pass on.


@OpenBH
If feedback is immediately nipped in the bud because you reply that there can't be a problem, then you won't get any more feedback.
You shouldn't make it that easy for yourself.

The 'blue screen' is there and comes from the kexec and as Fremske writes, it's not a problem if it only flashes briefly.

twol read it here as in the ATV and PikeBishop is no beginner!

https://www.opena.tv...html#post536012

If the box stalls with this 'BlueScreen' then it's coming from the Kexec and then there's a problem!

It is clear to this user that you should definitely keep a minimal image for Slot0 or r or whatever.
But even if it is not clear to him, it shows that you need a little more explanation when using it.

The image or better the entire boot can no longer be continued and ends with the blue screen.
All multiboot images can then no longer be saved.
A new flash is required.

I can only appeal to take this seriously.

A log is not possible from the area, as I see it.

Edited by rantanplan, 20 May 2023 - 23:21.

[Huevos]

LOL. That is a problem with one of the STARTUP files.

[rantanplan]

Ok, so that's all feedback?
An assertion and then that was it as an explanation?

Well then, that's how it should be.

[Ev0]

It's a question of how to deal with problems that users pass on.


@OpenBH
If feedback is immediately nipped in the bud because you reply that there can't be a problem, then you won't get any more feedback.
You shouldn't make it that easy for yourself.

The 'blue screen' is there and comes from the kexec and as Fremske writes, it's not a problem if it only flashes briefly.

twol read it here as in the ATV and PikeBishop is no beginner!

https://www.opena.tv...html#post536012

If the box stalls with this 'BlueScreen' then it's coming from the Kexec and then there's a problem!

It is clear to this user that you should definitely keep a minimal image for Slot0 or r or whatever.
But even if it is not clear to him, it shows that you need a little more explanation when using it.

The image or better the entire boot can no longer be continued and ends with the blue screen.
All multiboot images can then no longer be saved.
A new flash is required.

I can only appeal to take this seriously.

A log is not possible from the area, as I see it.

If by @OpenBH you are replying to me, then @Ev0 would be better in future

I have already posted, that I have found a way to see the blue screen myself, I have to turn off my tv and then turn it on at the right time to see it, otherwise my tv simply does not display it.

As for my other point, you have now linked to another thread and looking at the information posted there, he is using 2x usb 3.0 hubs on both rear usb 3.0 ports, so yes it is very possible that the hubs are the reason for his issue.

Usb 3.0 is slower to init than usb 2.0 ports on vu+ boxes and as kexec checks for usb 3.0 it halts the process for a short time (to check for images on usb sticks), so it is possible that with his additional active hubs, this extra wait time is the reason for his box freezing at this point (perhaps his hubs don't react fast enough, once kexec continues), I don't know it's only a guess but nobody else seems to have this issue.

[rantanplan]

@Ev0
Thanks

Exactly, that's what error analysis is all about.
And that's exactly what it's all about when you have a user who is basically a developer himself.

He also gave it all as feedback and also suspects that there could be a connection with regard to the USB hard drives.

What is and remains important in this context is the fact that it leads to a complete image failure right here.
This is new and not pleasant for the user when it comes to it.

Because if the user uses the multiboot as desired, then these are also three images that have been set up.

Then they are all gone

From my point of view, one should simply deal with such things.

[Ev0]

I agree it should be fixed if possible, but without logs, how do we go about creating a fix for this specific issue ?

Do we just add an infinite delay to kexec to give any device enough time to react, and thus slow down the boot process for everyone ?

Your previous post says

VU+ images were previously fine.
The users had little or no interest in a multiboot solution.

In that respect nothing has changed, users have a choice if they want to use Mulitboot or not, if they choose not to enable mulitboot then the image is exactly as it has always been.

[rantanplan]

This isn't about me.

I don't have VU+ and see myself more as an 'advocate' of a very safe and reliable image.

A log of the start of an image that hangs in the Kexec is obviously not possible directly.

Whether and how you can delay, I can not judge.
However, it seems obvious that there is a connection here.
I'm glad that this is being considered as a potential problem.

[littlesat]

As far I know with kexec the dark blue screen is a standard…. I experienced it already with other kexec solutions and there at that point a menu is also shown where you can select a slot (not on enigma2 stuff). As Huevos or Evo die not see it I thought they made a kind of patch to remove it which is also strange as I expect it in an area where they share code with openatv.
Indeed when a startup file or so get corrupted and/or an image in slot 1,2,3 (and also slot 0), get corrupted the dark blue screen will get stuck. My question is when it happens does an usb stick with the recovery file resolve it? When not it could even better considered to change the usb recovery stuff with a kind of bypass for the startup file….’just to put a startup file on that stick and give it prio above what is in the flash from the box.
I understand that at the point where it really belongs that is the dark blue screen is not an easy task for us.
Of course we first need to know somehow why it could get stuck at the blue screen. But I still think having an option with a startup file on an usb stick is a good feature.

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

[dpeddi]

From what I know, gigablue boxes doesn't have a recovery.

Is possible to do the same to save space with kexec by modify the image to write the file in flash in linuxrootfs1.

 

Then is possible to repack kexec by disabling completely the support to usb (this will reduce any delay and probably the annoying blue screen).

But if something went wrong with one of the image you have to reflash and loose all the images. Is a decision up to you.

 

We (openbh and openvix teams) decided to be more conservative and let the user to decide if continue without multiboot or use it.

[littlesat]

The same openpli has and all others. You can initiate it or don’t… I think checking for files on usb is less than a second…