592 replies to this topic

[babsy98]

in openATV I have not enabled the USB slots either because simply the file system on the USB stick quickly generates errors, depending on the quality of the USB stick, so I use that only in emmc and have no problems, I had understood that users use USB slots, is it, so ?

[rantanplan]

in openATV I have not enabled the USB slots either because simply the file system on the USB stick quickly generates errors, depending on the quality of the USB stick, so I use that only in emmc and have no problems, I had understood that users use USB slots, is it, so ?

No, USB is only used as a medium for external data carriers.
The assumption was made that this usage would have caused the problem.

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

 

I don't understand your attacks against me.


 if they have a destroyed box afterwards and you say that this was not tested at all.

 

No one is attacking anyone. I am just responding to what you posted.

 

Please explain how using kexec could destroy a box. All it does is stop one kernel and start another. Nothing permanent or that touches the boot loader. At the very worst, if something got corrupt you could just reflash same as with any image.

[dpeddi]

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

 

Kernel manipulation?!

 

Please take some time to read the documentation I wrote and stop making weird assumptions: https://github.com/B...kexec-multiboot

 

 

 

@ WanWizard


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.
 

 

Why? This demostrate that you didn't understood the solution.

 

Bootloader --> kernel+intramfs --> kexec --> kernel(guest) + intramfs --> Image

 

The risk of flash loss is the same then running an image.

 

From my point of view OpenMultiBoot (OMB) is more dangerous since it rewrite the kernel partition on every image switch so it stress the same block of the flash every time.

[littlesat]

As far I can see you always can restore the box with flashing a new image via USB via the bootloader that stay untouched…. But while doing so you will lost all the programmed slots. So there is as far I can see no way to brick a vu+ box.

I understood our solution now has a patched binary modified kernel without patch. It would be much better to get the real patch/change as source and no binary. Maybe I make a mistake here, as I’m also somehow lost….

[dpeddi]

As far I can see you always can restore the box with flashing a new image via USB via the bootloader that stay untouched…. But while doing so you will lost all the programmed slots. So there is as far I can see no way to brick a vu+ box.

I understood our solution now has a patched binary modified kernel without patch. It would be much better to get the real patch/change as source and no binary. Maybe I make a mistake here, as I’m also somehow lost….

https://github.com/B...kexec-multiboot

These are the source. Feel free to include in your bsp

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

 

Kernel manipulation?!

 

Please take some time to read the documentation I wrote and stop making weird assumptions: https://github.com/B...kexec-multiboot

 

 

 

@ WanWizard


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.
 

 

Why? This demostrate that you didn't understood the solution.

 

Bootloader --> kernel+intramfs --> kexec --> kernel(guest) + intramfs --> Image

 

The risk of flash loss is the same then running an image.

 

From my point of view OpenMultiBoot (OMB) is more dangerous since it rewrite the kernel partition on every image switch so it stress the same block of the flash every time.

 

An 'OpenMultiboot' has never received a recommendation from me or anyone who should test images.

Of course we agree on that.

We stay with the kexec and the only question that needs to be clarified....

Against the background of the kernel being changed in this way...
And you and Ev0 yourself spoke of possible problems regarding timing and USB in connection with the error pattern described...

Is it possible to rule out that the user only sees a 'Kexec blue screen' and that the USB ports may no longer respond?

What I mean exactly would be a starting Kexec from Flash and then nothing happens.
And under certain circumstances, the USB slots are no longer accessible because of this problem.

[littlesat]

These are the source. Feel free to include in your bsp

->

it is not our bsp as it is Vu’s bps.

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

 

Kernel manipulation?!

 

Please take some time to read the documentation I wrote and stop making weird assumptions: https://github.com/B...kexec-multiboot

 

 

 

@ WanWizard


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.
 

 

Why? This demostrate that you didn't understood the solution.

 

Bootloader --> kernel+intramfs --> kexec --> kernel(guest) + intramfs --> Image

 

The risk of flash loss is the same then running an image.

 

From my point of view OpenMultiBoot (OMB) is more dangerous since it rewrite the kernel partition on every image switch so it stress the same block of the flash every time.

 

An 'OpenMultiboot' has never received a recommendation from me or anyone who should test images.

Of course we agree on that.

We stay with the kexec and the only question that needs to be clarified....

Against the background of the kernel being changed in this way...
And you and Ev0 yourself spoke of possible problems regarding timing and USB in connection with the error pattern described...

Is it possible to rule out that the user only sees a 'Kexec blue screen' and that the USB ports may no longer respond?

What I mean exactly would be a starting Kexec from Flash and then nothing happens.
And under certain circumstances, the USB slots are no longer accessible because of this problem.

 

If USB is not accessible it will boot to recovery.

[rantanplan]

We're going in circles and that's not going to work.
I probably just don't get it, or I'm not able to make it clear.

[Abu Baniaz]

We know that there are no partitions created on the internal flash memory, directories are created. There was no straight forward answer as to whether they are fixed or dynamic sizes. There is no recovery partition,  there is no recovery image. Some image teams advocate not using the main (nigel) image so that you can always have a failsafe image. Other teams counter this idea and say to use it.

 

One of the other teams had a way to partition the flash memory. This has been discounted. And everybody seems to agree that Vu are not going to do anything either. 

 

Nobody is forced to use Kexec multiboot. So the people who don't want to use it can continue to use the receiver as they would normally do. Hopefully the ones who do, will get clear and concise information. If it goes belly up, flash by USB. 

[neo]

Directories are directories, there is no quota management, therefore they are dynamic in size.

 

Whether or not you need a failsafe image in slot 0 depends on how you use the box, i.e. can you afford it to go belly up?

[WanWizard]

On my Solo 4K, I have a develop build in slot 0 and slot 1. I'm using slot 1 on a daily basis, both for watching TV and and for testing.

 

I use slot 0 simply to be back up and running quicker then when I need to flash from USB + restore + autoinstall. For me a big improvement.

[Frenske]

I use slot 0 simply to be back up and running quicker then when I need to flash from USB + restore + autoinstall. For me a big improvement.

 

Exactly this is the way I use it too. Especially when the NB caused issues the last days. Eventually I went back to slot 0 and so the Mrs. is happy again. 

[cobus]

 

I use slot 0 simply to be back up and running quicker then when I need to flash from USB + restore + autoinstall. For me a big improvement.

 

Exactly this is the way I use it too. Especially when the NB caused issues the last days. Eventually I went back to slot 0 and so the Mrs. is happy again. 

 

Here Idem
 

[Pr2]

Hi,

 

I just test the multiboot and it is working fine on my Solo 4K and on my Duo 4K.

 

Can you please tell me where are the slot 1 to 3 created?

 

For people willing to test, you don't lose your current image which will be the one in slot 0.

 

But one remark, it is no longer possible to use online flash to flash slot 0, so I guess that it is normal and by design.

 

Thanks,

 

Pr2

Edited by Pr2, 28 May 2023 - 15:08.

[twol]

Hi,

 

I just test the multiboot and it is working fine on my Solo 4K and on my Duo 4K.

 

Can you please tell me where are the slot 1 to 3 created?

 

For people willing to test, you don't lose your current image which will be the one in slot 0.

 

But one remark, it is no longer possible to use online flash to flash slot 0, so I guess that it is normal and by design.

 

Thanks,

 

Pr2

Unable to flash Slot 0  - if that is correct then that is OpenPli, with the original code you can flash  slot 0.

[Huevos]

Hi,

 

I just test the multiboot and it is working fine on my Solo 4K and on my Duo 4K.

 

Can you please tell me where are the slot 1 to 3 created?

 

For people willing to test, you don't lose your current image which will be the one in slot 0.

 

But one remark, it is no longer possible to use online flash to flash slot 0, so I guess that it is normal and by design.

 

Thanks,

 

Pr2

You should be able to flash slot 0 unless someone has broken something. There seem to have been a large number of commits to FlashImage.py lately.

Edited by Huevos, 28 May 2023 - 16:18.

[Pr2]

OK here is how I proceed:

 

- I had OpenPLi Nightly Build in both box

- I go into Flash Image and  use the initialize button to enable multiboot

- it took a few minutes and reboot the box

- MultiBoot was enabled

- I flash OpenPli nighty build into slot 1

- Restart on slot 1.

- Auto-install does the job

 

So today I have slot 0 and slot 1 with the same image.

I am now running the box with image in slot 1.

 

Image is up to date.

 

I go into flash image and here are the possible options.

 

 FlashImage.jpg   140.42KB   2 downloads

 

As you can see I am running now the image in slot 1, and I have no option to flash to slot 0.

 

Info: screenshot taken on the Solo 4K

 

To be sure I boot to slot 0 and check the Flash Image and there is no option to flash slot 0 neither.

Edited by Pr2, 28 May 2023 - 16:38.

[Ev0]

OK here is how I proceed:

 

- I had OpenPLi Nightly Build in both box

- I go into Flash Image and  use the initialize button to enable multiboot

- it took a few minutes and reboot the box

- MultiBoot was enabled

- I flash OpenPli nighty build into slot 1

- Restart on slot 1.

- Auto-install does the job

 

So today I have slot 0 and slot 1 with the same image.

I am now running the box with image in slot 1.

 

Image is up to date.

 

I go into flash image and here are the possible options.

 

FlashImage.jpg

 

As you can see I am running now the image in slot 1, and I have no option to flash to slot 0.

Boot Slot 0, then see if you have the option