I'm building an RPM that contain a kernel module.
Like all the other kernel modules, there is a dependency between the running kernel version to the kernel module.
I want to enforce this dependency, so if you want to update your kernel, you will need to update my rpm.
I was trying to do that with the spec file but without success.
Could you help me to find a way to do this?
Any other idea for enforce update of my kernel module during kernel update?
Related
I got a binary kernel module provided by 3rd party, which expects version magic 5.4.0-81-generic SMP mod_unload modversions aarch64 of the kernel. It means that I need to grab the exact source tree to build the kernel for using the .ko, on my own customized SoC platform.
Now I have serveral questions for this task:
5.4.0-81-generic: 5.4.0 seems refer to the official kernel version 5.4; what is 81? Is this a patch level (or abi number)?
Can I obtain the exact source tree by patching the official kernel version 5.4? If so, where can I find the corresponding patch file for patch level 81?
I can do apt install linux-source-5.4.0, but there is no patch level on the linux-source pkg name. However, to install the headers, there are patch level on the pkg name, e.g. apt install linux-header-5.4.0-81? Why the difference?
Thanks!
Ubuntu collects its own patched sources into a source package which you can download.
The version number includes a build version; the upstream sources (the Linux kernel) does not have an Ubuntu build, but each released build has a specific version with a number after the dash and you want exactly the right one.
apt-get install linux-headers-$(uname -r)
If you want the full sources,
apt source linux-generic
though in practice you want to read the instruction it prints and download the sources from Github.
Perhaps see also https://ubuntu.com/kernel and https://linuxhint.com/install-linux-kernel-ubuntu/
I tired to compile tun.ko linux kernel version 3.0.21+ for my older embedded system. Tried install jessie on my VM so i can use gcc4.8/gcc4.9, but no tun.ko built in my drivers/net after i hit make modules. I even use make allyesconfig and retry make modules but no luck. I just want tun.ko armhf for kernel 3.0.21+, cant find the binary so i want build it, but still no luck for both.
I am running into a issue with RH7 kernels. We are running RH6/Centos6 based systems - we normally compile the kernel module once (Centos6.6) and we could install the kernel module on another Centos kernel in the same series (say Centos6.4).
With Centos7 (3.10 kernel) I cannot build the kernel module with says 3.10.0-329 (Centos7.2) kernel and install on a kernel version 3.10.0-227 (Centos7.1) - insmod returns invalid format.
Anyone run into similar issues - are there any workarounds.
Thanks
--
Jimmy
Probably, you want a binary blob - ready-made object file which is part of the module. Look into kernel documentation for know how to build module which uses binary blobs. – Tsyvarev
I'm looking for the "best"* method to add the linux kernel headers and development libraries as a requirement for an RPM and Debian package I'm making. I know that I can add a "Requires: blah" tag in the RPM .spec file, and that I can do the analog in the Debian control file, but this will have the user download the latest kernel's headers/devel...not their current headers/devel.
For example, say the user is running linux kernel version 3.4, and the latest is 3.5. If they install the RPM via yum, and don't have any kernel headers or development libraries, they will download the 3.5 headers and development libraries. But when the software goes to build, it will try to find the 3.4 headers and development libraries and fail.
Thanks!
Debian at least easily allows you to specify a particular version in Build-Depends:. Usually you don't want to, but it's perfectly possible.
I do not understand why something like this would not suffice (something like a minumum kernel required)
Requires: kernel >= 3.5
BuildRequires: kernel-headers >= 3.5
i guess you are trying to build/package some 3rd party kernel modules (since afaik this is really the only type of package that should depend on kernel-headers).
if so, you probably want to have a look at how other kernel-modules are packaged, esp, check dkms, which is supported by all major distributions, and use that to build your kernel module.
What is the recommended approach for distributing a kernel module using a RPM? Ideally, for portability, I would like the RPM to be able to build the modules against the running kernel's headers before installing.
I've used Dynamic Kernel Module Support or DKMS before to distribute a Linux driver targeting multiple kernel versions (2.6.31-37). DKMS itself is a collection of bash scripts that can automate both the building and rebuilding of a kernel module based on the current installed version of Linux. You can distribute drivers as either RPM or DEB files which contain the driver source, DKMS scripts, and optionally, binary versions of the driver tied to particular kernel versions.