wget error 8 on packages that exist on CDN (25.12.2 -> 25.12.3, ramips/mt7621/asus_4g-ax56)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 450
- Forks
- 111
- PR merge metrics
- No merged PRs in 30d
Description
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, targetramips/mt7621, profileasus_4g-ax56, archmipsel_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 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.- The stock
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
- Check whether the build worker uses an internal mirror or proxy and whether that endpoint has the failing files.
- Consider not caching
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. - The
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the build worker's package-index generation and package_install failure shown at Makefile:254, then inspect how the worker reaches the package files and how ASU caches failures for the request_hash. Compare the worker's mirror or proxy responses with the public CDN. Done means transient fetch failures are distinguishable from package-selection errors and can be retried or re-queued appropriately.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, build-system, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100