Snapshots and opkg

Hello everyone,
I am slightly customizing my openwrt images using the imagebuilder. I add some basic extra packages and install on my routers, so far without problems. I am able to use opkg to install some extra packages on them, and this works for a couple of days, but then if any new kernel is submitted, opkg fails to install anything new. Example below:

root@OpenWrt:~# opkg install zram-swap
Installing zram-swap (8) to root...
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for zram-swap:
 * 	kernel (= 5.4.109-1-27dc69a3a9c10175d770b3e54c6436d0)
 * opkg_install_cmd: Cannot install package zram-swap.

so what would be the best way to build a custom image and still be able to use opkg ?

Thank you a lot !

If you are building your own images anyways, why don't you just include the additional packages in the image?

See also


I do include my packages, but some days after, I want to test something new without the time of having to recompile/reflash or reboot the router ! Help !

When you get the message “Cannot satisfy the following dependencies for…” it is most likely because you installed a snapshot version of OpenWrt.
Read here for possible solutions.

As general advice, especially for inexperienced users: Go for the latest stable release (if available for your device), not a snapshot version, then the package repositories will match and packages will be available.

Solution #6: Compile the packages you want to install after flashing as modules. They will be built, but not included in the image.

1 Like

Thanks eduperez, that link provided some guidance. In particular, I see Persistent kmods for snapshots, which is what I would like to be able to do.
My distfeeds file has theorically the path to those kmods from my running kernel:

src/gz openwrt_core
src/gz openwrt_base
src/gz openwrt_kmods
src/gz openwrt_luci
src/gz openwrt_packages
src/gz openwrt_routing
src/gz openwrt_telephony

Should I also bypass satisfy_dependencies_for ?

edit: just tried and it seems there is some kind of bug, see below:

root@OpenWrt:~# opkg install --force-depends zram-swap
Installing zram-swap (8) to root...
Installing kmod-crypto-acompress (5.4.109-1) to root...
Installing kmod-lib-lzo (5.4.109-1) to root...
Installing kmod-zram (5.4.109-1) to root...
Configuring kmod-crypto-acompress.
Configuring kmod-lib-lzo.
Configuring kmod-zram.
Configuring zram-swap.
zram_applicable: [ERROR] device '/dev/zram0' not found
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for zram-swap:
 * 	kernel (= 5.4.109-1-27dc69a3a9c10175d770b3e54c6436d0)

Why is it trying to download mod-crypto-acompress (5.4.109-1) to root, etc... if I do have a distfeed configured to picking up stuff from 5.4.108-1 ?

Unfortunately the kmods feed contains only kmods for the running kernel.
Meanwhile, you want to install the package zram-swap that depends on a later kernel version.
You can try the solution #2, and if that doesn't help, then the solution #1.

1 Like

Wouldnt it be possible to make zram-swap depend on the kmod and not on a specific kernel, and have that kmod provided by my distfeed ? I think of this because lot of kmods rely on tools to manage them. If the kmods can be installed and the tools fail, it makes no sense to the distfeed. What do you think ?

ps: is there a way I can edit at least the specific zram-swap package to make it compatible with 5.4.108 ?
ps2 (new edit): I see 2 available packages, how do I select the one for my kernel ?

root@OpenWrt:~# opkg list|grep zram
kmod-zram - 5.4.108-1 - Compressed RAM block device support
kmod-zram - 5.4.109-1 - Compressed RAM block device support
zram-swap - 8 - A script to activate swaping on a compressed zram partition. This could be used to increase the available memory, by using compressed memory.

To be fair, zram-swap is just a shell script, thus you should be able to override its version-specific dependencies.
However, it may not be so simple for other packages which rely on a specific kernel feature/version, so this approach can be problematic in general case.

You should match the running kernel version:

uname -a; opkg list-installed kernel
1 Like

I saw and downloaded manually that script from github yesterday which solved that specific trial of zram-swap. Some times I am prompted with multiple available packages for different kernel versions, see for example this trial to install wireguard module. First, the available packages: kmod-wireguard - 5.4.108-1 and kmod-wireguard - 5.4.109-1. If I try to install it, something gets confused:

root@OpenWrt:~# opkg install kmod-wireguard
Installing kmod-wireguard (5.4.108-1) to root...
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-wireguard:
 * 	kernel (= 5.4.109-1-27dc69a3a9c10175d770b3e54c6436d0)
 * opkg_install_cmd: Cannot install package kmod-wireguard.
root@OpenWrt:~# uname -a; opkg list-installed kernel
Linux OpenWrt 5.4.108 #0 Sun Mar 28 10:16:24 2021 mips GNU/Linux
kernel - 5.4.108-1-27dc69a3a9c10175d770b3e54c6436d0

it seems to try to download 5.4.108 and blames a dependency on 5.4.109. Weird.

1 Like

There's only version-specific kmods feed, but there's no version-specific packages feed.
The feed for packages is a rolling release, so the issues for snapshots are inevitable.

1 Like

The thing is here something really weird is happening, and it is 100% kmod-related (I am trying to install kmod-wireguard). It does find it in the distfeed, but shows a dependency to kernel 5.4.109 which to me makes no sense.

You can use stable releases as mentioned above or automate the upgrade process:

Sorry, maybe I misunderstood, but I am not trying to install wireguard-tools, just the kmod, which finds himself with the current kernel, but gives a weird error after that. This makes the use of kmod distfeeds useless I guess. I am not understanding well here !

1 Like

I see, it looks like a bug.
Well, snapshots have never been considered stable. :upside_down_face:
And the kmods feed is not a complete solution anyways.
So, you probably shouldn't rely on it too much.

1 Like

if you use force depends does it work? to shed a little light / paraphrase here...

  • most kmods are available from openwrt_core ...
  • as core is dynamic ( todays kernel ) YOU are telling opkg to find packages in this repo... so it's not weird that it complains about an incorrect dependancy for a package it found available that you asked it to install and told it where to look
  • the only weird aspect is that it fails to recognize a compatible one was also found and to 'prefer' that... ( which implies feature-for-feature / "abi-version" like awareness for all kmods from their interdependent packages ( something currently not implemented ) so one would have to "trust-all-kmods-with-the-same-primary-name" in order to fully achieve your goal given the available underlying capabilities )...

but as @vgaetera says... and as you found with zram... there are interdependancies that often are not so easily resolved...