[ovs-dev,V2,1/2] rhel: Add depmod file for openvswitch module search

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
Related show

Commit Message

Gregory Rose Jan. 12, 2018, 4:37 p.m.
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>

---

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(-)

Comments

Guru Shetty Jan. 12, 2018, 5:20 p.m. | #1
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
>
Gregory Rose Jan. 12, 2018, 6:10 p.m. | #2
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>
>
>
Flavio Leitner Jan. 12, 2018, 7:32 p.m. | #3
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
Gregory Rose Jan. 12, 2018, 7:38 p.m. | #4
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
Flavio Leitner Jan. 12, 2018, 7:53 p.m. | #5
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
Gregory Rose Jan. 12, 2018, 8:30 p.m. | #6
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
>
>
Gregory Rose Jan. 12, 2018, 11:46 p.m. | #7
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
>>
>>
>
Flavio Leitner Jan. 13, 2018, 3:05 a.m. | #8
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 || :'
Gregory Rose Jan. 13, 2018, 6:59 p.m. | #9
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
Flavio Leitner Jan. 13, 2018, 10:53 p.m. | #10
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?
Gregory Rose Jan. 14, 2018, 2:15 a.m. | #11
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

Patch

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