Kernel version in sources

I'm building image from sources as described in the manual.

But I am not sure that installed after sysupgrade image also updated the kernel. At least once I've got kernel and modules mismatch ("could not find modules for ... kernel version").

So, the question is, where in the sources the kernel version is written. To compare it with uname -rv output. (And the next question, if it differs what to do.)

I use Asus RT-AC65P if this matters.

when doing what ?
trying to install kmods from ?

When I got tge problem, I had to tftp the factory image from, and then sysupgrade to my built image. At least it works. (Kernel version the same or upgraded? Or not too different in number?)

No, I've sysupgraded to my image and got mismatch!

if you install your own image, the kmods usually have to come from you too...
there's a way of fixing it, though, it's been posted.

Yes! And kmods appered newer than kernel somehow! Kernel modules upgraded, but not kernel itself.

if your image is snapshot based, then yes, those modules/builds are updated/refreshed on a daily basis.

So, the kernel should have the same date as the build? Mine is older.

technically, they newer will, there will always be a mismatch.

as I said, snapshot builds are daily, even for people installing images from, everyone will get a kernel version mismatch error after < 24h.

want to avoid it, use stable, or refresh, recompile and reinstall every 24h.

1 Like

… or do this :


I do not quite understand what are you recommending.

I do

git pull
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig

But then, when I install the successfully built (without errors) sysupgrade image, not everytime everything is actually updated, for example, kernel sometimes stays the same old, but LUCi is updated and modules too. So, I had got a version mismatch problem at least once.

I am not sure this occurs every time, so was the first question: how to compare installed kernel version uname -vr with the version from sources I was compiling.

And, obviously, the second question: how to solve the problem if it occurs?

May be some "dangerous" options during menuconfig step which I should be aware?

Build everything at once by yourself.

With opkg, install overrrding the dependencies. But may soft-brick the device:

I do not use opkg.
I build everything by myself.
Sorry, if that wasn't clear from my first post.

Typical mismatches are from trying to use opkg, so I pointed at that. Sorry, if opkg is unrelated.

If you build everything from sources with the full toolchain (from a clean slate after a make clean), you should always get a coherent image, as everything is built at the same time.

As your problem is related to the actual build, I suspect that some build artefacts are from a different build run. You need a "make clean" before the build to ensure a clean build.

(Your commands looked ok otherwise. A "make menuconfig" or "make defconfig" is needed for dependency check after a source update, and you had that.)

1 Like

I suppose, I could have problem in sysupgrade process itself. The initial installation on that router was not that easy also. Had to use initramfs image in between.

As far as I've found out, kernel version could be checked in a built image if one open it like a tar file.

So, I will watch the situation and do make cleandir sometimes instead of just make clean.

To avoid such problems, you need to do the following things:

  1. Build the kernel so that it is binary compatible with official OpenWRT releases:
  2. When building images, you need to patch the vermagic kernel parameter:

And why should I have binary compartible kernel if I do not use opkgs?

Somehow kernel from the image file I installed actually did not install, but kernel modules did. So I 've got mismatch.

check the .vermagic part