fix(images): refresh the opkg index in the layer that installs - #10
Merged
Conversation
`opkg update` ran in an earlier RUN than the install of the staged extra_packages files. Buildkit keeps that layer for as long as the release and the feed package list hold, while the install layer re-runs on every change to the staged files, so the index could be months older than the install reading it. A pin does not make that safe: OpenWrt rebuilds the packages inside releases/24.10.8/ in place, under the same version string. Measured on 2026-09-04 against an image built 2026-07-29: index in the image bash 5.2.37-r1 Size 473650 SHA256 f1872e60... downloads.openwrt.org bash 5.2.37-r1 Size 473647 SHA256 20eaa220... opkg_install_pkg: Checksum or size mismatch for package bash. Either the opkg or the package index are corrupt. Try 'opkg update'. `owlab test` had the same hole at run time. It refreshed the index only when a feed had been added, but a package installed by path still resolves its DEPENDENCIES out of the index, and a reused image carries whatever index its build left behind. The apk line needs neither change, measured: apk-tools 3.0.5 revalidates a cached index older than --cache-max-age (4 hours by default) on its own, and re-downloaded every APKINDEX before resolving anything in a month-old image. opkg has no such policy. Nothing that cached before stops caching. An unchanged `owlab up` is still 28 cached steps in 1.6 s; changing only the staged package leaves the feed-install layer CACHED and costs about 1.6 s and a megabyte of gzipped indexes in the layer that was re-running anyway.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
opkg updateran in an earlierRUNthan the install of the stagedextra_packagesfiles. Buildkit keeps that layer for as long as the release and thefeed package list hold, while the install layer re-runs on every change to the staged
files. The two are routinely months apart.
A pinned point release does not make that safe. OpenWrt rebuilds the packages inside
releases/24.10.8/in place, without bumping a version, so an index from an olderbuild names bytes the server no longer serves:
opkg install bashin that image reproduces the message verbatim. It bites at thestaged-package step rather than the feed step because a local package is installed by
path, but its dependencies still come out of the index.
Excluded by measurement: the pin has not expired (
owlab releasesreports all eightrouters up to date), the feed has not moved (
distfeeds.confpoints at 24.10.8, HTTP200), and it is not about
bash— the whole index was rebuilt on 2026-09-03.What changes
opkg updatenow runs in the layer that installs, inside theif, so a build with noout-of-feed package still fetches nothing.
owlab testsetsUpdate: trueunconditionally for the same reason: a router boots with whatever index its cached
image layer left behind.
The apk line needs nothing, also measured
apk-tools 3.0.5 revalidates a cached index older than
--cache-max-age(four hours bydefault) on its own: an
apk addinside a month-old image re-downloaded every APKINDEX(744322 -> 733065 bytes) before resolving, and a second one seconds later did not. opkg
has no such policy — it reads whatever the last
opkg updateleft and never asks.Cost
Nothing stops caching. A repeat
owlab upwith no changes is 28 CACHED, 1.6 s, zerodownloads. Changing only an extra package leaves layer 2/12 CACHED and takes 4/12 from
3.8 s to 4.6 s — about 1.6 s and 1 MB of gzipped indexes per opkg router. The apk layer
is untouched.
Verified
Both release lines build; LuCI answers 200 on all routers and the theme is in place.
owlab testpasses 2 of 2 on 24.10.8 and 25.12.4.dash -nclean on every script andon the changed RUN body;
gofmt/go vetclean;go test ./...clean apart from thepre-existing
TestMissingQEMUSaysWhereItLookedAndWhatToRun, which fails on any machinewith qemu installed.
Troubleshooting entries added in both languages.