OpenWrt Forum Archive

Topic: how do I force build to use package version compatible with my kernel

The content of this topic has been archived on 23 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

getting this error:

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-nfs:
 *     kernel (= 3.3.8-1-63ee11828acfdf163a501c90c2e97894) * 
 * opkg_install_cmd: Cannot install package kmod-fs-nfs.

I understand the cause.  Tried to force build process to checkout the version of kmod-fs-nfs that matches my kernel using

cd feeds
svn co -r 33696 svn://

and also changed feeds.conf to use:

src-svn packages svn://

since my build verison is r33696.  I did a clean build and I still see for kmod-fs-nfs CONTROL file:

Depends: kernel (=3.3.8-1-63ee11828acfdf163a501c90c2e97894), kmod-fs-nfs-common

which of course is not what I was hoping for since my kernel is:

root@OpenWrt:~# opkg list-installed | grep kernel
kernel - 3.3.8-1-1768c0ba3b291d20a23aec35cc28ae61

What am I doing wrong?

(Last edited by choogenboom on 16 Oct 2012, 23:16)

I should add that I understand rebuilding and sysupgrading the image is the typical advice.  I would like to avoid that since I am using extroot and have installed many packages that do not fit in the image. If I sysuprgade I will have to rebuild extroot and re-install all packages and configuration changes made after extroot was enabled.

Nothing wrong.

The checksum requirement (mainly based on kernel build options) is so strict that practically only the modules compiled in the same build run as the main kernel do pass it.

You might use the --force-depends option with opkg to force it to ignore the dependency requirements and just install the packages.

That is risky and can break things if you try to install actually incompatible packages.

(Last edited by hnyman on 16 Oct 2012, 23:25)

Thanks for your reply,  not sure I am comfortable forcing it to ignore the kernel check since its a kernel module. 

I am still not ready to give up on the clean solution of finding and using the compatible package version.  There must have existed, at the time I did the image build, a version of that package that agreed with my kernel.  Or is that an incorrect assumption?  Assuming my assumption is correct, how is it I can't get at that version now and use it?

You are running into the effects of changes in January:
(Bug tracker server is currently down, but that is the change made then.)

Kernel version/name includes now a hash checksum of config options, and the kernel modifications will depend on that checksum as it is part of the kernel version/name. The goal is to ensure that the kmods to be installed have been compiled using exactly the same options as the main kernel.

That will decrease the possibility of installing kernel modules from trunk snapshot directory for older openwrt installations, as the default kernel config changes every now and then.

To be able to reproduce the same checksum, you would need exactly the same kernel options in your .config that have been used when compiling the main kernel. (Just having the same source code revision is not enough.)

In practice, if you have the same source code revision and you have vanilla kernel compile options, there should be no major risk in overriding the checksum. Most likely you will never be able to reproduce exactly the same kernel options, as the options in your .config have already been modified while compiling later source code revisions.

this extract from include/ is the code generating the checksum:

define Kernel/Configure/Default
# copy CONFIG_KERNEL_* settings over to
    awk '/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}' $(TOPDIR)/.config >> $(LINUX_DIR)/
    echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >> $(LINUX_DIR)/
    echo "# CONFIG_KALLSYMS_ALL is not set" >> $(LINUX_DIR)/
    echo "# CONFIG_KPROBES is not set" >> $(LINUX_DIR)/
    $(SCRIPT_DIR)/ kconfig $(TMP_DIR)/.packageinfo $(TOPDIR)/.config > $(LINUX_DIR)/.config.override
    $(SCRIPT_DIR)/ 'm+' '+' $(LINUX_DIR)/ /dev/null $(LINUX_DIR)/.config.override > $(LINUX_DIR)/.config
    $(call Kernel/SetInitramfs)
    rm -rf $(KERNEL_BUILD_DIR)/modules
    [ -d $(LINUX_DIR)/user_headers ] || $(MAKE) $(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install
    $(SH_FUNC) grep '=[ym]' $(LINUX_DIR)/.config | LC_ALL=C sort | md5s > $(LINUX_DIR)/.vermagic

(Last edited by hnyman on 17 Oct 2012, 00:01)

Thanks for the detailed explanation.  I can't say for sure, although it sounds likely, if my .config file changed.  For now I crossed my fingers and forced it and it worked.

Just found this threat and need recommendation:

I use barrier-braker 14.07 (the official current stable) but the kernel-modules in the official repository are incompatible:

Installing kmod-video-core (3.10.49-1) to root...

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-video-core:
 *     kernel (= 3.10.49-1-ae8faac940b75972a8aae78a94418b56) * 
 * opkg_install_cmd: Cannot install package kmod-video-core.

Since I don't know where are the modules, the official kernel was compiled with: Is it safe to just force install of the official kernel-modules I need?

My sources for openwrt:

src/gz barrier_breaker_base
src/gz barrier_breaker_luci
src/gz barrier_breaker_packages
src/gz barrier_breaker_routing
src/gz barrier_breaker_telephony
src/gz barrier_breaker_management
src/gz barrier_breaker_oldpackages

Exact version-information from LUCI:

Firmware Version OpenWrt Barrier Breaker 14.07 / LuCI Trunk (0.12+svn-r10530) 

Kernel Version    3.10.49


Oh! The answer is no! Just tried it. After a reboot...boom...router doesn't startup anymore. Luckily I was using extroot and have a backup of the stick.

Somebody knows where to get kernel-modules for present stable-release of openwrt?

badpitt wrote:

Oh! The answer is no! Just tried it. After a reboot...boom...router doesn't startup anymore. Luckily I was using extroot and have a backup of the stick.

are you a regular user of ext-root?
I am using ext-root beucause i think my modem flash has got badblocks so I have to install an small image that just is enough to load the ext-root from usb.
have you found any solution for the incompatibility in kmod packages and kernel?
how does linux on desktop manages this  stuff?
is it because kernel in desktop in a general kernel with most option built in and its config is not changed?

how do I make it so that the kernel config is not changed?

I have customized some options that are not package related (like disabling ipv6). what are any other option that affects that damn tag that checks the compatibility?

how can I make sure that my packages get updated but that tag number doesn't change?
btw that tag is not only for kernel , but also for other packages like procd and procd-nand.

can I NOT update the git of openwrt and just update the git of packages repo and be sure that the packages are now compatible with the kernel? what I am asking is that if I dont touch kernel options( whichever part of .config file they are) and not update git of main repo , can I be sure that the tag dont change?

when I started to use ext-root I tought (based on my limited understanding ) that first kernel loads the second kernel from usb somehow and I would have a complete system on the usb. but know I know that is impossible to do that on consumer routers.

$(SH_FUNC) grep '=[ym]' $(LINUX_DIR)/.config | LC_ALL=C sort | md5s > $(LINUX_DIR)/.vermagic

changing any byte of .config will cause vermagic change

to override it replace mentioned line with

echo "release_hash" > $(LINUX_DIR)/.vermagic

where release_hash is a hash used while building official image (just check downloads for you platform and you will find kernel package there with that hash)

The discussion might have continued from here.