|
[PATCH v2] ceph: inherit pkgconfig.bbclass
kai
From: Kai Kang <kai.kang@...>
According to oe-core commit 8e26252b45 layer.conf: Extend recipes not to install without explict dependencies pkgconfig-native is not deployed in sysroot by default any more. Inherit pkgconfig.bbclass to make it available for ceph. Signed-off-by: Kai Kang <kai.kang@...> --- v2: * correct referenced commit recipes-extended/ceph/ceph_15.2.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-extended/ceph/ceph_15.2.12.bb b/recipes-extended/ceph/ceph_15.2.12.bb index 6636d7a..693b525 100644 --- a/recipes-extended/ceph/ceph_15.2.12.bb +++ b/recipes-extended/ceph/ceph_15.2.12.bb @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://COPYING-LGPL2.1;md5=fbc093901857fcd118f065f900982c24 file://COPYING-GPL2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://COPYING;md5=4eb012c221c5fd4b760029a2981a6754 \ " -inherit cmake python3native python3-dir systemd +inherit cmake pkgconfig python3native python3-dir systemd # Disable python pybind support for ceph temporary, when corss compiling pybind, # pybind mix cmake and python setup environment, would case a lot of errors. -- 2.17.1
|
|
|
|
Re: [PATCH] ceph: inherit pkgconfig.bbclass
kai
On 10/19/21 10:04 AM, Kai wrote:
My fault. I referred to wrong commit. Thank you for pointing out. Regards,
-- Kai Kang Wind River Linux
|
|
|
|
Re: [PATCH] ceph: inherit pkgconfig.bbclass
kai
On 10/15/21 5:52 PM, Martin Jansa
wrote:
Sorry, just ref the commit in Yocto. Will ref to URL link next time. Regards,
-- Kai Kang Wind River Linux
|
|
|
|
Re: Issues with Setscene tasks
Bruce Ashfield
On Mon, Oct 18, 2021 at 3:30 PM Diego Sueiro <diego.sueiro@...> wrote:
I've actually been going through and fixing these as they pop up, and just had to do it for kubernetes: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?h=master-next&id=45e5f2e821784f0b55a41ee5f08d7acb98f8f288 If you were doing anything other than what you see that I did in that recipe, let me know. Otherwise, I'll make a similar change globally to the layer. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Issues with Setscene tasks
Diego Sueiro
Hi,
Recently I realized that we are having issues with setscene tasks (for docker-moby and cni recipes) where the packages were rebuild even already have their tasks in the sstate
mirror and bitbake-diffsigs not showing any difference. WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-r0/temp/log.do_package_qa_setscene.3335 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_package_qa_setscene) failed with exit code '1' - real task will be run instead WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-0/temp/log.do_package_write_rpm_setscene.3336 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_package_write_rpm_setscene) failed with exit code '1' - real task will be run instead WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-r0/temp/log.do_populate_lic_setscene.3337 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_populate_lic_setscene) failed with exit code '1' - real task will be run instead WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-r0/temp/log.do_populate_sysroot_setscene.3338 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_populate_sysroot_setscene) failed with exit code '1' - real task will be run instead WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-r0/temp/log.do_package_qa_setscene.3339 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_packagedata_setscene) failed with exit code '1' - real task will be run instead WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-r0/temp/log.do_package_setscene.3380 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_package_setscene) failed with exit code '1' - real task will be run instead WARNING: Logfile for failed setscene task is /<snip>/build/tmp/work/neoversen1-poky-linux/cni/v0.8.0+gitb5ab16f010e822936eb974690ecec38ba69afc01-r0/temp/log.do_deploy_source_date_epoch_setscene.3383 WARNING: Setscene task (/<snip>/layers/meta-virtualization/recipes-networking/cni/cni_git.bb:do_deploy_source_date_epoch_setscene) failed with exit code '1' - real task will be run instead ```
After some debugging I found that the “failed with exit code 1” comes from this line
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/sstate.bbclass#n764: localdata.setVar('SRCPV', d.getVar('SRCPV'))
Setting the SRCREV_FORMAT for cni and docker-moby recipes fixed the issue, but I also suspect that the following recipes are potentially having the same issue: ``` recipes-core/runx/runx_git.bb:PV = "v1.0-git${SRCREV_runx}" recipes-core/runv/runv_git.bb:PV = "0.4.0+git${SRCREV_runv}" recipes-containers/docker/docker-ce_git.bb:PV = "${DOCKER_VERSION}+git${SRCREV_docker}" recipes-containers/docker/docker-moby_git.bb:PV = "${DOCKER_VERSION}+git${SRCREV_moby}" recipes-containers/cri-o/cri-o_git.bb:PV = "1.22.0+git${SRCREV_cri-o}" recipes-containers/kubernetes/kubernetes_git.bb:PV = "v1.22.2+git${SRCREV_kubernetes}" recipes-containers/cri-tools/cri-tools_git.bb:PV = "1.21.0+git${SRCREV_cri-tools}" recipes-containers/crun/crun_git.bb:PV = "0.18+git${SRCREV_crun}" recipes-networking/cni/cni_git.bb:PV = "v0.8.0+git${SRCREV_cni}" recipes-devtools/yq/yq_git.bb:PV = "1.13.1+git${SRCREV_yq}" recipes-devtools/go/go-build_git.bb:PV = "0.1-git${SRCREV_runx}" ```
I can send a patch to fix cni and docker-moby but unfortunately I don’t have resources to test the other mentioned recipes.
--
|
|
|
|
Re: Building crun does not feth everything in do_fetch
#meta-virtualization
Bruce Ashfield
On Mon, Oct 18, 2021 at 8:59 AM <kovac167@...> wrote:
Ah yes, they've committed crimes in autogen.sh, that I hadn't noticed creeping in. I've bumped crun to the latest, and will confirm no network access before pushing. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Re: Building crun does not feth everything in do_fetch
#meta-virtualization
kovac167@...
Bruce,
Thank you for the response. I believe I am running into the same issue attempting to build podman with crun as the container runtime. These are the steps I have taken to reproduce the error:
- execute a build with podman & crun with networking enabled on the VM
- delete the tmp, cache, & sstate-cache directories from the build - save the downloads directory (for offline builds) - set the bb_no_network to 1 - disable networking on the VM - execute the build again offline It looks like the build is attempting to reach & out download yajl, even when the bb_no_network flag is set. When I remove the crun setting from podman, the build completes successfully.
Logs:
DEBUG: crun-0.18+gitf302dd8c02c6fddd2c50d1685d82b7a19aae8afe-r0 do_configure: Executing shell function do_configure
Submodule 'libocispec' (https://github.com/containers/libocispec.git) registered for path 'libocispec'
Submodule path 'libocispec': checked out 'fa3e8338c62ae482e509884ee2edaefc8e00499e'
Submodule 'image-spec' (https://github.com/opencontainers/image-spec) registered for path 'libocispec/image-spec'
Submodule 'runtime-spec' (https://github.com/opencontainers/runtime-spec) registered for path 'libocispec/runtime-spec'
Submodule 'yajl' (https://github.com/containers/yajl.git) registered for path 'libocispec/yajl'
Cloning into '/opt/roast/bitbake/build/tmp/work/corei7-64-gmit-linux/crun/0.18+gitf302dd8c02c6fddd2c50d1685d82b7a19aae8afe-r0/git/libocispec/yajl'...
fatal: unable to access 'https://github.com/containers/yajl.git/': Failed to connect to github.com port 443: Connection refused
fatal: clone of 'https://github.com/containers/yajl.git' into submodule path '/opt/roast/bitbake/build/tmp/work/corei7-64-gmit-linux/crun/0.18+gitf302dd8c02c6fddd2c50d1685d82b7a19aae8afe-r0/git/libocispec/yajl' failed
Failed to clone 'yajl' a second time, aborting
|
|
|
|
Re: [PATCH] criu: use a valid SRCREV
Bruce Ashfield
I was just finishing up a move to the master branch of the repository
toggle quoted messageShow quoted text
.. because it now seems that they are willing to force-push crui-dev. At the same time, I'm moving it to 3.16.1. But thanks for the patch, for a while, I thought I was seeing some local breakage when that commit disappeared! Bruce
On Mon, Oct 18, 2021 at 12:10 AM Chen Qi <Qi.Chen@...> wrote:
--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
[PATCH] criu: use a valid SRCREV
Chen Qi
Commit e49ce513c8df43e8d3b30b7acfbe7bd496d89862 is no longer in repo.
Use 95ead14874244f3c12e5970a74d1f4dd2433d652 instead, which is tagged 3.14. Signed-off-by: Chen Qi <Qi.Chen@...> --- recipes-containers/criu/criu_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-containers/criu/criu_git.bb b/recipes-containers/criu/criu_git.bb index 045a431..6b1b809 100644 --- a/recipes-containers/criu/criu_git.bb +++ b/recipes-containers/criu/criu_git.bb @@ -13,7 +13,7 @@ EXCLUDE_FROM_WORLD = "1" LIC_FILES_CHKSUM = "file://COPYING;md5=412de458544c1cb6a2b512cd399286e2" -SRCREV = "e49ce513c8df43e8d3b30b7acfbe7bd496d89862" +SRCREV = "95ead14874244f3c12e5970a74d1f4dd2433d652" PV = "3.14+git${SRCPV}" SRC_URI = "git://github.com/checkpoint-restore/criu.git;branch=criu-dev \ -- 2.33.0
|
|
|
|
Re: ip6tables executable not getting installed in dunfell
Bruce Ashfield
On Fri, Oct 15, 2021 at 8:49 AM Fabio Estevam <festevam@...> wrote:
ipv6 is always in my distro features, so I didn't notice that myself. I've added ipv6 to the required distros check of podman, so it will be caught in the future. Bruce ~# podman run hello-world -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Re: ip6tables executable not getting installed in dunfell
Bruce Ashfield
On Fri, Oct 15, 2021 at 9:00 AM Fabio Estevam <festevam@...> wrote:
There's definitely something different in your image composition than the core-image* (poky based) that are used in much of the (my) regular testing. In a systemd based image, you shouldn't need to specify the cgroup_manager ... crun yes, but that isn't all that common a configuration. From my build this morning: root@qemux86-64:~# podman run hello-world Trying to pull docker.io/library/hello-world:latest... Getting image source signatures Copying blob 2db29710123e done Copying config feb5d9fea6 done Writing manifest to image destination Storing signatures [ 170.623873] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 170.629244] cni-podman0: port 1(vetha3693c5d) entered blocking state [ 170.632659] cni-podman0: port 1(vetha3693c5d) entered disabled state [ 170.633441] device vetha3693c5d entered promiscuous mode [ 170.634203] cni-podman0: port 1(vetha3693c5d) entered blocking state [ 170.634938] cni-podman0: port 1(vetha3693c5d) entered forwarding state [ 170.635725] IPv6: ADDRCONF(NETDEV_CHANGE): cni-podman0: link becomes ready [ 170.783982] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation Hello from Docker! This message shows that your installation appears to be working correctly. <snip> root@qemux86-64:~# uname -a Linux qemux86-64 5.14.9-yocto-standard #1 SMP PREEMPT Wed Oct 6 11:28:32 UTC 2021 x86_64 GNU/Linux ---------------- If what you are seeing can be reproduced on master, and your image definitions are public, I'd be interested in seeing them, so I can expand the rdepends/requires of podman to make sure it pull in what it needs. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Re: ip6tables executable not getting installed in dunfell
Fabio Estevam
On 15/10/2021 09:49, Fabio Estevam wrote:
On 15/10/2021 01:40, Fabio Estevam wrote:I had to add a /etc/containers/libpod.conf file with the followingHi,After passing 'ipv6' into DISTRO_FEATURES, ip6tables gets installed. content: cgroup_manager = "cgroupfs" runtime = "/usr/bin/crun" And now podman can run: @iotgate:~# podman run hello-world .... Hello from Docker! This message shows that your installation appears to be working correctly. ... Thanks -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@...
|
|
|
|
Re: ip6tables executable not getting installed in dunfell
Fabio Estevam
On 15/10/2021 01:40, Fabio Estevam wrote:
Hi,After passing 'ipv6' into DISTRO_FEATURES, ip6tables gets installed. ~# podman run hello-world .... [ 207.201607] cni-podman0: port 1(veth6b661354) entered disabled state Error: systemd cgroup flag passed, but systemd support for managing cgroups is not available: OCI runtime error Does anyone know how to add systemd support for managing cgroups? Thanks, Fabio Estevam -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@...
|
|
|
|
Re: [PATCH] ceph: inherit pkgconfig.bbclass
Martin Jansa
On Fri, Oct 15, 2021 at 11:37 AM kai <kai.kang@...> wrote: From: Kai Kang <kai.kang@...> I think you should refer to this oe-core commit instead: pkgconfig-native is not deployed in sysroot by default any more. Inherit
|
|
|
|
[PATCH] ceph: inherit pkgconfig.bbclass
kai
From: Kai Kang <kai.kang@...>
According to oe-core commit 652fdf8719 sstate: Allow validation of sstate singatures against list of keys pkgconfig-native is not deployed in sysroot by default any more. Inherit pkgconfig.bbclass to make it work for ceph. Signed-off-by: Kai Kang <kai.kang@...> --- recipes-extended/ceph/ceph_15.2.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-extended/ceph/ceph_15.2.12.bb b/recipes-extended/ceph/ceph_15.2.12.bb index 6636d7a..693b525 100644 --- a/recipes-extended/ceph/ceph_15.2.12.bb +++ b/recipes-extended/ceph/ceph_15.2.12.bb @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://COPYING-LGPL2.1;md5=fbc093901857fcd118f065f900982c24 file://COPYING-GPL2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://COPYING;md5=4eb012c221c5fd4b760029a2981a6754 \ " -inherit cmake python3native python3-dir systemd +inherit cmake pkgconfig python3native python3-dir systemd # Disable python pybind support for ceph temporary, when corss compiling pybind, # pybind mix cmake and python setup environment, would case a lot of errors. -- 2.17.1
|
|
|
|
ip6tables executable not getting installed in dunfell
Fabio Estevam
Hi,
I am running the dunfell branch and I notice that ip6tables is not getting installed: # podman run hello-world Trying to pull docker.io/library/hello-world... Getting image source signatures Copying blob 93288797bd35 done Copying config 18e5af7904 done Writing manifest to image destination Storing signatures [ 41.667476] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 41.674442] cni-podman0: port 1(veth5ab23089) entered blocking state [ 41.680912] cni-podman0: port 1(veth5ab23089) entered disabled state [ 41.687634] device veth5ab23089 entered promiscuous mode [ 41.693058] audit: type=1700 audit(1634272456.424:3): dev=veth5ab23089 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 [ 41.694135] cni-podman0: port 1(veth5ab23089) entered blocking state [ 41.711492] cni-podman0: port 1(veth5ab23089) entered forwarding state [ 41.856399] audit: type=1325 audit(1634272456.604:4): table=nat family=2 entries=0 op=xt_register pid=481 comm="modprobe" [ 41.867521] audit: type=1325 audit(1634272456.612:5): table=nat family=2 entries=5 op=xt_replace pid=482 comm="iptables" [ 41.883462] audit: type=1325 audit(1634272456.632:6): table=nat family=2 entries=7 op=xt_replace pid=485 comm="iptables" [ 41.899451] audit: type=1325 audit(1634272456.648:7): table=nat family=2 entries=8 op=xt_replace pid=488 comm="iptables" [ 41.910483] audit: type=1325 audit(1634272456.656:8): table=nat family=2 entries=9 op=xt_replace pid=490 comm="iptables" ERRO[0004] Error adding network: could not initialize iptables protocol 1: exec: "ip6tables": executable file not found in $PATH ERRO[0004] Error while adding pod to CNI network "podman": could not initialize iptables protocol 1: exec: "ip6tables": executable file not found in $PATH [ 41.973531] cni-podman0: port 1(veth5ab23089) entered disabled state [ 41.981035] device veth5ab23089 left promiscuous mode [ 41.986213] cni-podman0: port 1(veth5ab23089) entered disabled state [ 41.986238] audit: type=1700 audit(1634272456.736:9): dev=veth5ab23089 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295 Error: error configuring network namespace for container 173dbac37c7b288e2a932ef9e6fa2c05c50a30305f46b1ddbd6208b8d77e76de: could not initialize iptables protocol 1: exec: "ip6tables": executable file not found in $PATH What could be the reason for ip6tables executable not getting installed? I have also cherry-picked the commit below to dunfell, but it did not help: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=35fce40e86c6cd475d24136c699ae1f2821dea85 Thanks, Fabio Estevam -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@...
|
|
|
|
nsenter installation in dunfell
Fabio Estevam
Hi Bruce,
Could you please cherry-pick the following commit into dunfell? https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-core?id=94501882dcf6eec411d68696e59953653c787eab It fixes the following run-time error when launching podman: Error: error configuring CNI network plugin: exec: "nsenter": executable file not found in $PATH Thanks, Fabio Estevam -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@...
|
|
|
|
Re: Building crun does not feth everything in do_fetch
#meta-virtualization
Bruce Ashfield
On Wed, Oct 13, 2021 at 10:18 AM Marc Wiz <mwyocto@...> wrote:
All of those dependencies are already specified in the recipe, and in any integration/build testing that I've done, they are all picked up properly. libocispec is directly specified in the SRC_URI and placed where crun will look for it, so that happens in the fetch task. yajl is specified in DEPENDS, so it will be in place in the recipe sysroot before compilation starts. You get a build error without yajl, so it is properly in place for the builds that I'm doing. Bruce Thanks, -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Building crun does not feth everything in do_fetch
#meta-virtualization
Marc Wiz
I recently discovered a couple of issues with building crun.
The first issue is when using a proxy to download source. crun depends on libocispec which is a git sub-module. The proxy environment variables are apparently not passed or recognized by the git sub-module code . The fix is to add the proxy configuration into the git configuration. The real issue IMHO is that crun depends on libocispec which depends on yajl. Yajl is not downloaded until the compile task for crun is executed. This breaks offline builds. So I am wondering what the best way is to address this? It seems to me that the Makefiles for libocispec and yajl would need to be modified and the recipe for crun would need to be modified to fetch the dependencies. Thanks, Marc
|
|
|
|
Re: [hardknott][PATCH] k3s: Bump to v1.20.11+k3s2
Bruce Ashfield
On Tue, Oct 12, 2021 at 2:02 PM Bruce Ashfield <bruce.ashfield@...> wrote:
Ooops. My mistake, I read that version number as 1.21, not 1.20. This is fine for hardknott and won't interfere with my master / release branch bumps. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|