Managing kernel-updates in rpm
Hi, We have a rpm which installs a linux kernel driver. Now this driver has some kernel-level dependencies especially Development Tools (kernel-headers etc) such that they depend on running kernel version. Now in the rpm we provide drivers for different kernel versions since the user can update the kernel. In the rpm's SPEC file, we match the running kernel version with our driver for that particular version and install it. If the user has updated its kernel to such a version whose driver is not present in the RPM, the installation fails. We tell user in the error message to update the kernel to a supported version. Now this is very cumbersome and we plan to replace it with installing a yum plugin through our rpm which allows user to update the kernel level dependencies. Is this a right approach? Regards, Saket Sinha
Saket, IMO, explore the option of kABI and/or DKMS. http://people.redhat.com/jcm/el6/dup/docs/dup_book.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf HTH On Tue, Mar 25, 2014 at 12:54 PM, Saket Sinha <saket.sinha89@gmail.com> wrote:
Hi,
We have a rpm which installs a linux kernel driver. Now this driver has some kernel-level dependencies especially Development Tools (kernel-headers etc) such that they depend on running kernel version.
Now in the rpm we provide drivers for different kernel versions since the user can update the kernel. In the rpm's SPEC file, we match the running kernel version with our driver for that particular version and install it.
If the user has updated its kernel to such a version whose driver is not present in the RPM, the installation fails. We tell user in the error message to update the kernel to a supported version.
Now this is very cumbersome and we plan to replace it with installing a yum plugin through our rpm which allows user to update the kernel level dependencies.
Is this a right approach?
Regards, Saket Sinha
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- easy is right begin right and you're easy continue easy and you're right the right way to go easy is to forget the right way and forget that the going is easy....
Let me describe a scenario to explain my question - I first deployed a RHEL machine which happened to boot into kernel-2.6.32-358.14.1.el6.x86_64. Some time later I decided to install kernel-headers and kernel-devel, and therefore I ended up with kernel-devel-2.6.32-431.5.1.el6.x86_64 and kernel-headers-2.6.32-431.5.1.el6.x86_64. Note that these differ from the running kernel in minor version (358 and 431). This is normal and expected with RHEL but it breaks the installation of my driver. I will also explain why my driver has dependencies on these packages In this condition, my driver rpm will try to install a driver for version 2.6.32-358.14.1.el6.x86_64 which is the currently running kernel. Since the rpm does not contain a driver for this exact kernel, I do not fail my driver. NOW HERE WHAT CAN I DO. I HAVE FOUND THE FOLLOWING SOLUTION. In my rpm's SPEC file, I try to build my driver with kernel-devel & Development Tools. Thus my rpm has dependencies on two packages kernel-devel and development-tools. Most of the times this is successful. But look at the above scenario. What all I have in the above scenario- kernel-devel-2.6.32-431.5.1.el6.x86_64 kernel-headers-2.6.32-431.5.1.el6.x86_64 kernel-firmware-2.6.32-358.14.1.el6.noarch kernel-2.6.32-358.14.1.el6.x86_64 And although it appears that kernel-devel is installed, it is installed for a different version from the running kernel, hence the failure. Now I thought of installing a yum plugin with my rpm to handle kernel updates rather than the above approach. Is this approach right? Regards, Saket Sinha
On Tue, Mar 25, 2014 at 12:54:12PM +0530, Saket Sinha wrote:
Hi,
We have a rpm which installs a linux kernel driver. Now this driver has some kernel-level dependencies especially Development Tools (kernel-headers etc) such that they depend on running kernel version.
I'd ask you first off, why is your kernel driver not merged upstream with the main kernel.org releases, to prevent any of these issues from ever happening? Do you have a pointer to your driver somewhere so we can look at it to determine what is needed to be done to get it merged properly? thanks, greg k-h
Hi Greg, Please find my response inline-
We have a rpm which installs a linux kernel driver. Now this driver has some kernel-level dependencies especially Development Tools (kernel-headers etc) such that they depend on running kernel version.
I'd ask you first off, why is your kernel driver not merged upstream with the main kernel.org releases, to prevent any of these issues from ever happening?
Its a proprietary driver so its not meant to be the part of mainline kernel. :(
Do you have a pointer to your driver somewhere so we can look at it to determine what is needed to be done to get it merged properly?
I am sorry but I am not allowed to do that. Regards, Saket Sinha
On Tue, 25 Mar 2014 18:18:35 +0530, Saket Sinha said:
Its a proprietary driver so its not meant to be the part of mainline kernel. :(
Hey Greg - how long did Linux carry around an entire freaking *architecture* for the Voyager when there were only like 4 systems on the *planet* still in existence?
Do you have a pointer to your driver somewhere so we can look at it to determine what is needed to be done to get it merged properly?
I am sorry but I am not allowed to do that.
If you can't do that, you *probably* can't legally ship the code to customers either. Just thought you should consider that...
On Tue, Mar 25, 2014 at 09:32:11AM -0400, Valdis.Kletnieks@vt.edu wrote:
On Tue, 25 Mar 2014 18:18:35 +0530, Saket Sinha said:
Its a proprietary driver so its not meant to be the part of mainline kernel. :(
Hey Greg - how long did Linux carry around an entire freaking *architecture* for the Voyager when there were only like 4 systems on the *planet* still in existence?
There was only 1 working system, and it was years :)
On Tue, Mar 25, 2014 at 06:18:35PM +0530, Saket Sinha wrote:
Hi Greg,
Please find my response inline-
We have a rpm which installs a linux kernel driver. Now this driver has some kernel-level dependencies especially Development Tools (kernel-headers etc) such that they depend on running kernel version.
I'd ask you first off, why is your kernel driver not merged upstream with the main kernel.org releases, to prevent any of these issues from ever happening?
Its a proprietary driver so its not meant to be the part of mainline kernel. :(
Do you have a pointer to your driver somewhere so we can look at it to determine what is needed to be done to get it merged properly?
I am sorry but I am not allowed to do that.
Then I'm not allowed to help you, and asking for help from the community seems a bit rude to the community that you are relying on for your product. Take a look at this for details: http://www.linuxfoundation.org/collaborate/workgroups/technical-advisory-boa... Good luck with the lawsuits, greg k-h
On Tue, 25 Mar 2014 12:54:12 +0530, Saket Sinha said:
Now this is very cumbersome and we plan to replace it with installing a yum plugin through our rpm which allows user to update the kernel level dependencies.
dkms is your friend. Look to see how VirtualBox and NVidia use it for their kernel code.
participants (4)
-
Greg KH -
parinay -
Saket Sinha -
Valdis.Kletnieks＠vt.edu