I’m not sure whether the problem I’m about to describe is a yum problem, or a problem with the way the kernel packages are set up in our Fedora 20 server. If this is the wrong place to ask, I’d really appreciate a pointer to the right one (the Fedora mechanism
for yum kernel updates seems to be particularly complex, and I haven’t properly understood it yet, which is why I’m not sure where the real problem lies).
I have some RAID hardware that requires a driver module to be built after every kernel update (all updates are performed with yum, not package-manager). My process is to disable the hardware, boot to the newly-updated kernel, build and install the module,
then re-enable the harware and reboot. Since about mid year, I have been having repeated problems building the module. When I build it, the build appears to succeed, but install fails, saying that the module wasn’t built against the running kernel. This seems
to be correct - when I manually check the magic of the built module, it shows the preceding kernel (i.e. at the moment, 3.17.2), although it was built under a running 3.17.3 kernel, and is installed in the correct location for 3.17.3 modules.
By the way, I have no clear idea how I got to a working 3.17.2 kernel - the problem originally occurred at 3.16.3, and I was stuck in that kernel for a long while. Fortunately I had some free time on the server a few weeks ago. Somehow something in a complex
sequence of grub2-install, grub2-mkconfig , removals and reinstallations of the corresponding kernel and kernel-devel, and module rebuilds changed something, and I managed to get the 3.17.2 update working. But I haven’t been able to figure out what it was,
or to reproduce it since.
Why it looks like it should build correctly: at the time of building, all kernel components have been fully updated. For example, at the moment, I have kernel, kernel-devel, kernel-modules-extra and kernel devel all at 3.17.3 (but of course, I also have
earlier versions of kernel, kernel-headers and kernel-modules-extra installed as well - in this case, including 3.17.2). When I try to do the build and install, it is booted in 3.17.3. So I don’t understand why it builds a 3.17.2 module.
It seems that at the time it is building the module, the system is somehow defaulting to building for 3.17.2. That suggests that a necessary flag recording the current kernel version isn’t being updated when the kernel is updated or booted - I haven’t
been able to figure out how the system decides what the current kernel is, so I don’t know where this flag might be. Any suggestions on how this is done (and why it might be failing, or how to check it) would be really appreciated.
There is more detail on the problem at:
but unfortunately no responses in either place yet (possibly because there isn’t sufficient detail - but I have no idea what else to supply).
The system is a production server; it’s currently running stably with 3.17.2, and I can’t reboot very often, so any suggestions that would help me to diagnose this problem without rebooting would be particularly appreciated.
