I would like to create a custom build, but retain the ability to install kmod packages from the official repository.
On most custom builds installing kmods fails with an error like this:
Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-sched-ctinfo: * kernel (= 5.10.x-XXXXXXXXXX) * * opkg_install_cmd: Cannot install package kmod-sched-ctinfo.
This is because OpenWRT has a system called “vermagic” that ensures you can only install kmod packages with the same settings as the build config settings of the kernel you are running.
But OpenWRT publishes the build settings for all official builds. So it’s possible to download them and build a custom image with exactly the same kernel build settings.
This results in a custom image that has the same vermagic as the official image, which makes it possible to install kmod packages from the official opkg repository.
And since the vermagic hash is calculated only based on the kernel build config, it’s possible to also apply additional patches to the kernel and still get a custom image that has the same vermagic and allows kmod installs.
My question is… Can a patched kernel with an official vermagic value create issues or instabilities when you use kernel module packages from the official repo?
What I mean is… just because it’s possible to do something, it doesn’t necessarily mean that it’s a good idea.
I want to understand what exactly is the vermagic system trying to achieve and protect the user from?
A) Only ensuring that the build settings of kmods and the kernel match, because them not matching can cause problems. But the underlying code or deftrees of the kernel are not important.
B) Ensure that the kmods are used with EXACTLY the same kernel they were built with.
In that case the vermagic system does not fully protect against this and is easily circumvented, because it only hashes the build settings, but not the actual kernel code.
Thank you in advance for your help!