#4305 There is a mismatch between running kernel version and kernel-devel RPM version.
Closed: Dropped by tkopecek. Opened by jaruga.

The rpms/systemtap[1]'s tests requires the kenel-devel RPM whose version is same with the current running kernel version (uname -r).

However, testing with my testing RPM spec file[2] and the koji scratch build on rawhide[3], f41 and f40, I see there is a mismatch between the running kernel version (uname -r) and kernel-devel RPM package version. The running kernel version is older and f41 build, while the kenerl-devel RPM package version is newer and f42.

You can see the following part in the build.log on the build[3]. This situation prevents the rpms/systemtap from enabling the test in the systemtap.spec's %check section.

build.log

+ uname -r
6.12.8-200.fc41.x86_64
+ rpm -q kernel-devel
kernel-devel-6.13.0-0.rc7.20250114gitc45323b7560e.56.fc42.x86_64

I am not sure if this is koji issue or a tool chain issue that koji depending on.

As a reference, we added a logic to run dnf upgrade and reboot OS on our tests/ruby's systemtap tests.[4] Though I am not sure if this is directly related to the solution of this issue. Because running kernel is for f41, and kernel-devel RPM is for rawhide in this case.

What do you think?

[1] https://src.fedoraproject.org/rpms/systemtap
[2] https://github.com/junaruga/report-kernel-devel-mismatch/tree/main
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=128613533
[4] https://src.fedoraproject.org/tests/ruby/pull-request/32#_2__17-19


This is a necessary evil in current process. Builder's kernel will almost never be exactly same as the buildroot's kernel-devel. E.g. one fedora builder runs specified kernel version but compiles packages for more fedora versions (or even if it would be for one fedora version there still be buildroots with updated non-released kernel) and as such they can't run the same one.
The best what we do is to run run ABI-compatible kernel on those builders. If it really makes sense in some cases it would need some releng cooperation (setup channel with pinned kernel version, add corresponding kernel-devel to buildroot), but that is the first time I hear anyone relies on exact same version of these.
Note that even konflux will have the same issues. Basically no one want to run builders on unreleased kernel.

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

Note that for purposes of systemtap, it would not need to be the exact same kernel version as the buildroot, just be close enough that if the %check phase does a yum install kernel-devel-$(uname -r), it'd get access to the right one. So e.g. any same-fedora-version kernel e.g. would be fine.

Koji itself doesn't really have control over the running kernel. It gets whatever kernel is installed on the builder. Koji manages installation of the buildroots, but not the host itself.

Situations like this are generally solved by provisioning builders with the needed kernel, putting them in a special channel, and setting up a target. This is something you'll need to take up with Fedora releng, as Tomas suggests. We can't really solve this in koji code

Metadata Update from @tkopecek:
- Issue close_status updated to: Dropped
- Issue status updated to: Closed (was: Open)

I suppose that koji infra using a bootable container (bootc) [1] including kernel in the container may solve this issue.

[1] https://docs.fedoraproject.org/en-US/bootc/getting-started/

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/4305

Please continue any further discussion there.

Metadata