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/
Related
I am making an operating system with Yocto. I created new meta, new layer, new recipe and new machine. It was working fine until I tried to include packages already compiled for debian. Normally, I was installing these packages with the apt-get command after flashing the image, but as the number of packages increased, they started to conflict with the packages that came with the image and compiled with bitbake, so I am trying to add these packages as a recipe.
Can I create recipe directly from .deb file or .dsc file? If I can't create it, how can I find the source code and how can I create a recipe from the source code?
I'm currently using the OpenEmbedded dunfell version, but I'm planning to switch to the kirkstone version. Since I'm using dunfell version, I'm looking at debian's stretch version packages. Which version packages of debian should I look for when I switch to kirkstone version?
I am compiling for armhf architecture on Intel 64 bit Ubuntu 18.04. I'm compiling for a custom board.
These are the packages I'm trying to install for now (I think I can install similar packages if I can install them with a recipe):
xbindkeys
libcrypto++6
libcurl3-gnutls
default-jre-headless
libccid
libpam-pkcs11
pcscd
libacsccid1 (This is special because it only has deb package. There is no source code or dsc file.)
Whilst Yocto Project and OpenEmbedded can output deb packages they are only compatible with the DISTRO setting that built them in OE. Packages from Debian are not compatible.
You can look at https://layers.yoctoproject.org/ to search for recipes in other layers which may be able to build what you need once those layers are added.
Where you can't build from source you may be able to extract files from a Debian deb and turn it into a different deb that might work with OE but it assumes the binaries are compatible and they may or may not be depending on how you've configured your build. This isn't recommended.
I'm running an old version of my linux distro (fedora, but this is not very relevant) and for reasons which are completely irrelevant I'm not in a position to update it. However I do need a newer version of gcc and some other libraries than those supplied by my old distro.
I could compile a newer gcc and all the other libraries of course but I thought the simplest way would be to install a minimal set of packages from the latest distro version to a directory and then just chroot there. This way I'd take advantage of the binary packages present in the newest distro and all the infrastructure around it (like dependency installation, etc.) and I wouldn't need to compile everything from source.
My question is this: if I only would like to be able to compile with the most recent gcc and run those programs, what is the minimal set of packages I need? Since we are talking about fedora, what is the minimal set of rpms (beyond glibc and gcc)? Note that I don't need any X environment, networking, or anything like that, only the most basic terminal tools.
The minimal set varies depending on your user needs and what you're linking with. What I do when making a chroot environment is have a look at the distro I want to chroot and see if they have a base rpm/deb package that kickstarts everything. Then I install that in the chroot. From there I add libraries and applications as needed.
For an example where I create a chroot for RHEL on Arch see http://www.zenskg.net/wordpress/?p=267
The only source code related to perf I could find is in the kernel source, so am not sure what I need to do to get the latest perf.
If I upgrade the kernel version (leavin the rest of my distro unchanged), will I now get the latest version of perf or is there a user space library that I also need to rebuild?
Edit -
I see that the perf source is not actually in the kernel source but in a separate tools directory and I can just build this directory.
In deb based distribution perf is usually provided by a package with a name starting with linux-tools and yes, the version X of perf it's not designed to run on the kernel number Y, it's a program that is strictly tied to the kernel.
For example on Debian/Ubuntu you can write
sudo apt-get install linux-tools-$(uname -r)
I installed Fedora 19 x86_64 on My vmware workstation. When I try to install the third party software. it give me a message "can't find kernel source files".
I checked that the kernel version is 3.9.5-301.fc19.x86_64 via uname -r.
but I found the kernel source version is higher than the current running kernel version.
there are two symblic links in /lib/modules/3.9.5-301.fc19.x86_64 folder. they are
build -> /usr/src/kernels/3.9.5-301.fc19.x86_64
source -> build
They are broken, because there is no folder /usr/src/kernels/3.9.5-301.fc19.x86_64 in my system.
Can anyone tell me why this situation happens. and how to install correct kernel source in my Fedora.
Big thanks.
Any reason to not run the latest kernel? You might benefit from updating everything first.
# yum update
Doubt you actually need the entire kernel source. Have you installed kernel-devel?
# yum install kernel-devel
If you need more, next install kernel headers.
# yum install kernel-headers
If you do update the running kernel, reboot into that kernel before installing the 3rd party software.
You can check here what is the currently most stable kernel available (and download associated RPMs if you requiere):
https://admin.fedoraproject.org/updates/kernel
The same happened to me on my Fedora 19 box and my kernel version was: 3.14.4-100.fc19.x86_64 so VirtualBox was looking for the source here:
/usr/src/kernels/3.14.4-100.fc19.x86_64
I checked my /usr/src/kernels dir which and found that it was empty. Then I downloaded the kernel src from the net which was named:
kernel-3.14.4-100.fc19.**src**.rpm
and extracted to /usr/src/kernels/ and run:
/etc/init.d/vboxdrv setup
Which returned:
Stopping VirtualBox kernel modules [ OK ]
Recompiling VirtualBox kernel modules [ OK ]
Starting VirtualBox kernel modules [ OK ]
Was working great!
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.