On 1/12/2018 7:05 PM, Flavio Leitner wrote:
On Fri, Jan 12, 2018 at 03:46:16PM -0800, Gregory Rose wrote:
On 1/12/2018 12:30 PM, Gregory Rose wrote:
On 1/12/2018 11:53 AM, Flavio Leitner wrote:
On Fri, Jan 12, 2018 at 11:38:05AM -0800, Gregory Rose wrote:
On 1/12/2018 11:32 AM, Flavio Leitner wrote:
On Fri, Jan 12, 2018 at 08:37:43AM -0800, Greg Rose wrote:
From: Gurucharan Shetty <shet...@vmware.com>
There are occasions when an openvswitch kernel module rpm which does
not match the exact build number of the running kernel. In that
case the openvswitch kernel modules will be installed to the
"weak-updates" directory under the /lib/modules/$(uname -r)
directory. But the new kernel modules will not be found because
the default /etc/depmod.d/dist.conf search path lists weak-updates
last.
This patch creates a file in /etc/depmod.d/ named 01openvswitch.conf.
This file specifies weak-updates first in the search path and since
it is named with a preceeding "01" it will be found first by depmod.
This resolves issues with customers who have installed openvswitch
kernel modules previously and a kernel upgrade has occurred since
and when the kernel minor build numbers do not exactly match the
running kernel.
I am a bit rusty on this so apologies if I am missing something
obvious. However, I don't know how this is fixing the issue because
the module is still being installed at /lib/modules/%{kernel_version}
and you are saying to depmod to look at /lib/modules/extra/openvswitch
and /lib/modules/weak-updates/openvswitch first.
It seems all you need is to run /sbin/weak-modules in %post to make
sure all kernels are updated.
I've never even heard of that utility. There's no man page for
it (at least
on my system) but
let me give it a look. Sounds promising!!
It's a valid request, feel free to open a bz.
So then if I looked at a yum transaction history list like this:
[ec2-user@ip-13-12-11-62 ~]$ sudo yum history list
Loaded plugins: product-id, search-disabled-repos, subscription-manager
ID | Command line | Date and time | Action(s) |
Altered
-------------------------------------------------------------------------------
27 | --disablerepo=* --enable | 2018-01-12 11:45 | Install | 2
26 | --disablerepo=* --enable | 2018-01-12 11:45 | Install | 1
25 | --disablerepo=* --enable | 2018-01-12 11:42 | Install | 1
EE
24 | --disablerepo=* --enable | 2018-01-12 11:41 | Install | 1
23 | --disablerepo=* --enable | 2018-01-12 11:41 | Install | 2
22 | --disablerepo=* --enable | 2018-01-12 11:37 | Install | 1
21 | localinstall -y nsx-agen | 2018-01-12 11:36 | Install | 10
EE
20 | --disablerepo=* --enable | 2018-01-12 11:36 | Install | 1
EE
19 | --disablerepo=* --enable | 2018-01-12 11:35 | Install | 1
EE
18 | --disablerepo=* --enable | 2018-01-12 11:35 | Install | 1
EE
17 | --disablerepo=* --enable | 2018-01-12 11:35 | Install | 1
16 | --disablerepo=* --enable | 2018-01-12 11:35 | Install | 1
15 | --disablerepo=* --enable | 2018-01-12 11:35 | Install | 1
14 | --disablerepo=* --enable | 2018-01-12 11:35 | Install | 1
Do you see any problems with that? Do those "EE" fields mean anything
important? I saw documentation for a single "E" which indicates an error of
some sort but what does the double "EE" mean?
http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=output.py;h=32e89580092858f82b5b0e21589f9b9a4f448a3e;hb=HEAD#l2107
It seems you will always see it duplicated.
It will flag E if the rpm package spits any output during the
installation:
E - The transaction completed fine, but had warning/error output
during the transaction.
You should be able to see the messages in the console though.
Usually we try to fix the problem to avoid the messages but
sometimes it's not possible, so we redirect to /dev/null.
The openvswitch-fedora.spec has many examples of that:
'&> /dev/null || :'
Thank you for the pointer and the explanation. I'm working on a bug in
which after the transactions listed occur then the installation of the
kmod kernel drivers rpm will not work right and the openvswitch kernel
module drivers are installed to a completely separate directory in
/lib/modules.
Normally after installing the kmod rpm you'll see something like this:
[root@Unknown ~]# find /lib/modules -name "openvswitch.ko"
/lib/modules/3.10.0-514.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
/lib/modules/3.10.0-514.el7.x86_64/weak-updates/openvswitch/openvswitch.ko
/lib/modules/3.10.0-514.6.1.el7.x86_64/extra/openvswitch/openvswitch.ko
However, when this bug occurs you see only this instead after installing
the same kmod rpm.
[root@Unknown ~]# find /lib/modules -name "openvswitch.ko"
/lib/modules/3.10.0-514.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
/lib/modules/3.10.0-514.6.1.el7.x86_64/extra/openvswitch/openvswitch.ko
The running kernel is 3.10.0-514.el7.x86_64 so after the kmod rpm
install the system continues to use the older openvswitch kernel driver.
It's very perplexing to say the least...
Thanks for your help!
- Greg
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
