Kernel Mismatch on self compiled firmware and module

I have compiled the RC1 r3042 and some file system support as module. I copied over the router and install it.
Then I receive the error message saying that the kernal mismatch. Strangely, some will get passed
I then delete the package with problem from my build system, then compile again. Same error.

Any idea?

# opkg install kmod-fs-vfat_4.4.42-1_mips_24kc.ipk --force-check
Installing kmod-fs-vfat (4.4.42-1) to root...
Ignored kmod-fs-vfat sha256sum mismatch.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-vfat:
 * 	kernel (= 4.4.42-1-e5354221548c6c1d2077b0ae77f2f96d) * 	kernel (= 4.4.42-1-e5354221548c6c1d2077b0ae77f2f96d) * 	kernel (= 4.4.42-1-e5354221548c6c1d2077b0ae77f2f96d) * 
 * opkg_install_cmd: Cannot install package kmod-fs-vfat.

# cat /etc/*-release
VERSION="17.01.0-rc1, Reboot"
ID_LIKE="lede openwrt"
PRETTY_NAME="LEDE Reboot 17.01.0-rc1"
LEDE_TAINTS="no-all busybox"
LEDE_RELEASE="LEDE Reboot 17.01.0-rc1 r3042-ec095b5"

This is because the devs think that a different kernel config can cause issues with upstream kmod so they are made incompatible by default, but I think it would be better to warn the users they are not using the standard kernel config but let them proceed than block them outright.

Do I need to adjust my build setting to keep them align?

it's well documented over a long time that there are kernel config options that
must be the same for modules to work. Sometimes the problems are subtle
corruption issues, not obvious crashes.

It's far from all kernel config options, but rather than trying to identify
which ones are safe and which are dangerous, the play-it-safe approach is to
only allow modules to be loaded that were built from the same source tree and
config options as the original kernel.

For users, either they should build things themselves, or they should stick to a
release (which LEDE hasn't had yet) and only use things from that release.

David Lang

1 Like

Thanks @dlang

I suspect I did something wrong with git (never use git until recently try to compile LEDE)

I think have this solved. I think I was taking a customized config file at the very beginning

After getting the 17.01-rc1 config.seed for my chipset, renamed it to .config and did a make defconfig, the compiled firmware can now install the package built by the buildbot

Is it possible to build a kernel .ipk with the same name as the build bot?
I built v17.01.1 using the following instructions from @hnyman, however the kernel filename has a much different signature than that of the buildbot (listed below).


I suspect the string in bold is an MD5sum which would be nearly impossible to duplicate.

Filename pays no role. The dependency is in the package metadata.

The string is a md5sum of the kernel options & modules used in kernel compilation. In practice it is impossible to duplicate in a private build as you do not build all kernel modules. The checksum is a guard against mixing private kernel modules with downloaded firmwares or vice versa, as those could easily brick the router. dlang gives a good summary above.

If you need/want custom kernel modules, you need to compile the whole kernel at the same time. (in practice, the whole firmware)

Note: it is possible to override the checksum check (package dependency check) when you install a package with opkg, but that is highly risk and may brick the device or corrupt some data...
opkg install --force-depends XXX.ipk

Thanks @hnyman. It's not custom kernel modules I'm after, but a simple one line change to concatenate NAND flash partitions on my wndr3700v4:

I would love nothing more than to use an official pre-built image, but it appears I'm stuck either building the entire firmware (with local patch), using imagebuilder (which appears to be missing all profiles BTW) with the same local patch, or using extroot and USB storage (which I'd rather not) :disappointed:

The is simple "one line change" goes rather deeply into system startup things...

Modifying disk partition layout for the booting process requires compiling and flashing the whole firmware. No way to avoid that.

False alarm. There is no ImageBuilder bug.
For some reason my path was causing the issues I was seeing.