openwrt / openwrt/asu

wget error 8 on packages that exist on CDN (25.12.2 -> 25.12.3, ramips/mt7621/asus_4g-ax56)

Open
#1,637 1 comment 4 reactions 0 assignees View on GitHub

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, 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

  1. Check whether the build worker uses an internal mirror or proxy and whether that endpoint has the failing files.
  2. 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.
  3. 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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.