Packages: sqm-scripts: Commit ed1e001fd causes image builder error (for mt7621)

[azuwis]

Maintainer: @tohojo @ldir-EDB0
Environment: ramips mt7621 zbtlink_zbt-wg3526-16m

Description: After commit ed1e001fd, image builder fails when package sqm-scripts included.

Step to reproduce:

$ wget https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/openwrt-imagebuilder-ramips-mt7621.Linux-x86_64.tar.xz
$ tar xf openwrt-imagebuilder-ramips-mt7621.Linux-x86_64.tar.xz
$ cd openwrt-imagebuilder-ramips-mt7621.Linux-x86_64
$ make image PROFILE=zbtlink_zbt-wg3526-16m PACKAGES=sqm-scripts

Error message:

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for sqm-scripts:
 *  kmod-sched-cake-oot
 * opkg_install_cmd: Cannot install package sqm-scripts.
make[2]: *** [Makefile:158: package_install] Error 255
make[1]: *** [Makefile:118: _call_image] Error 2
make: *** [Makefile:207: image] Error 2

[hnyman]

mt7621 seems like a rarity:

The mt7621 subtarget has been changed to use kernel 5.4 with https://github.com/openwrt/openwrt/commit/1dce5c8a2835a05fbf532115a2baf0d1a8ca76c9 by @dengqf6 and @981213 in early April. However, the main ramips target is still with kernel 4.14 for some reason.

So, kernel packages like kmod-sched-cake are built with 5.4:
https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/kmods/5.4.36-1-3b786b630d02d27b2afc931a875ba4d9/

kmod-sched-cake-oot would be built for 4.14 but mt7621 has 5.4.

However, the user-space packages "mipsel_24kc" are built in the packages buildbot by using the mt7620 SDK toolchain and mt7620 is still with kernel 4.14 along the main ramips target. So, the sqm-scripts built there would expect to find a kernel package for 41.4, kmod-sched-cake-oot
http://buildbot.openwrt.org/master/packages/builders/mipsel_24kc/builds/244/steps/updatesdk/logs/stdio

So, mt7621 packages dependency logic is screwed for those few user-space packages that require such kernel packages where the package itself and the dependency change between 4.14 and 5.4.
I know only SQM and exfat to be such ones, so the bug likely hits only the users of those packages.

[sinancetinkaya]

Unfortunately I'm one of those users too :(

[tohojo]

Hmm, I guess this may end up being a situation that will stick around for a while, since there will likely be a long tail of targets being ported to 5.4. So we really do need to find a solution.

I guess we could add an intermediate kernel module package that will pick up the right dependency based on kernel version, and just have sqm-scripts depend on that.

But it's not clear to me why kmod-sched-cake-oot needs the -oot suffix in the first place? If it's only built for kernel versions that doesn't have the in-tree version, then why can't it just be called kmod-sched-cake as well? @ldir-EDB0 ?

[hnyman]

Note that

• it is about 4.14 vs. (4.19 or 5.4)
• only impacts the few targets that have a different kernel version in SDK used for packages compilation (phase2 buildbot) than in the target's own kernel compilation (phase1 images). One of them uses 4.14 and the other one 5.4 or 4.19. That is a rare issue. I am not sure if there are currently other ones than that mt7621 vs. ramips SDK.
• the problem does not affect self-built firmware with SQM (and cake) included, as the mismatch only concerns with opkg installing SQM to a firmware.
• does not affect release 19.07.x, only the bleeding edge master

why can't it just be called kmod-sched-cake as well?

It was tested earlier. It leads into nasty dependency problems if the same package is defined twice.

[tohojo]

Hannu Nyman [e-mail] writes:

Note that

• it is about 4.14 vs. (4.19 or 5.4)
• only impacts the few targets that have a different kernel version in SDK used for packages compilation (phase2 buildbot) than in the target's own kernel compilation (phase1 images). One of them uses 4.14 and the other one 5.4 or 4.19. That is a rare issue. I am not sure if there are currently other ones than that mt7621 vs. ramips SDK.
• the problem does not affect self-built firmware with SQM (and cake) included, as the mismatch only concerns with opkg installing SQM to a firmware.
• does not affect release 19.07.x, only the bleeding edge master

Sure. Still think it should be fixed :)

why can't it just be called kmod-sched-cake as well?

It was tested earlier. It leads into nasty dependency problems if the
same package is defined twice.

Ah, right, because you can't make the package definition itself
conditional on the kernel version. So how about we define a new virtual
package like:

define KernelPackage/sched-cake-virtual
SUBMENU:=Network Support
TITLE:=Virtual package for sched-cake
URL:=https://github.com/dtaht/sch_cake
DEPENDS:=+!LINUX_4_14:kmod-sched-cake +LINUX_4_14:kmod-sched-cake-oot
endef

And have sqm-scripts depend on that instead? As long as that virtual
package is built along with the kernel version, that should end up doing
the right thing, shouldn't it?

[hnyman]

That virtual cake kernel package might work as a short-term stopgap solution.

[azuwis]

How about use PROVIDES?

define KernelPackage/sched-cake-oot
  SUBMENU:=Network Support
  TITLE:=OOT Cake fq_codel/blue derived shaper
  URL:=https://github.com/dtaht/sch_cake
  FILES:=$(PKG_BUILD_DIR)/sch_cake.ko
  AUTOLOAD:=$(call AutoLoad,75,sch_cake)
  DEPENDS:=@LINUX_4_14 +kmod-sched-core +kmod-ipt-conntrack
  PROVIDES:=kmod-sched-cake
endef

define Package/sqm-scripts
  SECTION:=net
  CATEGORY:=Base system
  DEPENDS:=+tc +kmod-sched-core +kmod-ifb +iptables \
    +iptables-mod-ipopt +iptables-mod-conntrack-extra \
    kmod-sched-cake
  TITLE:=SQM Scripts (QoS)
  PKGARCH:=all
endef

[hnyman]

As mentioned in http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022526.html , also that PROVIDES approach was considered but found lacking.

(If I remember right, that was originally tested already in late 2019.)

[tohojo]

sqm-scripts PR above - kmod-sched-cake patch here: https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/

[tohojo]

(I've compile tested the combination on ath79 - if someone has any idea for how to test this on the image builder short of just merging both patches, please go ahead!)

[hnyman]

It would need ramips SDK for compiling the SQM package (with kernel 4.14) and then mt7621 SDK for compiling the kernel packages (5.4) and finally imagebuilder to cook up the mt7621 image with those packages.

In practice, merge first and hope for the best when buildbot crunches it ;-)

Note that the main OpenWrt repo patch should be merged first, maybe 1-2 days ahead of the SQM patch, so that the kernel packages from the images phase1 buildbot are ready when the phase2 packages buildbot next time tries to build SQM. Otherwise SQM might be unavailable for 2-3 days (due to missing cake-virtual), as the packages buildbot has a pretty slow rotation.

[tohojo]

On 6 May 2020 23:25:17 CEST, Hannu Nyman [e-mail] wrote:

It would need ramips SDK for compiling the SQM package (with kernel
4.14) and then mt7621 SDK for compiling the kernel packages (5.4) and
finally imagebuilder to cook up the mt7621 image with those packages.

In practice, merge first and hope for the best when buildbot crunches
it ;-)

Haha, yeah, that's what I figured :)

Note that the main OpenWrt repo patch should be merged first, maybe 1-2
days ahead of the SQM patch, so that the kernel packages from the
images phase1 buildbot are ready when the phase2 packages buildbot next
time tries to build SQM. Otherwise SQM might be unavailable for 2-3
days (due to missing cake-virtual), as the packages buildbot has a
pretty slow rotation.

Yup, will do - just put the PR up now in case someone wants to take it for a spin. And so that you can just merge it if I forget ;)

[9000000]

Please fix this

[tohojo]

Still waiting for the patch in the patchwork link above. @hnyman or @ldir-EDB0 any of you have commit privs to get that merged?

[hnyman]

Sorry, I do not have merge right there.
But Kevin has.

[sinancetinkaya]

This is frustrating because I can't flash snapshots anymore

[tohojo]

Opened a github PR for the same patch to core; maybe that'll help get it merged. See https://github.com/openwrt/openwrt/pull/3039

[ptpt52]

why not just rebuild sqm-scripts base on the correct kernel so that it depends on correct kmod-sch-cake or kmod-sch-cake-oot

[tohojo]

Chen Minqiang [e-mail] writes:

why not just rebuild sqm-scripts base on the correct kernel so that
it depends on correct kmod-sch-cake or kmod-sch-cake-oot

Short answer: Because that's not how the build bots work :)

Longer answer: The build bots are split into stage-1 and stage-2 builds,
where the former builds all the kernel packages for each specific
target, and the latter builds the package feed but only for each
architecture, not for each individual target. Since sqm-scripts is part
of the packages feed, it gets built as part of stage 2...

[ptpt52]

the build bots is the problem.

I think the build bot is not fine

one architecture could be in different kernel version, this is the point.
for ramips, mt7621 use kernel 5.4 and mt7620 use kernel 4.14 so they need different kmod-sch-cake**

we should change the build bots to do this right.

[tohojo]

Yes, well, that's what openwrt/openwrt#3039 and #12096 are supposed to do :)

[ilker-aktuna]

is there a solution to this now ?
I am using Netgear r6700v2 and it is mt7621 based.
https://openwrt.org/toh/hwdata/netgear/netgear_r6700_2.0

[sinancetinkaya]

The solution is ready. It just has to be merged

On Sun, 7 Jun 2020, 23:01 ilker Aktuna, [e-mail] wrote:

is there a solution to this now ?
I am using Netgear r6700v2 and it is mt7621 based.
https://openwrt.org/toh/hwdata/netgear/netgear_r6700_2.0

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/openwrt/packages/issues/12072#issuecomment-640271763,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAUNHR7YRPT2LMV2GVONVY3RVPW23ANCNFSM4MYLT7NA
.

[hnyman]

It has been merged yesterday, both the core OpenWrt part and the SQM dependency part.

(but the builtbot has not yet built all targets, so it may take a few hours/days before the package for your specific architecture is available)

[adschm]

I will probably drop kernel 4.14 support from master this week. This will also removed the oot cake, and leave the sched-cake-virtual package just pointing kmod-sched-cake. Therefore, I'd like to remove it as well; is there a nice way to do this without breaking sqm-scripts in certain update szenarios?

[hnyman]

sched-cake-virtual was invented just as a way to overcome the non-mainlined cake on kernel 4.14 problem. And the problem only surfaced when the package architecture was using an SDK with different kernel version than the firmware image and kernel kmods (like ramips vs. mt7621)

In future the cake kmod will always be available, as everything is 4.19+
So even if there is a difference in the package arch SDK and firmware kernel versions, the cake kmod would be picked from the target image/kernel repo, quite normally.

As far as I see, cake-oot and sched-cake-virtual can be safely dropped if sqm-scripts itself is reverted to again use the normal kmod-sched-cake instead of kmod-sched-cake-virtual