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.

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

 

vuduo4k needs extra sleep

Thanks for the test.

I hope you fix this.

And I will update the necessary files on the git.

 

4 seconds sleep rear connector (usb3) FAILURE

4 seconds sleep front connector (usb2) OK

so i should put about 12-13 seconds sleep to get usb3 stick to work... i think is too much

vuduo4k needs extra sleep