592 replies to this topic

[littlesat]

Indeed what the user sees could be just ‘prepare multiboot’ or so

[littlesat]

Indeed what the user sees could be just ‘prepare multiboot’ or so

The other one was already in as far I know

[neo]

The other one was already in as far I know

 

These are for 8.3-release, and both still open.
 

[littlesat]

I do not decide alone if we should backport this to 8.3… it is not a fix. Basically it is a new feature that should not be backported.

Edited by littlesat, 3 April 2023 - 20:39.

[neo]

As I understand it, it is needed if you want to flash/install a current release on a box that is prepared for multiboot.

 

Since I haven't seen anything about the current state of develop and/or a release 9, it might not be a bad idea.

[Abu Baniaz]

I do not decide alone if we should backport this to 8.3… it is not a fix. Basically it is a new feature that should not be backported.

 

I think it would be a good idea to backport the function to allow rebooting into different image for the affected boxes. Otherwise if you were to flash 8.3 to into a directory/slot, you cannot then reboot into into another image in a simple manner.

I think this is the commit: https://github.com/O...e7532960975bf6c

[Guest-*0823016*]

Only BH can answer that...

I think it's a long story perhaps dictated by....
VTi seems to me to be online

krime mobile

Where is BH to replicate

krime mobile

[littlesat]

That commit is wrong.

[Dimitrij]

I do not decide alone if we should backport this to 8.3… it is not a fix. Basically it is a new feature that should not be backported.

It's just compatibility.

This makes it possible to return to the recovery slot.

I checked these changes yesterday, everything is ok.

 

The only downside is that it needs to be update ofgwrite for 8.3("4.6.2"   --> "4.6.5")

Edited by Dimitrij, 4 April 2023 - 06:08.

[Dimitrij]

https://github.com/O...orefs.conf#L176

-SRCREV_pn-ofgwrite ??= "f45fe98197a0c34f4011878d2f5978e6e67dea7c"
+SRCREV_pn-ofgwrite ??= "07e156f2064a9b6d5d15b0773be85ea8221af54d"

 

[littlesat]

It's just compatibility.

This makes it possible to return to the recovery slot.

I checked these changes yesterday, everything is ok.

 

The only downside is that it needs to be update ofgwrite for 8.3("4.6.2"   --> "4.6.5")

This is the second change for 8.3.... 8.3 is stable so we prefer basically not to add features to it... contra you can use it as multiboot when it is adapted that has added value. The OpenPLi team needs to make a decision here if we backport it yes or no....

[Dimitrij]

This is not a new feature, but simple compatibility.
I remind you that 8.3 is the last image with python 2.7 and many users will put it in the new multiboot as stable.
But they won't be able to move to another slot.
Why don't we help users?
I checked everything myself, there are no problems.
And a new version ofgwfite, what's the problem with updating it?

[neo]

+1

[littlesat]

I agree but it is not only to mee.

[neo]

Who else needs to agree? Then we can give those people a nudge to respond here, instead of wait until they do...

[littlesat]

Openpli core members. Not only dima and me

Edited by littlesat, 4 April 2023 - 19:56.

[Tech]

Something is not okay....also the license file conf/license/license-close.inc is missing

ERROR: vuplus-kexec-1.0-r1 do_install: ExecutionError('/home/andre/openpli/oe/develop/build/tmp/work/vuultimo4k-oe-linux-gnueabi/vuplus-kexec/1.0-r1/temp/run.do_install.120812', 1, None, None) 
ERROR: Logfile of failure stored in: /home/andre/openpli/oe/develop/build/tmp/work/vuultimo4k-oe-linux-gnueabi/vuplus-kexec/1.0-r1/temp/log.do_install.120812 
Log data follows: 
| DEBUG: Executing python function extend_recipe_sysroot 
| NOTE: Direct dependencies are ['/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/gcc/gcc-runtime_10.3.bb:do_populate_sysroot', '/home/andre/openpli/oe/develop/openembedded-core/meta
/recipes-devtools/gcc/gcc-cross_10.3.bb:do_populate_sysroot', 'virtual:native:/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', '/home/andre/
openpli/oe/develop/openembedded-core/meta/recipes-core/glibc/glibc_2.33.bb:do_populate_sysroot', '/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_popula
te_sysroot', 'virtual:native:/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot'] 
| NOTE: Installed into sysroot: [] 
| NOTE: Skipping as already exists in sysroot: ['gcc-runtime', 'gcc-cross-arm', 'pseudo-native', 'glibc', 'quilt-native', 'patch-native', 'linux-libc-headers', 'libgcc', 'xz-native', 'flex-native', 'binuti
ls-cross-arm', 'gnu-config-native', 'zlib-native', 'libmpc-native', 'libtool-native', 'gmp-native', 'autoconf-native', 'automake-native', 'mpfr-native', 'texinfo-dummy-native', 'attr-native', 'gettext-mini
mal-native', 'm4-native'] 

[rantanplan]

Openpli core members. Not only dima and me

And, if I'm somehow counted among them, then I still ask myself what exactly we're doing there.

So how am I supposed to accept something as a commit that I don't understand either because of the lack of hardware or purely logically.
There is a working boot system from the manufacturer and it is being changed new.

Where do the binaries come from?
There are no original binaries.

If I understand it correctly, the change is desired, because otherwise the images would not run properly in the "new mutiboot".
Therefore, a backport in 8.3 is also desired.

I'd rather fix or update something than break something that's intact.

And so this can't motivate everyone to just accept commits on command here.
I can't test them.

[rantanplan]

 

Something is not okay....also the license file conf/license/license-close.inc is missing

ERROR: vuplus-kexec-1.0-r1 do_install: ExecutionError('/home/andre/openpli/oe/develop/build/tmp/work/vuultimo4k-oe-linux-gnueabi/vuplus-kexec/1.0-r1/temp/run.do_install.120812', 1, None, None) 
ERROR: Logfile of failure stored in: /home/andre/openpli/oe/develop/build/tmp/work/vuultimo4k-oe-linux-gnueabi/vuplus-kexec/1.0-r1/temp/log.do_install.120812 
Log data follows: 
| DEBUG: Executing python function extend_recipe_sysroot 
| NOTE: Direct dependencies are ['/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/gcc/gcc-runtime_10.3.bb:do_populate_sysroot', '/home/andre/openpli/oe/develop/openembedded-core/meta
/recipes-devtools/gcc/gcc-cross_10.3.bb:do_populate_sysroot', 'virtual:native:/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', '/home/andre/
openpli/oe/develop/openembedded-core/meta/recipes-core/glibc/glibc_2.33.bb:do_populate_sysroot', '/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_popula
te_sysroot', 'virtual:native:/home/andre/openpli/oe/develop/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot'] 
| NOTE: Installed into sysroot: [] 
| NOTE: Skipping as already exists in sysroot: ['gcc-runtime', 'gcc-cross-arm', 'pseudo-native', 'glibc', 'quilt-native', 'patch-native', 'linux-libc-headers', 'libgcc', 'xz-native', 'flex-native', 'binuti
ls-cross-arm', 'gnu-config-native', 'zlib-native', 'libmpc-native', 'libtool-native', 'gmp-native', 'autoconf-native', 'automake-native', 'mpfr-native', 'texinfo-dummy-native', 'attr-native', 'gettext-mini
mal-native', 'm4-native'] 

 

typical copy&paste error.
https://github.com/O...lus-kexec.bb#L4

 

fix

Edited by rantanplan, 4 April 2023 - 21:35.

[neo]

* disclaimer: this is how I understand it
 

So how am I supposed to accept something as a commit that I don't understand either because of the lack of hardware or purely logically.
There is a working boot system from the manufacturer and it is being changed new.

 
Some time ago a few manufacturers came with a multiboot system, which gives you the option to install multiple images in parallel.
 
Given the way it is implemented, it is very probably that they've done this using kexec, a linux kernel call that allows you to boot a second kernel. The kernels are installed in seperate eMMC partitions, and the rootfs either in partitions or in subdirectories in a single partition (which is more space efficient). This all is hidden in the primary partition (call it slot 0) in which the recovery image is installed.
 
The recovery image gives you the option to flash directly from internet (using a bootconfig file in an OE-A repo) or from USB, to select an image to boot, etc. The boxes also have a hardware option (a box button or a remote buitton) to force the recovery to boot in case of problems.
 
VU+ hasn't done that, and with only 4GB eMMC, it doesn't really have the space for it either. It also doesn't have a hardware solution to force slot 0 to boot.
 
Now, someone thought "what they did, I can do for VU+".
 
The partition you currently flash the image in, is labeled "slot 0" and the image installed "the recovery image" (which technically is a full image you can use, until someone makes a minimal image for it).
 
In order to deal with the lack of space, there is no further partitioning, everything is installed in subdirectories, but it is using the same kexec system as the other manufacturers.
 

If I understand it correctly, the change is desired, because otherwise the images would not run properly in the "new mutiboot".
Therefore, a backport in 8.3 is also desired.

Most people find multiboot handy. Yes, there are people that love to install a zillion different images, but for developers and testers, it is handy to be able to fall back to an image that works, especially if you develop or test on a box your family also uses.
 
So, what do these commits do:

• They update systemInfo to register that VU+ 4K boxes are now multiboot capable
• They update systemInfo to inform Enigma where to find the info about slots and images
• They introduce the kexec binaries needed to boot a second kernel
• They add the option to create the slots, needed because the base image doesn't create the slot structure and it gives the option to use another device than eMMC (due to the 4GB limit)
• There is an updated ofgwrite needed because the location where a kernel is flashed is different from the manufacturer multiboot solutions

The backport of some of these  to 8.3-release is desired because there is (afaik) no timing available for an OpenPLi 9 stable release, and if you flash 8.3-release in a multiboot slot, you can never get out of it again because the slot selection is missing. So 8.3-release needs the upadted ofgwrite, and the systeminfo changes so the slot selection is shown in the standby menu.
 

Where do the binaries come from?
There are no original binaries.

 
I agree that the source for this binaries should be public, we're in the open source business after all.
 
We like to see what is in it, and compile then ourselfs. If only because there can (of often will be) binary differerences between images, think for example about libc versions.

Edited by neo, 4 April 2023 - 22:24.