Kernel version incompatible

Installing and Using OpenWrt
1

Hi

I tend to compile my own OpenWrt firmware so that I can package the apps I want. When compiling I always use the latest stable builds rather than the bleeding edge nightly builds so that I can almost guarantee 100% stability. Once I've pulled OpenWrt from GitHub I use the following commands to see the versions available

git tag
git branch

and then use git checkout v19.07.1 to select the desired OpenWrt version.

Once I have finished compiling and I have flashed the firmware to the router everything works as expected.

On the rare occasions I want to install an app I didn't initially bake into the firmware, I use the OPKG LuCI app to install any new apps. The problem I'm facing more and more often with my own compiled firmware is, I'm getting the Kernel version incompatible message when I try to install an app. For example I'm trying to install the luci-app-nft-qos and get this

The installed version of package kernel is not compatible, require 4.14.167-1-a92a3f5c… while 4.14.167-1-da4f6ade… is installed.

Looking at those numbers above that almost identical except for the last section which i assume is the GitHub commits.

This is my OPKG distfeeds.conf

src/gz openwrt_core http://downloads.openwrt.org/releases/19.07.1/targets/mvebu/cortexa9/packages

src/gz openwrt_base http://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3/base

src/gz openwrt_luci http://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3/luci

src/gz openwrt_packages http://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3/packages

src/gz openwrt_routing http://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3/routing

src/gz openwrt_telephony http://downloads.openwrt.org/releases/19.07.1/packages/arm_cortex-a9_vfpv3/telephony

OPKG is configured to pull the v19.07.1 packages, the same version I compiled, yet the OpenWrt is telling me I have a different kernel.

Is there something I'm missing here?

2

try searching the forum for: ALL_KMODS ( and ensure your custom build does not alter any kernel options )

3

There is a strict checksum login of kernel options/selections at the compilation time for kernel related packages, which practically require you to compile the kmods at the same time as the firmware.

If you know that you have not changed kernel options, and that the selection of the new module does not change the compilation of other included modules, you can try overriding the opkg check with --force-depends option. Hopefully the router does not brick...

1 Like
4

No, it's not the commit identifier; it's a hash of the options used to compile the kernel. You will not have this issue if you compile your kernels using exactly the same parameters as the releases.

3 Likes
5

How do I set the same parameters as the releases please? My compiled firmwares are aimed at being exactly the same as the stable releases except for the packages I pack into them.

6

Use the "config.buildinfo" for your device, from the downloads page, and rename it to ".config" in your build environment.

7

Will running make menuconfig affect it anyway as I will need to add packages some of which the release doesn't include?

8

Your best approach is to build a new firmware with the needed kernel packages included. You are in any case building firmware by yourself, so that is the easiest thing.

Make menuconfig does not hurt if you do not touch any kernel related packages (no kmod may change from "m" to "y", or from "n" to any...)

1 Like
9

If I recall correctly, as long as you do not change any kernel-related parameters, it should work.

1 Like
10

I shall give it a go and post back later on. Cheers for your help so far, much appreciated.

1 Like
11

Is there a way I can see the kernel hash as I'm going along?

12

You ca try to mimic the command that calculates "vermagic":

But as that is run after the kernel prepare/setup/configure step during the build, you can't really see that from menuconfig, or just by running menuconfig.

2 Likes
13

Can you give more detail to change the vermagic? There is no clear information to make it.

14

all the details are above. ...the whole source code related to the issue...

It is a hash of all kernel config & options at the compilation time. Calculated automatically during the firmware build.

In practice it forces you to compile all requested kernel related packages at the same time as the kernel itself. If you add later a package to the config, the checksum changes. You can't prevent that.

Note that you might succeed if you compiled the SDK at the same time as the firmware and later use that SDK to compile the new module for the firmware.

15

adding any package with menuconfig changes vermagic. I use the default config.buildinfo to get the same.So there is no meaning to customize an image.