[elrepo] Intel e1000e and igb issue

[Phil Perry]

On 09/03/15 19:31, Nick Howitt wrote:
> 
> 
> On 09/03/2015 17:40, Phil Perry wrote:
>> On 06/03/15 15:42, Nick Howitt wrote:
>>> Hi,
>>>
>>> I've been using kmod drivers for a few years now - the r8168, e1000e (no more)
>>> and igb and I've recently bumped into an oddity while helping someone on the
>>> ClearOS forums
>>> <http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,28/func,view/id,69006/>.
>>> I've been used to the idea of the modules installing in a "week-updates"
>>> directory so, for example the r8168 driver installs to
>>> /lib/modules/2.6.32-504.8.1.v6.x86_64/weak-updates/r8168/r8168.ko. Compiling the
>>> e1000e and igb drivers from source against the ClearOS kernel (which is a small
>>> bit different to RHEL), I then install the drivers and I notice the igb one
>>> installs to /lib/modules/2.6.32-431.23.3.v6.x86_64/extra/igb/igb.ko. Subsequent
>>> to that ClearOS updated and a new kernel was installed
>>> (2.6.32-504.8.1.v6.x86_64). I rebooted the server and it showed me running the
>>> stock version of the igb, so the kmod one was not carried forward.
>>>
>>> Someone else has installed my e1000e driver I compiled on the older kernel and
>>> again it is not being loaded as it has installed into
>>> /lib/modules/2.6.32-431.3.1.v6.x86_64/extra/e1000e.
>>>
>>> Have I completely misunderstood things or is something wrong. The intel drivers
>>> are only being used with the kernel they were compiled for.
>>>
>>> Regards,
>>>
>>> Nick
>>>
>> Hi Nick,
>>
>> I'm not familiar with the differences between ClearOS and RHEL so I'll
>> explain how things work on RHEL and leave you to work out if there are
>> any significant differences.
>>
>> kmod packages install their driver(s) to the /extra/ directory in the
>> kernel against which they were compiled. For example, if you compiled
>> the driver against kernel-2.6.32-431.23.3.v6.x86_64 then you would
>> expect to find the file at:
>>
>> /lib/modules/2.6.32-431.23.3.v6.x86_64/extra/igb/igb.ko
>>
>> You can double check this by examining your RPM package, for example:
>>
>> rpm -qlp kmod-foo-1.2-3.el6.x86_64.rpm
>>
>> which should show the above.
>>
>> The weak-modules script is then run by the package and will symlink the
>> above driver to the /weak-updates/ directory for each kernel that the
>> module is kABI-compatible with. If it's not compatible it won't get weak
>> linked.
>>
>> As you are aware, modinfo will tell you the full path to the driver
>> being used so you can easily check if your kmod driver is being used
>> over the distro kernel driver.
>>
>> As a side note, I would recommend getting your users to reboot after
>> installing / updating a kmod driver. Experienced users can get away with
>> unloading the old module and reloading the new but rebooting takes away
>> any doubt for less experienced users and eliminates one more potential
>> issue when troubleshooting from afar.
>>
>> Hope that helps,
>>
>> Phil
>>
>> _______________________________________________
>> elrepo mailing list
>> elrepo at lists.elrepo.org
>> http://lists.elrepo.org/mailman/listinfo/elrepo
> Hi Phil,
> 
> Thanks for the reply. After I posted I tried running a modified post-install script:
> 
>     /sbin/weak-modules --add-kernel --dry-run --verbose 2.6.32-504.8.1.v6.x86_64
> 
> and I got the following message:
> 
>     Module igb.ko from kernel 2.6.32-431.23.3.v6.x86_64 is not compatible  with
>     kernel 2.6.32-504.8.1.v6.x86_64 in symbols: set_ethtool_ops_ext
> 
>  From contacting someone else this looks very similar to this Elrepo bug 
> <http://elrepo.org/bugs/view.php?id=517> so I am suspecting the update to the 
> 2.6.32-504.8.1.v6 kernel broke compatibility. It seems to have happened on both 
> Intel drivers but not the Realtek r8168 or r8101 drivers. This is a PITA for me 
> and probably nothing you can do anything about so I'll have to recompile and 
> keep 2 versions for people on different kernel versions.
> 
> Regards,
> 
> Nick

Yes, you will need to recompile against the newer kernel.

When this happens we normally just rebuild and bump the release by one.
If when built against the newer kernel the module is then no longer
backward compatible with older kernels we add a Requires for the newer
kernel - this will prevent users from updating who are still on an older
OS release.