Minimum requirements for building kernel in-tree

I’m seeing an issue building a kernel in Alma 9.2. I have pared it down to the bare essentials in a docker:

echo -e  "FROM almalinux:9.2\nRUN dnf install -y kernel-devel" | docker build --file - --tag alma .
docker run alma bash -c 'cd /usr/src/kernels/*/ ; make' |& tee build.log

This results in an error message, when it tries to build objtool:

make[2]: *** [Makefile:53: /usr/src/kernels/5.14.0-284.30.1.el9_2.x86_64/tools/objtool/objtool-in.o] Error 1
make[1]: *** [Makefile:69: objtool] Error 2
make: *** [Makefile:1420: tools/objtool] Error 2

(The build log is here)

What am I doing wrong?
Are there some dependencies missing?

I have tried dnf groupinstall "Development tools", dnf install kernel-tools kernel-core, but to no avail.

I also have the same error in a full installation on real hardware, but here I try to pare it down to a bare minimum.

that’s a bit of an oldskool way of building a kernel.

i’d do it in mock not docker, but shouldn’t make too much difference, the main point is that you’d be better off rebuilding an srpm unless you’re building a completely different kernel.

download srpm:

$ curl -O

install it (not as root!):

$ rpm -ivh kernel-5.14.0-284.30.1.el9_2.src.rpm

copy any patches you made into place:

$ cp mycoolpatch.patch ~/rpmbuild/SOURCES/

edit ~/rpmbuild/SPECS/kernel.spec to add your patches and maybe a new Release name e.g. above this line:

Patch2 mycoolpatch.patch
Patch999999: linux-kernel-test.patch


ApplyOptionalPatch mycoolpatch.patch
ApplyOptionalPatch linux-kernel-test.patch

create a new srpm:

$ rpmbuild -bs ~/rpmbuild/SPECS/kernel.spec --define 'dist .el9_2'

build rpm’s from srpm:

$ rpmbuild -ba ~/rpmbuild/SPECS/kernel.spec

or preferably:

$ mock -r almalinux-9-x86_64 --rebuild ~/rpmbuild/SRPMS/kernel-*.src.rpm --define 'dist .el9_2'

then go make a coffee, this’ll take an hour or more.

p.s. $ sudo dnf builddep kernel will generally install all of your dependencies, you may have to point it at a spec or srpm too, kernel-devel certainly won’t be enough. from your build log its pretty obvious you need to $ sudo dnf install diffutils

Hmmm. Thanks for the reply!

I don’t actually want to build a kernel - I just want to build some drivers as modules. When that failed I tried to pare things down to a bare minimum.

It’s been years since I played with rpmbuild. All I remember is that there were some weird dependencies on paths. I hope things have improved since then.

The dnf builddep kernel doesn’t seem to do what it should:
(in a clean almalinux:9.2 docker)

# docker run  almalinux:9.2 bash -c 'dnf install -y dnf-plugins-core && dnf builddep kernel'
Package gawk-5.1.0-6.el9.x86_64 is already installed.
Package coreutils-single-8.32-34.el9.x86_64 is already installed.
Package openssl-1:3.0.7-16.el9_2.x86_64 is already installed.
Package xz-5.2.5-8.el9_0.x86_64 is already installed.
Package findutils-1:4.8.0-5.el9.x86_64 is already installed.
Package hostname-3.23-6.el9.x86_64 is already installed.
Package bash-5.1.8-6.el9_1.x86_64 is already installed.
Package binutils-2.35.2-37.el9.x86_64 is already installed.
No matching package to install: 'glibc-static'
Package tar-2:1.34-6.el9_1.x86_64 is already installed.
Package gzip-1.12-1.el9.x86_64 is already installed.
No matching package to install: 'gcc-plugin-devel'
Not all dependencies satisfied
Error: Some packages could not be found.

I should have some time to play with the ‘proper’ way of using srpms later. It sounds promising.

its doing exactly what it should - installing all the BuildRequires, some aren’t found as you haven’t enabled the repo’s and some are already installed in the base image.

you’ll have to enable the CRB repo for certain and i think devel too, that’s why mock (or even an almalinux vm) is better than docker.

if you’re just building a kernel module, that’s different, here’s a couple of tutorials albeit a bit dated/incomplete but if you’re advanced enough to be building custom kernel modules you should be able to fill in the gaps:

Thank you for the patience! This was at least a large part of my problem.
I still haven’t quite understood the intricacies of using rpmbuild properly - I deed to dive a bit deeper into that.

But at least now I understand more of what’s happening.

(I normally try to do most of the development/compilation in a dedicated VM or on real hardware, but I wanted to pare things down to a bare minimum, to figure out what went wrong. )

Another way to build a kernel module will be to look at some existing package and start from there to make your own. One such example is:

This is a kABI-tracking “Hello World” package that should survive kernel updates. That’s a bonus.