Bug 1890095
Summary: | OVS build is broken due to kernel nf_conntrack_sctp.h update in RHEL-7.9 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Flavio Leitner <fleitner> |
Component: | openvswitch2.11 | Assignee: | Flavio Leitner <fleitner> |
Status: | CLOSED ERRATA | QA Contact: | Jean-Tsung Hsiao <jhsiao> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | FDP 20.H | CC: | ctrautma, fiezzi, jhsiao, kfida, ralongi |
Target Milestone: | --- | ||
Target Release: | FDP 20.I | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openvswitch2.11-2.11.3-74.el7fdp | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-12-01 15:06:32 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Flavio Leitner
2020-10-21 11:43:15 UTC
* Thu Oct 22 2020 Open vSwitch CI <ovs-team> - 2.11.3-74 - Merging upstream branch-2.11 [bcdaec801519a87334af425bc70f9edccac9c874] * Wed Oct 21 2020 Flavio Leitner <fbl> - 2.11.3-73 - Use in tree copy of header nf_conntrack_sctp.h. (#1890095) [62f0c9a4d6f48ffe185d509935dd14ed66557bdc] Hi Flavio, Since I don't have error free gcc command line, to verify this bug, can I just state that the OVS 2.11.3 build has been successful(-74, -75 and -76) with the following back port ? commit 8c7130da98c55bdf13eae62b5250434f8dfd366b Thanks! Jean Found the following compilation line from the build log which is error free: libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I ../include -I ./include -I ../lib -I ./lib -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -fno-strict-aliasing -Wshadow -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -c ../lib/netlink-conntrack.c -fPIC -DPIC -o lib/.libs/netlink-conntrack.o The compilation line in Comment 6 above is from the following build log: http://download-node-02.eng.bos.redhat.com/brewroot/packages/openvswitch2.11/2.11.3/76.el7fdp/data/logs/x86_64/build.log Hi Jean, We would need to know the kernel version used during the build to consider if the kernel is fixed or not. If the kernel is fixed, then this bug fix is not needed because the problem goes away. Another way to confirm this is to deploy rhel-7 with the 7.9 GA kernel and try to build before this fix to confirm the issue and then update the srpm and see if the build now succeeds. fbl (In reply to Flavio Leitner from comment #8) > Hi Jean, > > We would need to know the kernel version used during the build to consider > if the kernel is fixed or not. > If the kernel is fixed, then this bug fix is not needed because the problem > goes away. > > Another way to confirm this is to deploy rhel-7 with the 7.9 GA kernel and > try to build before this fix Hi Flavio, The rpmbuild succeeded without changes under 7.9 GA --- see a piece of log below. So, I think the bug no longer exists. Please let me know if this is enough. Thanks! Jean Wrote: /root/rpmbuild/RPMS/x86_64/openvswitch2.11-2.11.3-76.el7.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/python-openvswitch2.11-2.11.3-76.el7.x86_64.rpm Wrote: /root/rpmbuild/RPMS/noarch/openvswitch2.11-test-2.11.3-76.el7.noarch.rpm Wrote: /root/rpmbuild/RPMS/x86_64/openvswitch2.11-devel-2.11.3-76.el7.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/openvswitch2.11-debuginfo-2.11.3-76.el7.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.TanyIH + umask 022 + cd /root/rpmbuild/BUILD + cd ovs-2.11.3 + rm -rf /root/rpmbuild/BUILDROOT/openvswitch2.11-2.11.3-76.el7fdp.x86_64 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.xfG5sG + umask 022 + cd /root/rpmbuild/BUILD + rm -rf ovs-2.11.3 + exit 0 [root@netqe29 opt]# ll total 24232 -rw-r--r--. 1 root root 24813237 Nov 2 12:25 openvswitch2.11-2.11.3-76.el7fdp.src.rpm [root@netqe29 opt]# find . -name "*.rpm" ./openvswitch2.11-2.11.3-76.el7fdp.src.rpm [root@netqe29 opt]# uname -r 3.10.0-1160.el7.x86_64 [root@netqe29 opt]# > to confirm the issue and then update the srpm and see if the build now > succeeds. > > fbl Hi Jean, Yesterday we worked to reproduce and validate the fix, so could you please update here with your findings? (In reply to Flavio Leitner from comment #10) > Hi Jean, > > Yesterday we worked to reproduce and validate the fix, so could you please > update here with your findings? Working together we have run many tests to reproduce the issue and confirm the fix. Among these, here are some key tests: * Under 7.6 GA environment using openvswitch2.11-2.11.3-76.el7 srpm rpmbuild succeeded. * Install the kernel-headers of kernel-3.10.0-1160.1.1.el7, and rpmbuild succeeded again; So, the fix in -76 srpm worked. * Ran rpmbuild using openvswitch2.11-2.11.3-72.el7 srpm, the build failed in the middle, and we reproduced the issue. Below is part of the build log: Nov 10 13:27:24 <jhsiao> In file included from ../lib/netlink-conntrack.c:27:0: Nov 10 13:27:24 <jhsiao> /usr/include/linux/netfilter/nf_conntrack_sctp.h:25:2: error: unknown type name 'u8' Nov 10 13:27:24 <jhsiao> u8 last_dir; Nov 10 13:27:24 <jhsiao> ^ Nov 10 13:27:24 <jhsiao> /usr/include/linux/netfilter/nf_conntrack_sctp.h:26:2: error: unknown type name 'u8' Nov 10 13:27:24 <jhsiao> u8 flags; Nov 10 13:27:32 <jhsiao> So, we got it Nov 10 13:27:37 <fbl> \o/ Please update if I have missed something. Otherwise, I'll set the status to VERIFIED. Thanks! Jean Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openvswitch2.11 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:5307 |