| The weirdness continues. I never got 3.17.3 working, but a week or so ago, after 3.17.7 had been out for a while, I tried again, and the build worked flawlessly. So I was feeling reasonably confident to try 3.17.8 last week. But it failed. So I rebooted to 3.17.7 and used rpm to remove 3.17.8 (maybe I should have used yum, but I don’t know how to do that for a kernel). I then tried to build the module again. But although I was in kernel 3.17.7, and 3.17.8 had been removed, it believed it built a kernel for 3.17.8! i.e. the reverse of my previous problem. A bit confusing - it couldn’t have actually built a kernel for 3.17.8, because all the relevant headers and libraries no longer existed - but somehow it thought it had, and this seem to relate to another issue. It turned out that an rpm uninstall didn’t remove the boot files for 3.17.8; removing those by hand allowed me to build a module for 3.17.7. So it looked like the build system decided what kernel it had built for by checking what was the latest in /boot??? But this can’t explain the whole problem, because we can be absolutely certain that when I was building for the 3.17.8 kernel, the boot files were available (after all, I was booted into it).
So basing on Anders’ comment, it raises another possibility. When a new kernel arrives, I always delay installing it until the corresponding devel and header files are available in my local mirrors. But if I build soon after a new kernel turns up, it still always seems to fail. Waiting for a week or so often seems to do the trick (but difficult to experiment with, so I’m not certain). Does this ring any bells for anyone? Is there something else that the module build process could be relying on to determine what kernel it has built for - something that might not get updated for a few days in remote mirrors, after the kernel, headers and devel have arrived?
Thanks for any suggestions Bob
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.
|
