On 1/12/2018 9:37 AM, Guru Shetty wrote:
On 12 January 2018 at 08:37, Greg Rose <gvrose8...@gmail.com
<mailto:gvrose8...@gmail.com>> wrote:
A bug in RHEL 7.2 has been found in which a customer who installed
a RHEL 7.2 openvswitch kernel module rpm with a slightly different
minor build number than the running kernel found that the kernel
modules were installed to the wrong directory.
After the installation the new openvswitch kernel modules were
installed to:
/lib/modules/3.10.0-327.22.2.el7.x86_64/extra/openvswitch
But the running kernel was 3.10.0-327.el7.x86_64 and after the
installation was complete the kernel modules in the installed
directory were not linked to the "weak-updates" directory in
the running kernel. So a critical bug was encountered in
which the in-tree openvswitch kernel module was loaded instead
of the one the customer explicitly installed with the rpm.
This patch replicates ./extra/openvswitch directory with kernel
modules, if for the currently running kernel there is neither
a ./extra/openvswitch nor ./weak-update/openvswitch directory.
Signed-off-by: Greg Rose <gvrose8...@gmail.com
<mailto:gvrose8...@gmail.com>>
---
V2 - Incorporate feedback from V1
---
rhel/openvswitch.spec.in <http://openvswitch.spec.in> | 26
++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/rhel/openvswitch.spec.in <http://openvswitch.spec.in>
b/rhel/openvswitch.spec.in <http://openvswitch.spec.in>
index e510d35..b5b5122 100644
--- a/rhel/openvswitch.spec.in <http://openvswitch.spec.in>
+++ b/rhel/openvswitch.spec.in <http://openvswitch.spec.in>
@@ -169,6 +169,32 @@ fi
/sbin/chkconfig --add openvswitch
/sbin/chkconfig openvswitch on
+# In some cases a kernel module rpm will have a different minor build
+# version than the currently running kernel. In this case the kernel
+# modules will be installed but not to the kernel modules directory
+# of the currently running kernel. Check and copy modules if
+# necessary.
+# This is a bug that has only been found to occur on RHEL 7.2.
+if [[ ! -d /lib/modules/$(uname -r)/extra/openvswitch && \
+ ! -d /lib/modules/$(uname -r)/weak-updates/openvswitch ]]; then
This check may not be good enough. If we are doing a upgrade of OVS on
the system (say from 2.7 to 2.9) and previously we had something in
/lib/modules/$(uname -r)/weak-updates/openvswitch then we are no
longer going to add the newer version there.
But that would assure that a previous attempt to install the openvswitch
kernel modules rpm had succeeded, which means this system doesn't have
the bug that is prompting this patch. That means the newly installed
kernel modules have been placed in the right kernel modules directory.
So the test is correct.
+ found="false"
+ for i in `ls -t /lib/modules`
+ do
+ if [ -d /lib/modules/$i/extra/openvswitch ]; then
This will not help either. There is a possibility of multiple kernels
installed and it looks like we will choose one randomly. We should
only look at the path where the current rpm actually installed our files.
I tried it on a system with multiple installed kernels and it does work
because the sort by time will pick the most recently installed kernel
modules directory which would be the one where the just installed kernel
modules rpm had gone to (erroneously I should add).
+ mkdir -p /lib/modules/$(uname -r)/extra
+ cp -r --preserve "/lib/modules/$i/extra/openvswitch" \
+ /lib/modules/$(uname -r)/extra
+ found="true"
+ break
+ fi
+ done
+ if [ "$found" != "true" ]; then
+ echo "Error in openvswitch kernel modules installation"
+ else
+ /usr/sbin/depmod -a
+ fi
+fi
+
%post selinux-policy
/usr/sbin/semodule -i
%{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp &>
/dev/null || :
--
1.8.3.1
_______________________________________________
dev mailing list
d...@openvswitch.org <mailto:d...@openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
<https://mail.openvswitch.org/mailman/listinfo/ovs-dev>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
