Skip to content

fix(images): refresh the opkg index in the layer that installs - #10

Merged
VizzleTF merged 1 commit into
mainfrom
fix/stale-opkg-index
Sep 4, 2026
Merged

fix(images): refresh the opkg index in the layer that installs#10
VizzleTF merged 1 commit into
mainfrom
fix/stale-opkg-index

Conversation

@VizzleTF

@VizzleTF VizzleTF commented Sep 4, 2026

Copy link
Copy Markdown
Member
opkg_install_pkg: Checksum or size mismatch for package bash
target owrt2410: failed to solve: … opkg install --force-overwrite … exit code: 255
owlab: build failed: exit status 1

Why

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. 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 older
build names bytes the server no longer serves:

docker run --rm --entrypoint /bin/cat <image built 2026-07-29> \
  /var/opkg-lists/openwrt_packages | gunzip
    ->  bash 5.2.37-r1  Size 473650  SHA256 f1872e60...

curl -s .../24.10.8/packages/aarch64_generic/packages/Packages.gz | gunzip
    ->  bash 5.2.37-r1  Size 473647  SHA256 20eaa220...   (Last-Modified: 03 Sep 2026)

opkg install bash in that image reproduces the message verbatim. It bites at the
staged-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 releases reports all eight
routers up to date), the feed has not moved (distfeeds.conf points at 24.10.8, HTTP
200), and it is not about bash — the whole index was rebuilt on 2026-09-03.

What changes

opkg update now runs in the layer that installs, inside the if, so a build with no
out-of-feed package still fetches nothing. owlab test sets Update: true
unconditionally 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 by
default) on its own: an apk add inside 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 update left and never asks.

Cost

Nothing stops caching. A repeat owlab up with no changes is 28 CACHED, 1.6 s, zero
downloads. 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 test passes 2 of 2 on 24.10.8 and 25.12.4. dash -n clean on every script and
on the changed RUN body; gofmt/go vet clean; go test ./... clean apart from the
pre-existing TestMissingQEMUSaysWhereItLookedAndWhatToRun, which fails on any machine
with qemu installed.

Troubleshooting entries added in both languages.

`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.
@VizzleTF
VizzleTF merged commit 9f72573 into main Sep 4, 2026
14 checks passed
@VizzleTF
VizzleTF deleted the fix/stale-opkg-index branch September 4, 2026 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant