Summary
Two consecutive build attempts for an ASUS 4G-AX56 on releases/25.12.3 fail with wget: exited with error 8 and unexpected end of file for uclient-fetch and luci-ssl. The exact files the worker says it cannot fetch are returning HTTP 200 from downloads.openwrt.org at the same time, so this looks like a build-worker side issue rather than a real missing package.
Reproduction
- Device firmware before upgrade:
OpenWrt 25.12.2 r32802-f505120278, target ramips/mt7621, profile asus_4g-ax56, arch mipsel_24kc
- Submitted via on-device
luci-app-attendedsysupgrade (client: luci/26.118.65222~15aabe7)
- ASU rolled the request forward to
25.12.3 (expected behaviour)
request_hash: 6606d0a9f34059081de18f0868df54266a2f65a50f92e8ba60ce1a4ee066388e
API response (truncated):
{
"detail": "Error: Impossible package selection",
"imagebuilder_status": "failed",
"request": {
"distro": "openwrt",
"version": "25.12.3",
"target": "ramips/mt7621",
"profile": "asus_4g-ax56",
...
}
}
Build worker stderr (relevant lines)
WARNING: opening /builder/packages/packages.adb: No such file or directory
Package list missing or not up-to-date, generating it.
Building package index...
ERROR: wget: exited with error 8
ERROR: uclient-fetch-2026.02.20~7a0aa2e4-r1: unexpected end of file
ERROR: wget: exited with error 8
ERROR: luci-ssl-26.129.70992~61fbfe6: unexpected end of file
make[2]: *** [Makefile:254: package_install] Error 2
make[1]: *** [Makefile:193: _call_manifest] Error 2
make: *** [Makefile:369: manifest] Error 2
Files the worker reports as failing
Both return HTTP 200 from the public CDN right now:
$ curl -sI -o /dev/null -w "%{http_code} %{url_effective}\n" \
"https://downloads.openwrt.org/releases/25.12.3/packages/mipsel_24kc/luci/luci-ssl-26.129.70992~61fbfe6.apk" \
"https://downloads.openwrt.org/releases/25.12.3/packages/mipsel_24kc/base/uclient-fetch-2026.02.20~7a0aa2e4-r1.apk"
200 https://downloads.openwrt.org/releases/25.12.3/packages/mipsel_24kc/luci/luci-ssl-26.129.70992~61fbfe6.apk
200 https://downloads.openwrt.org/releases/25.12.3/packages/mipsel_24kc/base/uclient-fetch-2026.02.20~7a0aa2e4-r1.apk
The corresponding packages.adb index files for both feeds also return 200.
Notes
- Reproduced twice from the on-device LuCI app with the same
request_hash. ASU appears to cache the failure, so retries against the same hash do not get re-queued onto a different worker.
wget: error 8 from BusyBox wget means the server returned an HTTP error status. Given the files are reachable from outside, the most likely causes are a stale internal mirror cache used by the worker, an egress proxy returning 5xx, or a partial CDN replication where the worker's resolver happens to hit a node that was still empty at build time.
- The stock
openwrt-25.12.3-ramips-mt7621-asus_4g-ax56-squashfs-sysupgrade.bin image is also present on the CDN with a valid sha256sums entry. Flashing that image directly succeeded and brought the device to 25.12.3 r32912-6639b15f62 cleanly, so this is purely an ASU build-pipeline issue and not a packaging or release issue.
Suggested investigation
- Check whether the build worker uses an internal mirror or proxy and whether that endpoint has the failing files.
- Consider not caching
imagebuilder_status: failed results that have only wget: error 8 in stderr, since this is a strong indicator of a transient infrastructure problem rather than a real impossible package selection. Re-queueing onto a different worker would likely succeed.
- The
Impossible package selection final error message is misleading for this failure mode. The actual cause (HTTP fetch error during index build) gets surfaced only by reading the worker stderr. A more specific error class for "manifest/fetch failure" would help users distinguish this from genuine package-set conflicts.
Workaround
Flash the stock sysupgrade image directly from downloads.openwrt.org/releases/<version>/targets/... when ASU keeps caching a failed build for the same package set.
Summary
Two consecutive build attempts for an ASUS 4G-AX56 on
releases/25.12.3fail withwget: exited with error 8andunexpected end of fileforuclient-fetchandluci-ssl. The exact files the worker says it cannot fetch are returning HTTP 200 fromdownloads.openwrt.orgat the same time, so this looks like a build-worker side issue rather than a real missing package.Reproduction
OpenWrt 25.12.2 r32802-f505120278, targetramips/mt7621, profileasus_4g-ax56, archmipsel_24kcluci-app-attendedsysupgrade(client: luci/26.118.65222~15aabe7)25.12.3(expected behaviour)request_hash:6606d0a9f34059081de18f0868df54266a2f65a50f92e8ba60ce1a4ee066388eAPI response (truncated):
Build worker stderr (relevant lines)
Files the worker reports as failing
Both return HTTP 200 from the public CDN right now:
The corresponding
packages.adbindex files for both feeds also return 200.Notes
request_hash. ASU appears to cache the failure, so retries against the same hash do not get re-queued onto a different worker.wget: error 8from BusyBoxwgetmeans the server returned an HTTP error status. Given the files are reachable from outside, the most likely causes are a stale internal mirror cache used by the worker, an egress proxy returning 5xx, or a partial CDN replication where the worker's resolver happens to hit a node that was still empty at build time.openwrt-25.12.3-ramips-mt7621-asus_4g-ax56-squashfs-sysupgrade.binimage is also present on the CDN with a validsha256sumsentry. Flashing that image directly succeeded and brought the device to25.12.3 r32912-6639b15f62cleanly, so this is purely an ASU build-pipeline issue and not a packaging or release issue.Suggested investigation
imagebuilder_status: failedresults that have onlywget: error 8in stderr, since this is a strong indicator of a transient infrastructure problem rather than a real impossible package selection. Re-queueing onto a different worker would likely succeed.Impossible package selectionfinal error message is misleading for this failure mode. The actual cause (HTTP fetch error during index build) gets surfaced only by reading the worker stderr. A more specific error class for "manifest/fetch failure" would help users distinguish this from genuine package-set conflicts.Workaround
Flash the stock sysupgrade image directly from
downloads.openwrt.org/releases/<version>/targets/...when ASU keeps caching a failed build for the same package set.