[Yum] Weird yum/kernel problem

Brian Long (brilong) brilong at cisco.com
Fri Dec 12 13:11:26 UTC 2014


Bob,
Some questions & recommendations:
Why not use a supported RAID controller for a production server?

Have you tried using DKMS?  I found a guide for Ubuntu and a lot of what it says applies to Fedora:

https://help.ubuntu.com/community/RocketRaid

If I were the sysadmin of your box and it needed to be online as much as possible, I would use a LSI RAID controller.  There are others out there which work, but I’m most familiar with LSI.  Many vendors integrate their RAID controllers into their own RAID cards (Dell PERC, for example).  I would most definitely stay away from RAID controllers where the driver is not integrated into the mainstream kernel.

Just my 2 cents.

/Brian/
--
       Brian Long                             |       |
       Research Triangle Park, NC         . | | | . | | | .
                                              '       '
                                              C I S C O

On Dec 11, 2014, at 11:03 PM, Bob McKay <rimsnucse at gmail.com<mailto:rimsnucse at gmail.com>> wrote:

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:
http://forums.fedoraforum.org/showthread.php?t=300863
https://bugzilla.redhat.com/show_bug.cgi?id=1167222
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.
_______________________________________________
Yum mailing list
Yum at lists.baseurl.org<mailto:Yum at lists.baseurl.org>
http://lists.baseurl.org/mailman/listinfo/yum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/yum/attachments/20141212/d68d0efe/attachment.html>


More information about the Yum mailing list