Re: [PATCH] libvirt: fix CVE-2021-3667
Bruce Ashfield
In master, I tend to favour uprev's versus specific CVE patches.
toggle quoted messageShow quoted text
That being said, I have a lot of pending changes right now, and won't have time to uprev for a few more weeks, so I've gone ahead and merged the change. Bruce In message: [meta-virtualization][PATCH] libvirt: fix CVE-2021-3667 on 23/11/2021 Xu, Yanfei wrote:
Backport a fix for CVE-2021-3667.
|
|
[hardknott][PATCH] libvirt: fix CVE-2021-3667
Xu, Yanfei
Backport a fix for CVE-2021-3667.
The CVE discription: An improper locking issue was found in the virStoragePoolLookupByTargetPath API of libvirt. It occurs in the storagePoolLookupByTargetPath function where a locked virStoragePoolObj object is not properly released on ACL permission failure. Clients connecting to the read-write socket with limited ACL permissions could use this flaw to acquire the lock and prevent other users from accessing storage pool/volume APIs, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability. Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1986094 Signed-off-by: Yanfei Xu <yanfei.xu@...> --- ...nlock-object-on-ACL-fail-in-storageP.patch | 40 +++++++++++++++++++ recipes-extended/libvirt/libvirt_6.3.0.bb | 1 + 2 files changed, 41 insertions(+) create mode 100644 recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch diff --git a/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch b/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch new file mode 100644 index 00000000..608322d9 --- /dev/null +++ b/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch @@ -0,0 +1,40 @@ +From d3e20e186ed531e196bb1529430f39b0c917e6dc Mon Sep 17 00:00:00 2001 +From: Peter Krempa <pkrempa@...> +Date: Wed, 21 Jul 2021 11:22:25 +0200 +Subject: [PATCH] storage_driver: Unlock object on ACL fail in + storagePoolLookupByTargetPath + +'virStoragePoolObjListSearch' returns a locked and refed object, thus we +must release it on ACL permission failure. + +Fixes: 7aa0e8c0cb8 +Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1984318 +Signed-off-by: Peter Krempa <pkrempa@...> +Reviewed-by: Michal Privoznik <mprivozn@...> + +Upstream-status: Backport +CVE-2021-3667 [https://bugzilla.redhat.com/show_bug.cgi?id=1986094] +Signed-off-by: Yanfei Xu <yanfei.xu@...> +--- + src/storage/storage_driver.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c +index ecb5b86b4f..de66f1f9e5 100644 +--- a/src/storage/storage_driver.c ++++ b/src/storage/storage_driver.c +@@ -1739,8 +1739,10 @@ storagePoolLookupByTargetPath(virConnectPtr conn, + storagePoolLookupByTargetPathCallback, + cleanpath))) { + def = virStoragePoolObjGetDef(obj); +- if (virStoragePoolLookupByTargetPathEnsureACL(conn, def) < 0) ++ if (virStoragePoolLookupByTargetPathEnsureACL(conn, def) < 0) { ++ virStoragePoolObjEndAPI(&obj); + return NULL; ++ } + + pool = virGetStoragePool(conn, def->name, def->uuid, NULL, NULL); + virStoragePoolObjEndAPI(&obj); +-- +2.27.0 + diff --git a/recipes-extended/libvirt/libvirt_6.3.0.bb b/recipes-extended/libvirt/libvirt_6.3.0.bb index e68053a7..d028366d 100644 --- a/recipes-extended/libvirt/libvirt_6.3.0.bb +++ b/recipes-extended/libvirt/libvirt_6.3.0.bb @@ -45,6 +45,7 @@ SRC_URI = "http://libvirt.org/sources/libvirt-${PV}.tar.xz;name=libvirt \ file://CVE-2020-25637_3.patch \ file://CVE-2020-25637_4.patch \ file://CVE-2021-3631.patch \ + file://0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch \ " SRC_URI[libvirt.md5sum] = "1bd4435f77924f5ec9928b538daf4a02" -- 2.27.0
|
|
[PATCH] libvirt: fix CVE-2021-3667
Xu, Yanfei
Backport a fix for CVE-2021-3667.
The CVE discription: An improper locking issue was found in the virStoragePoolLookupByTargetPath API of libvirt. It occurs in the storagePoolLookupByTargetPath function where a locked virStoragePoolObj object is not properly released on ACL permission failure. Clients connecting to the read-write socket with limited ACL permissions could use this flaw to acquire the lock and prevent other users from accessing storage pool/volume APIs, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability. Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1986094 Signed-off-by: Yanfei Xu <yanfei.xu@...> --- ...nlock-object-on-ACL-fail-in-storageP.patch | 40 +++++++++++++++++++ recipes-extended/libvirt/libvirt_7.2.0.bb | 1 + 2 files changed, 41 insertions(+) create mode 100644 recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch diff --git a/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch b/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch new file mode 100644 index 00000000..608322d9 --- /dev/null +++ b/recipes-extended/libvirt/libvirt/0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch @@ -0,0 +1,40 @@ +From d3e20e186ed531e196bb1529430f39b0c917e6dc Mon Sep 17 00:00:00 2001 +From: Peter Krempa <pkrempa@...> +Date: Wed, 21 Jul 2021 11:22:25 +0200 +Subject: [PATCH] storage_driver: Unlock object on ACL fail in + storagePoolLookupByTargetPath + +'virStoragePoolObjListSearch' returns a locked and refed object, thus we +must release it on ACL permission failure. + +Fixes: 7aa0e8c0cb8 +Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1984318 +Signed-off-by: Peter Krempa <pkrempa@...> +Reviewed-by: Michal Privoznik <mprivozn@...> + +Upstream-status: Backport +CVE-2021-3667 [https://bugzilla.redhat.com/show_bug.cgi?id=1986094] +Signed-off-by: Yanfei Xu <yanfei.xu@...> +--- + src/storage/storage_driver.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c +index ecb5b86b4f..de66f1f9e5 100644 +--- a/src/storage/storage_driver.c ++++ b/src/storage/storage_driver.c +@@ -1739,8 +1739,10 @@ storagePoolLookupByTargetPath(virConnectPtr conn, + storagePoolLookupByTargetPathCallback, + cleanpath))) { + def = virStoragePoolObjGetDef(obj); +- if (virStoragePoolLookupByTargetPathEnsureACL(conn, def) < 0) ++ if (virStoragePoolLookupByTargetPathEnsureACL(conn, def) < 0) { ++ virStoragePoolObjEndAPI(&obj); + return NULL; ++ } + + pool = virGetStoragePool(conn, def->name, def->uuid, NULL, NULL); + virStoragePoolObjEndAPI(&obj); +-- +2.27.0 + diff --git a/recipes-extended/libvirt/libvirt_7.2.0.bb b/recipes-extended/libvirt/libvirt_7.2.0.bb index cc7bb2cb..4ec11fb5 100644 --- a/recipes-extended/libvirt/libvirt_7.2.0.bb +++ b/recipes-extended/libvirt/libvirt_7.2.0.bb @@ -30,6 +30,7 @@ SRC_URI = "http://libvirt.org/sources/libvirt-${PV}.tar.xz;name=libvirt \ file://gnutls-helper.py \ file://0002-meson-Fix-compatibility-with-Meson-0.58.patch \ file://0001-security-fix-SELinux-label-generation-logic.patch \ + file://0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch \ " SRC_URI[libvirt.md5sum] = "92044b629216e44adce63224970a54a3" -- 2.27.0
|
|
Re: [hardknott][PATCH] containerd-opencontainers: bump to v1.4.12
Chen Qi
Thanks 🙂
Regards,
Qi
From: Bruce Ashfield <bruce.ashfield@...>
Sent: Monday, November 22, 2021 22:02 To: Bruce Ashfield <bruce.ashfield@...> Cc: Chen, Qi <Qi.Chen@...>; meta-virtualization@... <meta-virtualization@...> Subject: Re: [meta-virtualization][hardknott][PATCH] containerd-opencontainers: bump to v1.4.12 Â
On Mon, Nov 22, 2021 at 8:54 AM Bruce Ashfield via
lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote: > > I already have version bumps for all of the related components under > test, they'll show up in master-next shortly, and should cover this. > Aha. My mistake, I didn't see the branch you specified. I'll merge this to hardknott shortly. Bruce > Cheers, > > Bruce > > On Mon, Nov 22, 2021 at 2:37 AM Chen Qi <Qi.Chen@...> wrote: > > > > Bump from v1.4.4 to v.1.4.12 so that some CVEs are resolved, > > e.g. CVE-2021-41103. > > > > Signed-off-by: Chen Qi <Qi.Chen@...> > > --- > > .../containerd/containerd-opencontainers_git.bb              | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/recipes-containers/containerd/containerd-opencontainers_git.bb b/recipes-containers/containerd/containerd-opencontainers_git.bb > > index 774a28c..7f6c75d 100644 > > --- a/recipes-containers/containerd/containerd-opencontainers_git.bb > > +++ b/recipes-containers/containerd/containerd-opencontainers_git.bb > > @@ -5,7 +5,7 @@ DESCRIPTION = "containerd is a daemon to control runC, built for performance and > >                support as well as checkpoint and restore for cloning and live migration of containers." > > > > > > -SRCREV = "409c87ba59dd96965239573aa9458a3585c05468" > > +SRCREV = "7b11cfaabd73bb80907dd23182b9347b4245eb5d" > > SRC_URI = "git://github.com/containerd/containerd;branch=release/1.4 \ > >            file://0001-build-use-oe-provided-GO-and-flags.patch \ > >            file://0001-Add-build-option-GODEBUG-1.patch \ > > @@ -15,7 +15,7 @@ SRC_URI = "git://github.com/containerd/containerd;branch=release/1.4 \ > > LICENSE = "Apache-2.0" > > LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=1269f40c0d099c21a871163984590d89" > > > > -CONTAINERD_VERSION = "v1.4.4" > > +CONTAINERD_VERSION = "v1.4.12" > > > > EXTRA_OEMAKE += "GODEBUG=1" > > > > -- > > 2.33.0 > > > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > -- - 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 xen-image-minimal for RPi4 Compute Module
Patrick Godwin
Just a small update to this thread: I finally got a Xen image booting to dom0 with ethernet on the Raspberry Pi Compute Module 4. Unfortunately, my config is very ugly and still has some issues (such as USB not working...), but I can at least outline what I did to get booted into Xen:
toggle quoted messageShow quoted text
- Added the meta-virt-rpi layer (https://github.com/aananthcn/meta-virt-rpi) and switched to their dom0-image. This probably wasn't necessary, but this image had some nice quality of life changes I was going to need anyways, - Use a kernel that contains the device tree blob for the CM4; I ended up using Raspberry Pi's 5.15 kernel. - I couldn't get my local.conf to override the kernel selected in meta-virt's inc file without commenting it out, but I'm assuming this is still user error on my part. - It looks like support for the CM4 is hitting upstream in 5.16 so yocto-dev will probably work fine starting around then - Use a more recent u-boot with fixes for CM4. I ended up using 2021.10, though I think the necessary fixes were made in April of this year. - I still ended up using the boot script from meta-virtualization instead of the one in meta-virt-rpi; this was easier to modify for my needs Hopefully these notes help anyone else who decides to try this out. My next goals are to get USB working and then get the configuration cleaned up good enough to share.
-----Original Message-----
From: meta-virtualization@... <meta-virtualization@...> On Behalf Of Patrick Godwin Sent: Sunday, November 14, 2021 11:30 PM To: Bruce Ashfield <bruce.ashfield@...> Cc: meta-virtualization@... Subject: Re: [meta-virtualization] Building xen-image-minimal for RPi4 Compute Module No worries, now it's my turn to apologize :) Got pulled away from this over the last week and haven't had a chance to fully dive back on in, but I really appreciate you taking the time to reply here! Now that I've had more time with Yocto and the meta-virt layer I think I'm closing the knowledge gaps that are blocking me, I just have a few more edges to sort out. I think that you're right that a patch shouldn't be needed, I think it's just been a lot of user error on my part. I'll be sure to update this thread once I have the device up and running; I think I'm close. Thanks again! -----Original Message----- From: Bruce Ashfield <bruce.ashfield@...> Sent: Thursday, November 11, 2021 6:53 AM To: Patrick Godwin <pbg.dev@...> Cc: meta-virtualization@... Subject: Re: [meta-virtualization] Building xen-image-minimal for RPi4 Compute Module Sorry for the slow reply, On Fri, Nov 5, 2021 at 11:45 PM Patrick Godwin <pbg.dev@...> wrote: Not sure if you've sorted this out yet. We do have reference images that booted on the RPI, but I can't say that I've been testing them myself. I'm hoping that my reply will catch the attention of those that do have the h/w and they can comment in more detail. # Override the meta-raspberrypi default kernel preferenceThere's a different level of support on the h/w between linux-yocto and the 'vendor' rpi tree. We use linux-yocto for the core enablement because the branches are stable/not rebased and have a cadence we can predict (all mentioned things are breakages we've hit before!). That being said, you can change the kernel provider to the linux-rpi, and the rest of the meta-virt settings, etc, are still applicable and should work. I've tried adding the bcm2711-rpi-cm4 firmware blob to the SD card manually, but that causes u-boot to fail with the error "Bad Linux ARM64 Image Magic!" after the Boot Xen step in output. I also tried manually replacing the bootfiles written by the xen sd card image with the latest blobs from meta-raspberrypi's packages, but once the OS boots I find that xen is no longer running, making me suspect I screwed up the configuration somewhere.It could be a kernel configuration issue between the two images, if the Xen packages are on the image, but nothing is running. Can you interact with the Xen support via the xen cli at all ? Just to get a better error message ? Is this something I can trivially fix? Is there a way for me to override the device tree selection used by the minimal xen image in my local.conf? Or do I need to investigate patching one of the meta-virtualization recipes?Anything that needs changing, should be overridable via variable or through bbappends, so hopefully no patching is required. 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
|
|
[m-c-s][PATCH] concurrent-ruby: 1.1.6 -> 1.1.9
kai
From: Kai Kang <kai.kang@...>
Upgrade concurrent-ruby from 1.1.6 to 1.1.9: * it changed license file to txt, so the license file name and checksum changed * remove 'tag=' from SRC_URI and use SRCREV instead Signed-off-by: Kai Kang <kai.kang@...> --- ...urrent-ruby_1.1.6.bb => concurrent-ruby_1.1.9.bb} | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) rename meta-openstack/recipes-devtools/ruby/{concurrent-ruby_1.1.6.bb => concurrent-ruby_1.1.9.bb} (50%) diff --git a/meta-openstack/recipes-devtools/ruby/concurrent-ruby_1.1.6.bb b/meta-openstack/recipes-devtools/ruby/concurrent-ruby_1.1.9.bb similarity index 50% rename from meta-openstack/recipes-devtools/ruby/concurrent-ruby_1.1.6.bb rename to meta-openstack/recipes-devtools/ruby/concurrent-ruby_1.1.9.bb index a328203e..e2c99d7d 100644 --- a/meta-openstack/recipes-devtools/ruby/concurrent-ruby_1.1.6.bb +++ b/meta-openstack/recipes-devtools/ruby/concurrent-ruby_1.1.9.bb @@ -2,11 +2,17 @@ SUMMARY = "Modern concurrency tools including agents, futures, promises, thread HOMEPAGE = "http://www.concurrent-ruby.com" LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://LICENSE.md;md5=fde65ae93d18826f70c6fe125aa04297" +LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=e319104fe1435b64fc0a67032db44f02" -SRC_URI = "git://github.com/ruby-concurrency/concurrent-ruby.git;protocol=https;tag=v1.1.6\ - file://0001-Removed-check-for-concurrent_ruby.jar.patch" +SRC_URI = "git://github.com/ruby-concurrency/concurrent-ruby.git;protocol=https;branch=master \ + file://0001-Removed-check-for-concurrent_ruby.jar.patch \ + " +SRCREV = "52c08fca13cc3811673ea2f6fdb244a0e42e0ebe" S = "${WORKDIR}/git" +do_install:append () { + rmdir --ignore-fail-on-non-empty ${D}${libdir}/ruby/gems/${RUBY_GEM_VERSION}/plugins +} + inherit ruby -- 2.17.1
|
|
Re: [hardknott][PATCH] containerd-opencontainers: bump to v1.4.12
Bruce Ashfield
On Mon, Nov 22, 2021 at 8:54 AM Bruce Ashfield via
lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote: Aha. My mistake, I didn't see the branch you specified. I'll merge this to hardknott shortly. Bruce Cheers, -- - 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: [hardknott][PATCH] containerd-opencontainers: bump to v1.4.12
Bruce Ashfield
I already have version bumps for all of the related components under
toggle quoted messageShow quoted text
test, they'll show up in master-next shortly, and should cover this. Cheers, Bruce
On Mon, Nov 22, 2021 at 2:37 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
|
|
[hardknott][PATCH] containerd-opencontainers: bump to v1.4.12
Chen Qi
Bump from v1.4.4 to v.1.4.12 so that some CVEs are resolved,
e.g. CVE-2021-41103. Signed-off-by: Chen Qi <Qi.Chen@...> --- .../containerd/containerd-opencontainers_git.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes-containers/containerd/containerd-opencontainers_git.bb b/recipes-containers/containerd/containerd-opencontainers_git.bb index 774a28c..7f6c75d 100644 --- a/recipes-containers/containerd/containerd-opencontainers_git.bb +++ b/recipes-containers/containerd/containerd-opencontainers_git.bb @@ -5,7 +5,7 @@ DESCRIPTION = "containerd is a daemon to control runC, built for performance and support as well as checkpoint and restore for cloning and live migration of containers." -SRCREV = "409c87ba59dd96965239573aa9458a3585c05468" +SRCREV = "7b11cfaabd73bb80907dd23182b9347b4245eb5d" SRC_URI = "git://github.com/containerd/containerd;branch=release/1.4 \ file://0001-build-use-oe-provided-GO-and-flags.patch \ file://0001-Add-build-option-GODEBUG-1.patch \ @@ -15,7 +15,7 @@ SRC_URI = "git://github.com/containerd/containerd;branch=release/1.4 \ LICENSE = "Apache-2.0" LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=1269f40c0d099c21a871163984590d89" -CONTAINERD_VERSION = "v1.4.4" +CONTAINERD_VERSION = "v1.4.12" EXTRA_OEMAKE += "GODEBUG=1" -- 2.33.0
|
|
[meta-cloud-services][PATCH 3/3] meta-openstack/README: fix for operator append combined with +=
Yi Zhao
Signed-off-by: Yi Zhao <yi.zhao@...>
--- meta-openstack/Documentation/README.OpenLDAP | 2 +- meta-openstack/README.setup | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta-openstack/Documentation/README.OpenLDAP b/meta-openstack/Documentation/README.OpenLDAP index a45b769..95c2227 100644 --- a/meta-openstack/Documentation/README.OpenLDAP +++ b/meta-openstack/Documentation/README.OpenLDAP @@ -6,7 +6,7 @@ OpenLDAP into DISTRO_FEATURES e.g. in conf/local.conf -DISTRO_FEATURES:append += " OpenLDAP" +DISTRO_FEATURES:append = " OpenLDAP" A number of variables can be specified during the build phase that configures OpenLDAP specific options: diff --git a/meta-openstack/README.setup b/meta-openstack/README.setup index d1a4703..f837f63 100644 --- a/meta-openstack/README.setup +++ b/meta-openstack/README.setup @@ -95,7 +95,7 @@ systemd will be used in your images: Additionally activiate the meta-virtualization layer: - DISTRO_FEATURES:append += "virtualization kvm" + DISTRO_FEATURES:append = " virtualization kvm" Package configurations -- 2.25.1
|
|
[meta-cloud-services][PATCH 1/3] openstack-image-compute: fix warning of operator append combined with +=
Yi Zhao
Fixes:
WARNING: openstack-image-compute.bb: IMAGE_ROOTFS_EXTRA_SPACE:append += is not a recommended operator combination, please replace it. Signed-off-by: Yi Zhao <yi.zhao@...> --- .../recipes-extended/images/openstack-image-compute.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-openstack/recipes-extended/images/openstack-image-compute.bb b/meta-openstack/recipes-extended/images/openstack-image-compute.bb index 15726fd..a725e2e 100644 --- a/meta-openstack/recipes-extended/images/openstack-image-compute.bb +++ b/meta-openstack/recipes-extended/images/openstack-image-compute.bb @@ -19,6 +19,6 @@ inherit monitor # Ensure extra space for guest images, and rabbit MQ has a hard coded # check for 2G of free space, so we use 3G as a starting point. -IMAGE_ROOTFS_EXTRA_SPACE:append += "+ 3000000" +IMAGE_ROOTFS_EXTRA_SPACE:append = " + 3000000" # ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; " -- 2.25.1
|
|
[meta-cloud-services][PATCH 2/3] openstack-image-controller: fix warning of operator append combined with +=
Yi Zhao
Fixes:
WARNING: openstack-image-controller.bb: IMAGE_ROOTFS_EXTRA_SPACE:append += is not a recommended operator combination, please replace it. Signed-off-by: Yi Zhao <yi.zhao@...> --- .../recipes-extended/images/openstack-image-controller.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-openstack/recipes-extended/images/openstack-image-controller.bb b/meta-openstack/recipes-extended/images/openstack-image-controller.bb index 7f41a08..96dc80c 100644 --- a/meta-openstack/recipes-extended/images/openstack-image-controller.bb +++ b/meta-openstack/recipes-extended/images/openstack-image-controller.bb @@ -24,5 +24,5 @@ inherit monitor # Ensure extra space for guest images, and rabbit MQ has a hard coded # check for 2G of free space, so we use 5G as a starting point. -IMAGE_ROOTFS_EXTRA_SPACE:append += "+ 5000000" +IMAGE_ROOTFS_EXTRA_SPACE:append = " + 5000000" -- 2.25.1
|
|
Re: [m-c-s][PATCH] concurrent-ruby: add explicit branch
Bruce Ashfield
On Fri, Nov 19, 2021 at 8:43 AM kai <kai.kang@...> wrote:
The default is to use SRCREVs instead of tags, since tags can change (although they shouldn't), and it used to be that tags did trigger some network access with some configurations. So if it isn't too much trouble, I do think switching to a SRCREV is better. 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: [m-c-s][PATCH] concurrent-ruby: add explicit branch
kai
On 11/11/21 7:05 PM, Peter Kjellerstedt wrote:
Sorry for late reply.-----Original Message-----While at it, why not remove the tag= and replace it with a proper I am not sure which is better because there is a tag with branch in SRC_URI in meta-oe. If you insist remove tag is better, I'll send it with v2. Thanks, Kai --file://0001-Removed-check-for-concurrent_ruby.jar.patch"//Peter Kai Kang Wind River Linux
|
|
Re: [PATCH] openvswitch: fix configure error with dpdk enabled
Bruce Ashfield
merged.
toggle quoted messageShow quoted text
Bruce
On Tue, Nov 16, 2021 at 1:13 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
|
|
Re: [m-c-s][PATCH] openstack-image-aio: fix warning of operator remove combined with +=
Bruce Ashfield
merged.
toggle quoted messageShow quoted text
Bruce
On Fri, Nov 19, 2021 at 2:29 AM kai <kai.kang@...> 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
|
|
Re: [m-c-s][PATCH] open-iscsi-user: remove typo spaces in SRC_URI
Bruce Ashfield
On Fri, Nov 19, 2021 at 2:10 AM kai <kai.kang@...> wrote:
I was waiting for you to reply about the comment on your other patch in the same send (the ruby branch one), since if they are sent on the same day by the same person, and there are comments .. I tend to treat them as a unit. But I have gone ahead and merged this now. 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
|
|
[m-c-s][PATCH] openstack-image-aio: fix warning of operator remove combined with +=
kai
From: Kai Kang <kai.kang@...>
Fix warning of openstack-image-aio: | WARNING: /path/to/meta-openstack/recipes-extended/images/openstack-image-aio.bb: | IMAGE_ROOTFS_EXTRA_SPACE:append += is not a recommended operator combination, | please replace it. Signed-off-by: Kai Kang <kai.kang@...> --- meta-openstack/recipes-extended/images/openstack-image-aio.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-openstack/recipes-extended/images/openstack-image-aio.bb b/meta-openstack/recipes-extended/images/openstack-image-aio.bb index 858c8e99..f01d0ed5 100644 --- a/meta-openstack/recipes-extended/images/openstack-image-aio.bb +++ b/meta-openstack/recipes-extended/images/openstack-image-aio.bb @@ -27,7 +27,7 @@ inherit identity inherit monitor # check for 5G of free space, so we use 5G as a starting point. -IMAGE_ROOTFS_EXTRA_SPACE:append += "+ 5000000" +IMAGE_ROOTFS_EXTRA_SPACE += "+ 5000000" POST_KEYSTONE_SETUP_COMMAND = "/etc/keystone/hybrid-backend-setup" -- 2.17.1
|
|
Re: [m-c-s][PATCH] open-iscsi-user: remove typo spaces in SRC_URI
kai
On 11/11/21 11:53 AM, kai wrote:
From: Kai Kang <kai.kang@...> There are typo spaces in SRC_URI which are introduced when add ';branch=master'. Remove them. Signed-off-by: Kai Kang <kai.kang@...> --- .../recipes-connectivity/open-iscsi/open-iscsi-user_2.1.4.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-openstack/recipes-connectivity/open-iscsi/open-iscsi-user_2.1.4.bb b/meta-openstack/recipes-connectivity/open-iscsi/open-iscsi-user_2.1.4.bb index d4c489cf..fe802b72 100644 --- a/meta-openstack/recipes-connectivity/open-iscsi/open-iscsi-user_2.1.4.bb +++ b/meta-openstack/recipes-connectivity/open-iscsi/open-iscsi-user_2.1.4.bb @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" DEPENDS = "kmod openssl util-linux open-isns" DEPENDS:append = " ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)}" -SRC_URI = "git://github.com/open-iscsi/open-iscsi.git;protocol=https ;branch=master \ +SRC_URI = "git://github.com/open-iscsi/open-iscsi.git;protocol=https;branch=master \ file://0001-fix-build-error-of-cross-build.patch \ " Ping.
-- Kai Kang Wind River Linux
|
|
[PATCH] openvswitch: fix configure error with dpdk enabled
Chen Qi
When enabling 'dpdk' PACKAGECONFIG, the following error appears.
| configure: error: Could not find DPDK library in default search path Fix the error by tweaking the configure option regarding dpdk. Add pkgconfig to 'inherit' because pkgconfig is required at do_configure when dpdk is enabled. Signed-off-by: Chen Qi <Qi.Chen@...> --- recipes-networking/openvswitch/openvswitch.inc | 2 +- recipes-networking/openvswitch/openvswitch_git.bb | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/recipes-networking/openvswitch/openvswitch.inc b/recipes-networking/openvswitch/openvswitch.inc index b354a84..831e0b3 100644 --- a/recipes-networking/openvswitch/openvswitch.inc +++ b/recipes-networking/openvswitch/openvswitch.inc @@ -72,7 +72,7 @@ FILES:${PN} += "${datadir}/ovsdbmonitor" FILES:${PN} += "/run" FILES:${PN} += "${libdir}/python${PYTHON_BASEVERSION}/" -inherit autotools update-rc.d systemd python3native +inherit pkgconfig autotools update-rc.d systemd python3native SYSTEMD_PACKAGES = "${PN}-switch" SYSTEMD_SERVICE:${PN}-switch = " \ diff --git a/recipes-networking/openvswitch/openvswitch_git.bb b/recipes-networking/openvswitch/openvswitch_git.bb index f1a5c4c..0fb7c13 100644 --- a/recipes-networking/openvswitch/openvswitch_git.bb +++ b/recipes-networking/openvswitch/openvswitch_git.bb @@ -32,10 +32,8 @@ SRC_URI += "git://github.com/openvswitch/ovs.git;protocol=https;branch=branch-2. LIC_FILES_CHKSUM = "file://LICENSE;md5=1ce5d23a6429dff345518758f13aaeab" -DPDK_INSTALL_DIR ?= "/opt/dpdk" - PACKAGECONFIG ?= "libcap-ng" -PACKAGECONFIG[dpdk] = "--with-dpdk=${STAGING_DIR_TARGET}${DPDK_INSTALL_DIR}/share/${TARGET_ARCH}-native-linuxapp-gcc,,dpdk,dpdk" +PACKAGECONFIG[dpdk] = "--with-dpdk=shared,,dpdk,dpdk" PACKAGECONFIG[libcap-ng] = "--enable-libcapng,--disable-libcapng,libcap-ng," PACKAGECONFIG[ssl] = ",--disable-ssl,openssl," -- 2.33.0
|
|