592 replies to this topic

[Huevos]

 

 

The ofgwrite is compatible with this system. That is how we couch flash our images. Anyway it appears from your random comments you haven't tried it yet.

You will not flash the new image with modified Layout via ofgwrite.
You have to flash it via USB and use it to activate the changed layout.
 

Wrong

 

+1.

 

These images can be flash by USB and couch flashed with ofgwrite.

 

No idea why people jump to conclusions without knowing the facts.

[Huevos]

'has a recovery image' -> Now we get to the point.... note these recovery images are not depended on the image builders... this is something 'general' that prepares the box for multiboot.... The same thing I also prefer for VU+...

Waiting for Vu is a pipe dream.

 

There is no need for you to merge anything you don't want to. This already works with PLi, so the users now have the multiboot option for Vu hardware but if PLi aren't interested in the patch it means the users will need to flash a 3rd party image to get PLi to multiboot.

[Huevos]

 

Again is SHOULD not be image depended... it should be something that divide the flash as it should be and arrange a kind of bootloader is added so the correct image is booted at a reboot or power on.... In all other hardware it is not IN the oimage....

 

Simple question 

Who will do this ?  Vu + is dead silent for this project 

 

+1

 

The bottom line is PLi want the manufacturers to run the BSP for them, so if something requires a change to BSP and the manufacturer doesn't do it, it won't get in to the PLi image.

Edited by Huevos, 8 March 2023 - 13:43.

[neo]

Question is if VU+ is still a manufacturer at the moment .

 

All BSP's are currently under PLi's own control (I helped set that up), and personally I think PLi should look at this, test this, and then come with a decision, as I think much of the responses are speculation without any knowledge of the proposed solution.

 

I think for developers multiboot is invaluable, so you always have a working image at hand. The other day, I nearly bricked a VU+ while testing, which is my living room box, so I couldn't watch TV.

 

What I do wonder (based on this topic), if there is no recovery menu, how do you select a different slot to boot from in case the current/active slot is bricked and doesn't boot? If that doesn't exist, the solution is of limited use.

Edited by neo, 8 March 2023 - 14:14.

[Ev0]

What I do wonder (based on this topic), if there is no recovery menu, how do you select a different slot to boot from in case the current/active slot is bricked and doesn't boot? If that doesn't exist, the solution is of limited use.

You have 3 ways to get to the base (recovery) image in that eventuality.

1) if you are in a multiboot image, you can select Recovery Mode.
2) if you have an image that is in a crash loop for example, you can put a blank file called STARTUP_RECOVERY onto the usb stick or hdd installed in the box, then power off and on the box (or press and hold the power button on the remote for 12 seconds to force a reboot).
3) If you are stuck at bootloader splash screen for any reason, you can put that same blank STARTUP_RECOVERY file onto a fat32 formatted usb stick, insert in the front, remove any usb from the rear, power off and on again and it will boot the recovery iamge.

Edited by Ev0, 8 March 2023 - 14:15.

[neo]

Ok, so there is a recovery image, I missed that in the discussion above.

 

Seems doable for a technical savvy person, probably less so for an end-user.

 

Flashing principe works the same way as with other boxes: there is an USB image that is flashed the traditional way, erases the eMMC, partitions it, and flashes the image in slot 1, and a multiboot image that you can couch-flash into a slot of choice?

 

Is there someone that is willing to create a PR on https://github.com/O...eta/meta-vuplus so it can be tested and/or adapted to our build process?

Edited by neo, 8 March 2023 - 14:19.

[Ev0]

This maybe will clear up some confusion.

https://board.openbh.net/threads/howto-vu-multiboot-in-openbh-5-2.3119/

[neo]

Thanks !

[rantanplan]

https://forum.mbreme...26303cf83a39c33

https://forums.openp...iboot-in-flash/

Those who wanted it used it for a long time and used it for their purposes.

 

[Ev0]

https://forum.mbreme...26303cf83a39c33

https://forums.openp...iboot-in-flash/

Those who wanted it used it for a long time and used it for their purposes.

 

But with that solution, you use the wrong kernel to get an image to boot, also it repartitions the flash.

Also unless I missed it, no option to use usb for additional slots (or instead of eMMC).

[neo]

Was just about to write the same. And also a lot of manual and non-standard work.

 

OpenPLi is an end-user image, if it is implemented, it must work as seamless (and similar) for end-users as the multiboot solutions from other vendors. Without all sorts of VU+ specific hacks in E2.

[twol]

Vu+ Multiboot - so to summarise many of the above points.

1. its not a Neutrino system, so doesn,t change the standard way of building Vu images used by OpenPli or the OE-A images
2. All OE-A images use the same build environment for their images, the same Vu+ meta and the same ofgwrite
3. In terms of E2 and Vu4K boxes, the OpenViX/OpenBH image will quite happily run as a single partition image

4. IF the user wants he can initiate a Multiboot system using the eMMC that can host quite happily any image (flashed using the OE-A ofgwrite) that uses as a basis the multiboot code written by Littlesat some moons ago.

5. Also if the user wants he can flash (using the same OE-A ofgwrite) an image to a USB hdd, used for holding the images.
This latter implementation does require a small change to multiboot.py to convert the UUID in the STARTUP files, to the actual mount used in the image. 
The UUID was used to handle multiple HDD devices and switching of mounts, so that we always identify the correct USB image drive.

Overall, this implementation is very simple and straightforward compared to a certain HiSilicon box that uses an external device for images.
Like Rantanplan, I can never understand why users want to load up many images (often 10+), but for my uses multiboot is a great tool & test bed.

[rantanplan]

 

https://forum.mbreme...26303cf83a39c33

https://forums.openp...iboot-in-flash/

Those who wanted it used it for a long time and used it for their purposes.

 

But with that solution, you use the wrong kernel to get an image to boot, also it repartitions the flash.

Also unless I missed it, no option to use usb for additional slots (or instead of eMMC).

 

Since 2019, that is the actual statement.
As you can see, the topic linked above has been discussed for a long time without any great feedback.
Rather the trend towards 'actually doesn't matter'.
Over 4 pages in 4 years it didn't matter.
Now ?

What's happening?

So if multiboot is so important, then one wonders why not everyone just uses it.

All other images can also be installed here via ofgwrite.
Just as described above by BH, the 'Multiboot' image must first be installed, otherwise it won't work.

The issue of the 'rescue image' is not considered.

Seems to be a nice feature 'NiceToHave' for some.
But for most users who don't reflash their image daily or just wait for the next update stamp, it's of no value.
It will bother you more than it will help.

From my point of view, this means saying goodbye to a way of simply using an image without worrying.
 

Edited by rantanplan, 8 March 2023 - 16:55.

[twol]

 

 

https://forum.mbreme...26303cf83a39c33

https://forums.openp...iboot-in-flash/

Those who wanted it used it for a long time and used it for their purposes.

 

But with that solution, you use the wrong kernel to get an image to boot, also it repartitions the flash.

Also unless I missed it, no option to use usb for additional slots (or instead of eMMC).

 

Since 2019, that is the actual statement.
As you can see, the topic linked above has been discussed for a long time without any great feedback.
Rather the trend towards 'actually doesn't matter'.
Over 4 pages in 4 years it didn't matter.
Now ?

What's happening?

So if multiboot is so important, then one wonders why not everyone just uses it.

All other images can also be installed here via ofgwrite.
Just as described above by BH, the 'Multiboot' image must first be installed, otherwise it won't work.

The issue of the 'rescue image' is not considered.

Seems to be a nice feature 'NiceToHave' for some.
But for most users who don't reflash their image daily or just wait for the next update stamp, it's of no value.
It will bother you more than it will help.

From my point of view, this means saying goodbye to a way of simply using an image without worrying.
 

 

Actually the user installs a normal Vu+4k image that can initiate a multiboot system.
.. and naturally we looked at and provide recovery ... and as there no changes to the basic Vu+ system, in worst case you can just usb flash a Vu+ image.
The E2 code used is obviously open source (not surprisingly PureE2 picked it up instantly), so most images can pick up the additional code without too much issue.

 

Lastly, being able to flash online a new image, with instant fallback to the current image if issues, is the biggest user plus for a multiboot system

Edited by twol, 8 March 2023 - 17:25.

[rantanplan]

Lastly, being able to flash online a new image, with instant fallback to the current image if issues, is the biggest user plus for a multiboot system

 

This sounds so good and easy, but...
You can see it yourself in the OBH forum, the user has to pay attention and understand that it is intended that way.

It all leads to a lot of problems and it has nothing to do with me.

Again, I really don't care.
Because of me, any technical toy and then I'll understand.

But I assumed there was a lot of interest in creating and distributing an image that was as easy to use as possible.

The user gets a flash guide and that's it.
From my point of view, the user now gets something that most people will say.
What?

I know that a few people find this quite good and certainly a few who are still tinkering with images may use it, but for most it's really more complicated than you or you want to see.

Even the last enigma2 freaks will get out at some point.

But, I have nothing to say.
Only give feedback that is not well received.
That's what happens when you give feedback.
 

[Matrix10]

 

"The user gets a flash guide and that's it."

 

And for that, some people need a few days to learn.

Actually, it took me two days, many years ago.

 

 

 

It is not clear to me why the pessimistic reactions.

I don't see any serious counter arguments for that.

I also rarely use multiboot, but I have nothing against there being such a possibility.

Let's say I can try other images or maybe they have some addition

or the plugin that doesn't have an image that I use the most.

e.t.c

Edited by Matrix10, 8 March 2023 - 23:36.

[Guest-*0823016*]

I share the whole discussion but as a simple home user I used the multiboot years ago to try custom skins.
Having said that today if I want to try another image I save the mounted one and load the new one from USB.
I try if I like it, otherwise I simply return with the one I had previously saved with USB. Obviously I saved the tested one for any developments of the same to try again. For the common user the multiboot I think it's useless but for the "curious" of other people's images it's a lot.

krime mobile

[littlesat]

A recovery image mechanism is mandatory here for a real multiboot system. How it is made now you need an image that tweaks it. A recovery mechanism is not image depended.

[twol]

A recovery image mechanism is mandatory here for a real multiboot system. How it is made now you need an image that tweaks it. A recovery mechanism is not image depended.

which is why the generated STARTUP'S include a Recovery STARTUP just like all receivers with Recovery and OpenPli like most images can boot directly to it.
As for USB installed images, if you are on an image on the usb drive and you disconnect the usb drive, it will boot to Recovery.
... and like ALL the multiboot receivers, at worst you just flash the box.
There is no magic here, the Vu4K receiver is setup as per any multiboot receiver with the appropriate STARTUP files. 

[littlesat]

Sounds what I suggested…. Create something that change the box for multiboot and not put stuff in an image is still not understood….