- OpenEmbedded - lists.linaro.org

CI RPB zeus builds rootfs corruption (ext2simg)

by Anibal Limon

Hi, I changed the RPB qcom-lt builds to use docker-buster-amd64 because we have been experimenting image corruption with ext2simg tool in new RPB zeus builds [1], there is a related bug report [1] and that's the reason why our Debian builds uses img2simg. I tried to use img2simg in Debian stretch but is an old version (5.x) and fails to create images when are small size (ramdisk). So it's a good opportunity to change the docker builder to Debian buster with a newer img2simg (8.x) tool in qcom-lt builds, I made the change in a way that doesn't affect current builds that uses Debian stretch [3] and give time to other users to switch (if needed). Regards, Anibal [1] https://validation.linaro.org/scheduler/job/1965964 [2] https://discuss.96boards.org/t/ext2simg-is-corrupting-custom-rootfs/8792 [3] https://git.linaro.org/ci/job/configs.git/commit/?id=2798029ae4a2772c9b51ef…

4 years, 2 months

2
2
0 0

meta-linaro support for ARM GCC 9.2-2019.12 toolchain

by Sumit Garg

Hi Everyone, We are pleased to announce that support for ARM GCC 9.2-2019.12 [1] toolchain has been added in meta-linaro [2]. - Support for ARM GCC 9.2 toolchain built from source, steps to use it: - Add <path-to-meta-linaro-repo>/meta-linaro-toolchain/ to BBLAYERS in conf/bblayers.conf. - Configure: GCCVERSION = "arm-9.2" in conf/local.conf. - Support for prebuilt ARM GCC 9.2 toolchain, steps to use it: - Add <path-to-meta-linaro-repo>/meta-linaro-toolchain/ to BBLAYERS in conf/bblayers.conf. - Configure: TCMODE = "external-arm" in conf/local.conf. - For AArch64 (eg. qemuarm64 machine in poky distro) - Configure: EXTERNAL_TOOLCHAIN = "<installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu" in conf/local.conf. - For AArch32 (eg. qemuarm machine in poky distro) - Configure: EXTERNAL_TOOLCHAIN = "<installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf" in conf/local.conf. Distro testing: =========== - poky distro (branch: zeus, machines: qemuarm and qemuarm64) - Build and boot tested. - RPB distro (branch: zeus, machine: dragonboard-410c) - Build and boot tested. - World builds (branch: zeus, machines: qemuarm and qemuarm64) for following layers: - poky/meta - poky/meta-poky - poky/meta-yocto-bsp - meta-openembedded/meta-oe - meta-openembedded/meta-python - meta-openembedded/meta-networking Known issues: =========== - mariadb build failure with ARM GCC 9.2 toolchain built from source: - Recipe fix patch [3] accepted in OE upstream. - Native tools dependency issues seen with multiple recipes (psmisc, xclock, ndisc6, dovecot, man-db, drbd-utils and unbound) when using prebuilt ARM GCC 9.2 toolchain. - Fixes posted in OE upstream [4] [5]. Reporting bugs: ============ Please report any issue here [6]. [1] https://developer.arm.com/tools-and-software/open-source-software/developer… [2] https://git.linaro.org/openembedded/meta-linaro.git/?h=master [3] https://patchwork.openembedded.org/patch/169296/ [4] https://patchwork.openembedded.org/patch/169289/ [5] https://patchwork.openembedded.org/series/22188/ [6] https://bugs.linaro.org/enter_bug.cgi?product=Linaro%20OpenEmbedded Happy hacking!, Regards, Sumit

4 years, 3 months

1
0
0 0

git:// access deprecated

by Denys Dmytriyenko

Hi, Was git:// access to git.linaro.org officially deprecated today of is it just temporary issue? http:// still works. Thanks. -- Denys

4 years, 4 months

3
2
0 0

Fwd: [CI-NOTIFY]: WaRP7 OpenEmbedded (warrior) - Build # 154 - Still Failing!

by Ryan Harkin

Hi Nico, My WaRP7 builds are failing because meta-clang has dropped warrior support from its master branch. The same problem will happen in oe-rpb's warrior branch, as you're also using meta-clang master. The meta-clang warrior branch is quite old and is missing a lot of the patches from master that I've been building with for a long time. I wanted to send a patch to fix oe-rpb, but I don't know if you'd prefer to use the last known good SHA from the meta-clang master branch, or to use their warrior branch. I'm not using clang, so for my WaRP7 builds, I've just reverted to the warrior branch to see if it builds, at least. Cheers, Ryan. ---------- Forwarded message --------- From: <ci_notify(a)linaro.org> Date: Thu, 14 Nov 2019 at 05:57 Subject: [CI-NOTIFY]: WaRP7 OpenEmbedded (warrior) - Build # 154 - Still Failing! To: <ryan.harkin(a)linaro.org> Hello CI User, This is notification from ci.linaro.org for project WaRP7 OpenEmbedded (warrior). The project WaRP7 OpenEmbedded (warrior) Build # 154 - Still Failing. Please check console output at https://ci.linaro.org/job/warp7-openembedded-warrior/154/ to view the results. Thanks!!! CI Team

4 years, 5 months

2
2
0 0

Re: openjdk is broken on zeus branch

by Nicolas Dechesne

On Wed, Nov 6, 2019 at 2:19 PM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > Yes, I did. > > On Wed, 6 Nov 2019 at 15:58, Nicolas Dechesne > <nicolas.dechesne(a)linaro.org> wrote: > > > > hi Maxim, > > > > your original email didn't make it to the mailing list.. not sure why, > > you might want to check. I am adding the list here again. > > > > On Wed, Nov 6, 2019 at 10:54 AM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > > > > > looks like it is. after this patch: > > > http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.… > > > I see error: > > > ERROR: ExpansionError during parsing > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb > > > Traceback (most recent call last): > > > File "Var <SRCPV>", line 1, in <module> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > > line 768, in get_srcrev(d=<bb.data_smart.DataSmart object at > > > 0x7faa98f59e48>, method_name='sortable_revision'): > > > raise FetchError("The SRCREV_FORMAT variable must be set > > > when multiple SCMs are used.\n"\ > > > > "The SCMs are:\n%s" % '\n'.join(scms)) > > > > > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV, > > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception > > > FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set > > > when multiple SCMs are used. > > > > I don't understand the situation. do we have a problem or did you fix it? > > > > and btw, are we really still using this recipe from 2014? or did you > > find that by accident? > > > yea fresh version of openjdk is in meta-java. But it has some issues > to compile on aarch64. > > Issue with meta-linaro can be fixed in a few ways: > 1. add SRCREV_FORMAT = "jdk8" and apply this patch > http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.… > > or > > 2. HG can allow to download tar balls. So we can switch from hg:// to https://. > > or > > 3. Simple drop openjdk from meta-linaro and fix meta-java version. > > For my issue meta-linaro/aarch64 was in ledge rp build. And parser > of .bb files started to fail on that recipe after we switched to zeus > branch. Because we don't need openjdk I simply removed it from ledge > rp layer. That fixed my current issue. But in general it will be good > to fix it. I think we should fix upstream. I think we used this recipe initially for the bring up, but it should be removed now. Would be nice to have some background on this recipe.. or at least someone who can confirm it's safe to be removed now. > > Maxim. > > > > The SCMs are: > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk8;name… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/corba;nam… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/hotspot;n… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxp;name… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxws;nam… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk;name=… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/langtools… > > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/nashorn;n… > > > > > > > > > > > > On Wed, 6 Nov 2019 at 12:33, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > > > > > > > Hi Nicolas, > > > > > > > > is that known bug? > > > > > > > > ---------- Forwarded message --------- > > > > From: Maxim Uvarov <maxim.uvarov(a)linaro.org> > > > > Date: Tue, 5 Nov 2019 at 23:09 > > > > Subject: openjdk is broken on zeus branch > > > > To: <openembedded(a)lists.linaro.org> > > > > > > > > > > > > It looks like ${AUTOREV} with hg tool project is broken. openjdk from > > > > meta-java also does not use AUTOREV. I'm not sure what is better fix > > > > for that - remove AUTOREV or fix it? > > > > > > > > BR, > > > > Maxim. > > > > > > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb: > > > > Exception during build_dependencies for AUTOREV | ETA: > > > > --:--:-- > > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb: > > > > Error during finalise of > > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb > > > > ERROR: ExpansionError during parsing > > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb > > > > Traceback (most recent call last): > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > > > line 1302, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart > > > > object at 0x7fddc1423b38>): > > > > for name in self.names: > > > > > self.revisions[name] = srcrev_internal_helper(self, d, name) > > > > > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > > > line 1167, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at > > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>, > > > > name='jdk8'): > > > > if srcrev == "AUTOINC": > > > > > srcrev = ud.method.latest_revision(ud, d, name) > > > > > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > > > line 1558, in Hg.latest_revision(ud=<bb.fetch2.FetchData object at > > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>, > > > > name='jdk8'): > > > > revs = bb.persist_data.persist('BB_URI_HEADREVS', d) > > > > > key = self.generate_revision_key(ud, d, name) > > > > try: > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > > > line 1570, in Hg.generate_revision_key(ud=<bb.fetch2.FetchData object > > > > at 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at > > > > 0x7fddc1423b38>, name='jdk8'): > > > > def generate_revision_key(self, ud, d, name): > > > > > key = self._revision_key(ud, d, name) > > > > return "%s-%s" % (key, d.getVar("PN") or "") > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/hg.py", > > > > line 225, in Hg._revision_key(ud=<bb.fetch2.FetchData object at > > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>, > > > > name='jdk8'): > > > > """ > > > > > return "hg:" + ud.moddir > > > > > > > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV, > > > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception > > > > AttributeError: 'FetchData' object has no attribute 'moddir'

4 years, 5 months

1
0
0 0

Re: openjdk is broken on zeus branch

by Nicolas Dechesne

hi Maxim, your original email didn't make it to the mailing list.. not sure why, you might want to check. I am adding the list here again. On Wed, Nov 6, 2019 at 10:54 AM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > looks like it is. after this patch: > http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.… > I see error: > ERROR: ExpansionError during parsing > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb > Traceback (most recent call last): > File "Var <SRCPV>", line 1, in <module> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > line 768, in get_srcrev(d=<bb.data_smart.DataSmart object at > 0x7faa98f59e48>, method_name='sortable_revision'): > raise FetchError("The SRCREV_FORMAT variable must be set > when multiple SCMs are used.\n"\ > > "The SCMs are:\n%s" % '\n'.join(scms)) > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV, > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception > FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set > when multiple SCMs are used. I don't understand the situation. do we have a problem or did you fix it? and btw, are we really still using this recipe from 2014? or did you find that by accident? > The SCMs are: > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk8;name… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/corba;nam… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/hotspot;n… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxp;name… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxws;nam… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk;name=… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/langtools… > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/nashorn;n… > > > > On Wed, 6 Nov 2019 at 12:33, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > > > Hi Nicolas, > > > > is that known bug? > > > > ---------- Forwarded message --------- > > From: Maxim Uvarov <maxim.uvarov(a)linaro.org> > > Date: Tue, 5 Nov 2019 at 23:09 > > Subject: openjdk is broken on zeus branch > > To: <openembedded(a)lists.linaro.org> > > > > > > It looks like ${AUTOREV} with hg tool project is broken. openjdk from > > meta-java also does not use AUTOREV. I'm not sure what is better fix > > for that - remove AUTOREV or fix it? > > > > BR, > > Maxim. > > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb: > > Exception during build_dependencies for AUTOREV | ETA: > > --:--:-- > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb: > > Error during finalise of > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb > > ERROR: ExpansionError during parsing > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb > > Traceback (most recent call last): > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > line 1302, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart > > object at 0x7fddc1423b38>): > > for name in self.names: > > > self.revisions[name] = srcrev_internal_helper(self, d, name) > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > line 1167, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>, > > name='jdk8'): > > if srcrev == "AUTOINC": > > > srcrev = ud.method.latest_revision(ud, d, name) > > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > line 1558, in Hg.latest_revision(ud=<bb.fetch2.FetchData object at > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>, > > name='jdk8'): > > revs = bb.persist_data.persist('BB_URI_HEADREVS', d) > > > key = self.generate_revision_key(ud, d, name) > > try: > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py", > > line 1570, in Hg.generate_revision_key(ud=<bb.fetch2.FetchData object > > at 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at > > 0x7fddc1423b38>, name='jdk8'): > > def generate_revision_key(self, ud, d, name): > > > key = self._revision_key(ud, d, name) > > return "%s-%s" % (key, d.getVar("PN") or "") > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/hg.py", > > line 225, in Hg._revision_key(ud=<bb.fetch2.FetchData object at > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>, > > name='jdk8'): > > """ > > > return "hg:" + ud.moddir > > > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV, > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception > > AttributeError: 'FetchData' object has no attribute 'moddir'

4 years, 5 months

1
0
0 0

OE RPB and Zeus release

by Nicolas Dechesne

hi there, I've pushed all needed changes to get started with Zeus builds for the Linaro OE RPB CI: * created zeus branch on meta-backports, meta-qcom * created zeus branch on oe-rpb-manifest * i did not create zeus and i am keeping master for meta-rpb, meta-96boards, meta-linaro. it's compatible, at least for now * our zeus manifest is using master for other layers when they don't have a zeus branch Build #1 is scheduled for now.. we will see how bad it goes. I have also create the qcom/zeus branch (I recall that it is a stripped down version of the overall Linaro manifest that only focuses on Qualcomm BSP). Of course, if you can keep an eye on builds and help fixing issues, that would be much appreciated. cheers nico

4 years, 6 months

2
2
0 0

[meta-linaro][PATCH] layer.conf: Update to zeus release name series

by Martin Jansa

Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> --- meta-aarch64/conf/layer.conf | 2 +- meta-bigendian/conf/layer.conf | 2 +- meta-ilp32/conf/layer.conf | 2 +- meta-linaro-integration/conf/layer.conf | 2 +- meta-linaro-toolchain/conf/layer.conf | 2 +- meta-linaro/conf/layer.conf | 2 +- meta-optee/conf/layer.conf | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/meta-aarch64/conf/layer.conf b/meta-aarch64/conf/layer.conf index ffa0b19..9bd8f47 100644 --- a/meta-aarch64/conf/layer.conf +++ b/meta-aarch64/conf/layer.conf @@ -13,4 +13,4 @@ BB_DANGLINGAPPENDS_WARNONLY = "true" LAYERDEPENDS_aarch64 = "linaro linaro-toolchain" -LAYERSERIES_COMPAT_aarch64 = "warrior" +LAYERSERIES_COMPAT_aarch64 = "zeus" diff --git a/meta-bigendian/conf/layer.conf b/meta-bigendian/conf/layer.conf index a1f3687..be884b9 100644 --- a/meta-bigendian/conf/layer.conf +++ b/meta-bigendian/conf/layer.conf @@ -8,4 +8,4 @@ BBFILE_COLLECTIONS += "bigendian" BBFILE_PATTERN_bigendian := "^${LAYERDIR}/" BBFILE_PRIORITY_bigendian = "20" -LAYERSERIES_COMPAT_bigendian = "warrior" +LAYERSERIES_COMPAT_bigendian = "zeus" diff --git a/meta-ilp32/conf/layer.conf b/meta-ilp32/conf/layer.conf index 39e60f5..744a171 100644 --- a/meta-ilp32/conf/layer.conf +++ b/meta-ilp32/conf/layer.conf @@ -13,4 +13,4 @@ BB_DANGLINGAPPENDS_WARNONLY = "true" LAYERDEPENDS_ilp32 = "linaro linaro-toolchain" -LAYERSERIES_COMPAT_ilp32 = "warrior" +LAYERSERIES_COMPAT_ilp32 = "zeus" diff --git a/meta-linaro-integration/conf/layer.conf b/meta-linaro-integration/conf/layer.conf index 323f467..f0965ed 100644 --- a/meta-linaro-integration/conf/layer.conf +++ b/meta-linaro-integration/conf/layer.conf @@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "linaro-integration" BBFILE_PATTERN_linaro-integration := "^${LAYERDIR}/" BBFILE_PRIORITY_linaro-integration = "30" -LAYERSERIES_COMPAT_linaro-integration = "warrior" +LAYERSERIES_COMPAT_linaro-integration = "zeus" # do not error out on bbappends for missing recipes BB_DANGLINGAPPENDS_WARNONLY = "true" diff --git a/meta-linaro-toolchain/conf/layer.conf b/meta-linaro-toolchain/conf/layer.conf index 995f81e..92a5ed5 100644 --- a/meta-linaro-toolchain/conf/layer.conf +++ b/meta-linaro-toolchain/conf/layer.conf @@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "linaro-toolchain" BBFILE_PATTERN_linaro-toolchain := "^${LAYERDIR}/" BBFILE_PRIORITY_linaro-toolchain = "30" -LAYERSERIES_COMPAT_linaro-toolchain = "warrior" +LAYERSERIES_COMPAT_linaro-toolchain = "zeus" # do not error out on bbappends for missing recipes BB_DANGLINGAPPENDS_WARNONLY = "true" diff --git a/meta-linaro/conf/layer.conf b/meta-linaro/conf/layer.conf index 5b1f29e..f7df72b 100644 --- a/meta-linaro/conf/layer.conf +++ b/meta-linaro/conf/layer.conf @@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "linaro" BBFILE_PATTERN_linaro := "^${LAYERDIR}/" BBFILE_PRIORITY_linaro = "25" -LAYERSERIES_COMPAT_linaro = "warrior" +LAYERSERIES_COMPAT_linaro = "zeus" # do not error out on bbappends for missing recipes (mysql5) BB_DANGLINGAPPENDS_WARNONLY = "true" diff --git a/meta-optee/conf/layer.conf b/meta-optee/conf/layer.conf index e5b3320..17b4fb4 100644 --- a/meta-optee/conf/layer.conf +++ b/meta-optee/conf/layer.conf @@ -8,4 +8,4 @@ BBFILE_COLLECTIONS += "meta-optee" BBFILE_PATTERN_meta-optee := "^${LAYERDIR}/" BBFILE_PRIORITY_meta-optee = "8" -LAYERSERIES_COMPAT_meta-optee = "warrior" +LAYERSERIES_COMPAT_meta-optee = "zeus" -- 2.17.1

4 years, 6 months

2
1
0 0

/var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior

by Ryan Harkin

Hi, I have a working system based on Sumo. The system boots with a read-only rootfs, then applies are read-write overlay for /etc. When I migrate to Warrior, systemd-resolved fails to start. If I mount the same rootfs via NFS, it starts and works fine. systemd-timesyncd is also failing, but I haven't looked into that yet. It also works fine on the NFS mounted system. The resolve problem seems to be caused by two things: - /var/volatile is read-only - /run/systemd/resolve has the wrong ownership drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23 resolve/ I think this permissions problem may be a result of the /var/volatile mounting problems; it looks fine on the NFS mounted system. If I manually mount /var/volatile (it's in fstab) and change the ownership on /run/systemd/resolve, the service starts just fine. I also notice that /tmp is not mounted at all, which may be related. Here are the various tmp mount points on my read-only rootfs: $ mount | grep tmp devtmpfs on /dev type devtmpfs (rw,nosuid,size=112036k,nr_inodes=28009,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) overlay on /etc type overlay (rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=23840k,mode=700) On the NFS mounted system, I see these: $ mount | grep tmp devtmpfs on /dev type devtmpfs (rw,relatime,size=118180k,nr_inodes=29545,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) tmpfs on /tmp type tmpfs (rw,nosuid,nodev) tmpfs on /var/volatile type tmpfs (rw,relatime) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=23840k,mode=700) As you can see, NFS has these extra mounts: tmpfs on /tmp type tmpfs (rw,nosuid,nodev) tmpfs on /var/volatile type tmpfs (rw,relatime) I've tried reverting a few commits that may be related, but I haven't had any luck working out things have changed, eg: c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available [Matt Hoosier] Advice would be appreciated. Are there any particular areas I should be looking to work out what's going wrong? Kind regards, Ryan.

4 years, 9 months

1
0
0 0

widevine support

by tarani.nomula＠yahoo.com

Hi Team, I have downloaded the lhg-oe-manifest source and builded it successfully for Dragonboard-410c.After flashing it on device i am only able to play the clearkey encrypted video but when i am trying to play the widevine encrypted content,it is showing like there is no supported key system.Is there any support of playing widevine encrypted content in this code.If not can you help me how to play widevine encrypted video.I have downloaded the code from below manifest $repo init -u https://github.com/linaro-mmwg/lhg-oe-manifests.git -b morty It would be a great help for me if you provide me any way to get out of it. Thanks and RegardsN.Tarani

4 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

OpenEmbedded