Chuck Campbell wrote:
how exactly where you planning on managing out-of-tree kernel drivers
otherwise ?
I've no idea... I've never had to deal with this before, so I didn't
even understand this could be an issue.
This is one the major issues with the Linux process these days, as you move from
kernel to kernel there is almost zero assurance of driver abi/api stability -
and that in turn creates a situation like this wherein one kernel works while
another does not. Its enough of a situation that on a lot of platforms sysadmins
will not upgrade a kernel unless they really really need to. On CentOS and the
EL codebase, this isnt so much of an issue because upstream do some work on
trying to make sure they dont break driver compatibility. If they do break this
compatibility, its easy to detect.
And most of the heavy lifting is getting done by a fairly simple shell script
called weak-modules, based in /sbin/ and comes from module-init-tools.rpm
weak-modules will basically take a given driver .ko and check what other kernels
installed at this time will work with it, it will then create the symlinks for
each of those kernels to point at this .ko. It will then check each initrd in
the /boot dir, and update each initrd for kernels it found compatible with the
driver. Rather than overwrite the initrd, it will create a new one with the
same-name but followed by a number. It will then edit /etc/grub.conf and add a
*new* section for this just created initrd. So when you reboot the machine you
have the choice to boot the kernel.rpm shipped initrd or the newly updated one.
Ok, so how does this work ? lets say you have drivers ( from install time ) in
/lib/modules/2.6.8-8.el5/updates/
1) sudo to root
2) find /lib/modules/2.6.8-8.el5/updates | /sbin/weak-modules --add-modules
3) watch the blinking lights, depending on how many kernels you have installed
it could be a few seconds
4) check /boot/ and make sure you have the new updated initrd's for all kernels
you thought it would work with.
5) check /etc/grub.conf for new sections [1]
6) reboot with whatever kernel + initrd you want
7) all further kernels brought down by yum from the centos repos will auto
magically get this driver included in the initrd. ( rpm -q --scripts
kernel-version will show you what happens in the post install section, and how
weak-updates does an --add-kernel )
thats about it. Give it a shot and let me know how you get along. I am writing
this from memory so i might have missed something :) One way to find out....
btw, before everyone crys foul over where the drivers are put insalltime -
remember, even when the kernel rpm is removed, because there are files under the
tree that are not owner by rpm, it wont zap those files. So once in the system
your driver is going to stay there. Keep that in mind.
I will try this in a few moments. One last observation though, 3Ware has
a newer driver for the updated kernel. If I wish to use it, is it a simple
matter of replacing the 3w-9xxx.ko file with the appropriate one? If it
is more complicated than that, where do I find info about this issue?
well, in this case, build that .ko agains the oldest kernel-devel you have on
the machine ( ideally, I should say only against the installtime kernel, but
lots of people dont have that hanging around :/ ) and weak-modules should do its
magic.
I shall try and do some more specific docs on this, in the centos wiki,
over the next few days.
Thanks, I'm anxious to learn, since I'll probably need to deploy more systems
with this (and other similar) issue(s).
Slight change in plan, I did this braindump and you get to write the wiki page
:) You might also want to look and see how the /lib/modules/<kver>/extras/
directory contents are handled and include some info on that. Since that would
basically address non install time .ko
[1] I know its called "Red Hat Updated Driver Model", if someone files a bug at
http://bugs.centos.org/ I will make sure that its changed for next update.
--
Karanbir Singh : http://www.karan.org/ : 2522219@icq
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
