[Resolved]Compile with specific kernel version?

I compile the snapshot for pi 4 using default configuration. When I try to install kmod-wireguard in opkg, I got this error

  • The installed version of package kernel is not compatible, require 5.4.52-1-1e805069… while 5.4.52-1-baff6070… is installed.

However, I can't find any way to select kernel modules that woudl sepcific 5.4.52-1-1e805069. I only find a place that could specify kernel to be 5.4. If I replace /home/XXX/openwrt/package/kernel/linux and in makefile set the patch version to 5.4.52-1-1e805069 will it do the job?


After running make defconfig
The Makefile in ~/openwrt/target/linux/bcm27xx still only says kernel version 5.4. Anyway to select the actual hash?

You need to compile kernel (and the whole firmware) and the kmod at the same time.

In practice, include the kmod in the image.

Only some kmod's do this.. others do not. Why a kmod needs to be compiled with reference and compared against HEAD is beyond me..

This not always practical or desirable though.

That library is keyed to a specific commit that was at the top of the stack when you compiled, for some reason.. I've seen a few others that do this and I'm not sure its really necessary, but I could be wrong :slight_smile: In any case, the only thing you can do is rebuild your packages. This is a real bummer for those who build all the packages, meh..

1 Like

You are wrong.
The kernel kmods set a a verification check via a hash "vermagic" compiled from the kernel options and kmods selected. That aims to ensure compatibility between kernel and all other kmods. So it is not about a commit, but more complicated. Anomeome already linked to vermagic search.

1 Like

So, why do some have those levels of checks and others don't? I'm genuinely trying to learn it :slight_smile:

It is kernel, kernel kmod packages and a few other kernel related userspace packages (that closely interact with kmods).

The goal is to ensure compatibility and prevent crashes. OpenWrt is so close to the actual hardware that many packages are driver-like. It is too easy to make hardware drivers to mysteriously crash if you have version mismatches between different components. That needs to also account for optional features that may be selected at compilation time. That may have impact on the interaction between driver components.

Earlier, ten years ago, there were too many end user problems / bug reports that were difficult to reproduce/debug as the reason was slight mismatches in driver components. So, a version hash was invented to prevent installing mixed components accidentally.

The version magic mainly affects master snapshot users, who try to later install new packages to the build.

1 Like

And that is exactly where I've run into it :slight_smile: Where the build changes but the packages didn't. Thanks for the explaination!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.