| Message ID | 1515775064-18494-1-git-send-email-gvrose8192@gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [ovs-dev,V2,1/2] rhel: Add depmod file for openvswitch module search | expand |
On 12 January 2018 at 08:37, Greg Rose <gvrose8192@gmail.com> wrote: > From: Gurucharan Shetty <shettyg@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. > > Signed-off-by: Greg Rose <gvrose8192@gmail.com> > Signed-off-by: Gurucharan Shetty <shettyg@vmware.com> If you decide to change my author to my usually preferred ovn.org email id, then Signed-off-by: Gurucharan Shetty <guru@ovn.org> > > --- > > V2 - Fix typo in commit title > --- > rhel/openvswitch-kmod-rhel6.spec.in | 10 ++++++---- > rhel/openvswitch-kmod.files | 2 +- > 2 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/rhel/openvswitch-kmod-rhel6.spec.in b/rhel/ > openvswitch-kmod-rhel6.spec.in > index 8413b25..a7f4832 100644 > --- a/rhel/openvswitch-kmod-rhel6.spec.in > +++ b/rhel/openvswitch-kmod-rhel6.spec.in > @@ -62,17 +62,19 @@ for flavor in %flavors_to_build ; do > find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' -exec rm > {} \; > done > install -d %{buildroot}%{_sysconfdir}/depmod.d/ > + > +echo "search extra/openvswitch weak-updates/openvswitch updates extra > built-in weak-updates" >> 01%{oname}.conf > for module in %{buildroot}/lib/modules/%{kernel_version}/$INSTALL_MOD_ > DIR/*.ko; > do > modname="$(basename ${module})" > - echo "override ${modname%.ko} * extra/%{oname}" >> %{oname}.conf > - echo "override ${modname%.ko} * weak-updates/%{oname}" >> > %{oname}.conf > + echo "override ${modname%.ko} * extra/%{oname}" >> 01%{oname}.conf > + echo "override ${modname%.ko} * weak-updates/%{oname}" >> > 01%{oname}.conf > done > -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ > +install -m 644 01%{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ > > %files > %defattr(644,root,root) > -/etc/depmod.d/%{oname}.conf > +/etc/depmod.d/01%{oname}.conf > > %clean > rm -rf $RPM_BUILD_ROOT > diff --git a/rhel/openvswitch-kmod.files b/rhel/openvswitch-kmod.files > index 357c2e8..49262f3 100644 > --- a/rhel/openvswitch-kmod.files > +++ b/rhel/openvswitch-kmod.files > @@ -1,3 +1,3 @@ > %defattr(644,root,root,755) > /lib/modules/%2-%1 > -/etc/depmod.d/openvswitch.conf > +/etc/depmod.d/01openvswitch.conf > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
On 1/12/2018 9:20 AM, Guru Shetty wrote: > > > On 12 January 2018 at 08:37, Greg Rose <gvrose8192@gmail.com > <mailto:gvrose8192@gmail.com>> wrote: > > From: Gurucharan Shetty <shettyg@vmware.com > <mailto:shettyg@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. > > Signed-off-by: Greg Rose <gvrose8192@gmail.com > <mailto:gvrose8192@gmail.com>> > > Signed-off-by: Gurucharan Shetty <shettyg@vmware.com > <mailto:shettyg@vmware.com>> > > If you decide to change my author to my usually preferred ovn.org > <http://ovn.org> email id, then > Signed-off-by: Gurucharan Shetty <guru@ovn.org <mailto:guru@ovn.org>> Ah yes, of course. What was I thinking!? I'll add your correct authorship and signed-off-by in the next round of patches. Thanks! > > --- > > V2 - Fix typo in commit title > --- > rhel/openvswitch-kmod-rhel6.spec.in > <http://openvswitch-kmod-rhel6.spec.in> | 10 ++++++---- > rhel/openvswitch-kmod.files | 2 +- > 2 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/rhel/openvswitch-kmod-rhel6.spec.in > <http://openvswitch-kmod-rhel6.spec.in> > b/rhel/openvswitch-kmod-rhel6.spec.in > <http://openvswitch-kmod-rhel6.spec.in> > index 8413b25..a7f4832 100644 > --- a/rhel/openvswitch-kmod-rhel6.spec.in > <http://openvswitch-kmod-rhel6.spec.in> > +++ b/rhel/openvswitch-kmod-rhel6.spec.in > <http://openvswitch-kmod-rhel6.spec.in> > @@ -62,17 +62,19 @@ for flavor in %flavors_to_build ; do > find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' > -exec rm {} \; > done > install -d %{buildroot}%{_sysconfdir}/depmod.d/ > + > +echo "search extra/openvswitch weak-updates/openvswitch updates > extra built-in weak-updates" >> 01%{oname}.conf > for module in > %{buildroot}/lib/modules/%{kernel_version}/$INSTALL_MOD_DIR/*.ko; > do > modname="$(basename ${module})" > - echo "override ${modname%.ko} * extra/%{oname}" >> %{oname}.conf > - echo "override ${modname%.ko} * weak-updates/%{oname}" >> > %{oname}.conf > + echo "override ${modname%.ko} * extra/%{oname}" >> > 01%{oname}.conf > + echo "override ${modname%.ko} * weak-updates/%{oname}" >> > 01%{oname}.conf > done > -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ > +install -m 644 01%{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ > > %files > %defattr(644,root,root) > -/etc/depmod.d/%{oname}.conf > +/etc/depmod.d/01%{oname}.conf > > %clean > rm -rf $RPM_BUILD_ROOT > diff --git a/rhel/openvswitch-kmod.files b/rhel/openvswitch-kmod.files > index 357c2e8..49262f3 100644 > --- a/rhel/openvswitch-kmod.files > +++ b/rhel/openvswitch-kmod.files > @@ -1,3 +1,3 @@ > %defattr(644,root,root,755) > /lib/modules/%2-%1 > -/etc/depmod.d/openvswitch.conf > +/etc/depmod.d/01openvswitch.conf > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org <mailto:dev@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > >
On Fri, Jan 12, 2018 at 08:37:43AM -0800, Greg Rose wrote: > From: Gurucharan Shetty <shettyg@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. fbl > > Signed-off-by: Greg Rose <gvrose8192@gmail.com> > > --- > > V2 - Fix typo in commit title > --- > rhel/openvswitch-kmod-rhel6.spec.in | 10 ++++++---- > rhel/openvswitch-kmod.files | 2 +- > 2 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/rhel/openvswitch-kmod-rhel6.spec.in b/rhel/openvswitch-kmod-rhel6.spec.in > index 8413b25..a7f4832 100644 > --- a/rhel/openvswitch-kmod-rhel6.spec.in > +++ b/rhel/openvswitch-kmod-rhel6.spec.in > @@ -62,17 +62,19 @@ for flavor in %flavors_to_build ; do > find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' -exec rm {} \; > done > install -d %{buildroot}%{_sysconfdir}/depmod.d/ > + > +echo "search extra/openvswitch weak-updates/openvswitch updates extra built-in weak-updates" >> 01%{oname}.conf > for module in %{buildroot}/lib/modules/%{kernel_version}/$INSTALL_MOD_DIR/*.ko; > do > modname="$(basename ${module})" > - echo "override ${modname%.ko} * extra/%{oname}" >> %{oname}.conf > - echo "override ${modname%.ko} * weak-updates/%{oname}" >> %{oname}.conf > + echo "override ${modname%.ko} * extra/%{oname}" >> 01%{oname}.conf > + echo "override ${modname%.ko} * weak-updates/%{oname}" >> 01%{oname}.conf > done > -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ > +install -m 644 01%{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ > > %files > %defattr(644,root,root) > -/etc/depmod.d/%{oname}.conf > +/etc/depmod.d/01%{oname}.conf > > %clean > rm -rf $RPM_BUILD_ROOT > diff --git a/rhel/openvswitch-kmod.files b/rhel/openvswitch-kmod.files > index 357c2e8..49262f3 100644 > --- a/rhel/openvswitch-kmod.files > +++ b/rhel/openvswitch-kmod.files > @@ -1,3 +1,3 @@ > %defattr(644,root,root,755) > /lib/modules/%2-%1 > -/etc/depmod.d/openvswitch.conf > +/etc/depmod.d/01openvswitch.conf > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 <shettyg@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!! Thanks, - Greg > > fbl > > >> Signed-off-by: Greg Rose <gvrose8192@gmail.com> >> >> --- >> >> V2 - Fix typo in commit title >> --- >> rhel/openvswitch-kmod-rhel6.spec.in | 10 ++++++---- >> rhel/openvswitch-kmod.files | 2 +- >> 2 files changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/rhel/openvswitch-kmod-rhel6.spec.in b/rhel/openvswitch-kmod-rhel6.spec.in >> index 8413b25..a7f4832 100644 >> --- a/rhel/openvswitch-kmod-rhel6.spec.in >> +++ b/rhel/openvswitch-kmod-rhel6.spec.in >> @@ -62,17 +62,19 @@ for flavor in %flavors_to_build ; do >> find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' -exec rm {} \; >> done >> install -d %{buildroot}%{_sysconfdir}/depmod.d/ >> + >> +echo "search extra/openvswitch weak-updates/openvswitch updates extra built-in weak-updates" >> 01%{oname}.conf >> for module in %{buildroot}/lib/modules/%{kernel_version}/$INSTALL_MOD_DIR/*.ko; >> do >> modname="$(basename ${module})" >> - echo "override ${modname%.ko} * extra/%{oname}" >> %{oname}.conf >> - echo "override ${modname%.ko} * weak-updates/%{oname}" >> %{oname}.conf >> + echo "override ${modname%.ko} * extra/%{oname}" >> 01%{oname}.conf >> + echo "override ${modname%.ko} * weak-updates/%{oname}" >> 01%{oname}.conf >> done >> -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ >> +install -m 644 01%{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ >> >> %files >> %defattr(644,root,root) >> -/etc/depmod.d/%{oname}.conf >> +/etc/depmod.d/01%{oname}.conf >> >> %clean >> rm -rf $RPM_BUILD_ROOT >> diff --git a/rhel/openvswitch-kmod.files b/rhel/openvswitch-kmod.files >> index 357c2e8..49262f3 100644 >> --- a/rhel/openvswitch-kmod.files >> +++ b/rhel/openvswitch-kmod.files >> @@ -1,3 +1,3 @@ >> %defattr(644,root,root,755) >> /lib/modules/%2-%1 >> -/etc/depmod.d/openvswitch.conf >> +/etc/depmod.d/01openvswitch.conf >> -- >> 1.8.3.1 >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 <shettyg@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. Looks at this example: %post kmod-%{kverrel} for k in $(cd /lib/modules && /bin/ls); do [ -d "/lib/modules/$k/kernel/" ] && depmod -a "$k" done if [ -x "/sbin/weak-modules" ]; then for m in sfc sfc_resource sfc_char onload sfc_affinity; do echo "/lib/modules/%{kernel}/extra/$m.ko" done | /sbin/weak-modules --add-modules fi %postun kmod-%{kverrel} for k in $(cd /lib/modules && /bin/ls); do [ -d "/lib/modules/$k/kernel/" ] && depmod -a "$k" done if [ "$1" = 0 ]; then # Erase, not upgrade if [ -x "/sbin/weak-modules" ]; then for m in sfc sfc_resource sfc_char onload sfc_affinity; do echo "/lib/modules/%{kernel}/extra/$m.ko" done | /sbin/weak-modules --remove-modules fi fi from here https://github.com/majek/openonload/blob/master/scripts/onload_misc/openonload.spec HTH, fbl
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 <shettyg@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. > > Looks at this example: > > %post kmod-%{kverrel} > for k in $(cd /lib/modules && /bin/ls); do > [ -d "/lib/modules/$k/kernel/" ] && depmod -a "$k" > done > if [ -x "/sbin/weak-modules" ]; then > for m in sfc sfc_resource sfc_char onload sfc_affinity; do > echo "/lib/modules/%{kernel}/extra/$m.ko" > done | /sbin/weak-modules --add-modules > fi > > %postun kmod-%{kverrel} > for k in $(cd /lib/modules && /bin/ls); do > [ -d "/lib/modules/$k/kernel/" ] && depmod -a "$k" > done > if [ "$1" = 0 ]; then # Erase, not upgrade > if [ -x "/sbin/weak-modules" ]; then > for m in sfc sfc_resource sfc_char onload sfc_affinity; do > echo "/lib/modules/%{kernel}/extra/$m.ko" > done | /sbin/weak-modules --remove-modules > fi > fi > > > from here > https://github.com/majek/openonload/blob/master/scripts/onload_misc/openonload.spec Thanks for the example, that's very helpful. - Greg > > HTH, > fbl > >
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 <shettyg@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? Thanks, - Greg >> Looks at this example: >> >> %post kmod-%{kverrel} >> for k in $(cd /lib/modules && /bin/ls); do >> [ -d "/lib/modules/$k/kernel/" ] && depmod -a "$k" >> done >> if [ -x "/sbin/weak-modules" ]; then >> for m in sfc sfc_resource sfc_char onload sfc_affinity; do >> echo "/lib/modules/%{kernel}/extra/$m.ko" >> done | /sbin/weak-modules --add-modules >> fi >> >> %postun kmod-%{kverrel} >> for k in $(cd /lib/modules && /bin/ls); do >> [ -d "/lib/modules/$k/kernel/" ] && depmod -a "$k" >> done >> if [ "$1" = 0 ]; then # Erase, not upgrade >> if [ -x "/sbin/weak-modules" ]; then >> for m in sfc sfc_resource sfc_char onload sfc_affinity; do >> echo "/lib/modules/%{kernel}/extra/$m.ko" >> done | /sbin/weak-modules --remove-modules >> fi >> fi >> >> >> from here >> https://github.com/majek/openonload/blob/master/scripts/onload_misc/openonload.spec >> > > Thanks for the example, that's very helpful. > > - Greg > >> >> HTH, >> fbl >> >> >
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 <shettyg@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 || :'
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 <shettyg@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
On Sat, Jan 13, 2018 at 10:59:25AM -0800, Gregory Rose wrote: > 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 <shettyg@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... Does that happen with or without using weak-modules?
On 1/13/2018 2:53 PM, Flavio Leitner wrote: > On Sat, Jan 13, 2018 at 10:59:25AM -0800, Gregory Rose wrote: >> 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... > Does that happen with or without using weak-modules? > Without - we have not yet implemented your suggested post install and uninstall scripts. - Greg
diff --git a/rhel/openvswitch-kmod-rhel6.spec.in b/rhel/openvswitch-kmod-rhel6.spec.in index 8413b25..a7f4832 100644 --- a/rhel/openvswitch-kmod-rhel6.spec.in +++ b/rhel/openvswitch-kmod-rhel6.spec.in @@ -62,17 +62,19 @@ for flavor in %flavors_to_build ; do find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' -exec rm {} \; done install -d %{buildroot}%{_sysconfdir}/depmod.d/ + +echo "search extra/openvswitch weak-updates/openvswitch updates extra built-in weak-updates" >> 01%{oname}.conf for module in %{buildroot}/lib/modules/%{kernel_version}/$INSTALL_MOD_DIR/*.ko; do modname="$(basename ${module})" - echo "override ${modname%.ko} * extra/%{oname}" >> %{oname}.conf - echo "override ${modname%.ko} * weak-updates/%{oname}" >> %{oname}.conf + echo "override ${modname%.ko} * extra/%{oname}" >> 01%{oname}.conf + echo "override ${modname%.ko} * weak-updates/%{oname}" >> 01%{oname}.conf done -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ +install -m 644 01%{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ %files %defattr(644,root,root) -/etc/depmod.d/%{oname}.conf +/etc/depmod.d/01%{oname}.conf %clean rm -rf $RPM_BUILD_ROOT diff --git a/rhel/openvswitch-kmod.files b/rhel/openvswitch-kmod.files index 357c2e8..49262f3 100644 --- a/rhel/openvswitch-kmod.files +++ b/rhel/openvswitch-kmod.files @@ -1,3 +1,3 @@ %defattr(644,root,root,755) /lib/modules/%2-%1 -/etc/depmod.d/openvswitch.conf +/etc/depmod.d/01openvswitch.conf