You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Retry every engine self-download, not just the two in build.func
The previous commit covered build.func and lxc/install.func. The engine
fetches itself from a dozen more places -- api/api.func pulling its four
parts, lib/tools.func pulling its five, the incus and VM entry points, the
UI loader -- and each of those was still a single attempt. Telemetry counts
roughly 240 runs in fourteen days that failed because the engine could not
download its own parts; none of them are the fault of the script being
installed.
The retry options are repeated per file rather than shared. There is nowhere
to put a shared copy that does not itself need downloading first, which is
the problem being solved.
Two things the flags alone got wrong:
curl -S prints a line per failed attempt, so a download that recovered on
the second try now showed the user two errors and then quietly worked, mid
spinner. _cs_curl_retry holds stderr back and releases it only if every
attempt failed, so a recovery is silent and a real failure still explains
itself.
--tries and --waitretry are GNU wget options. The wget fallback exists for
the minimal systems that ship BusyBox wget, where an unrecognised option is
a hard failure rather than a slower download, so those stay single-attempt.
Also, found while auditing the fetch sites:
- The debug-MOTD branch fetched ${CORE_URL}/install.func, a path that does
not exist -- the file is lxc/install.func. motd_ssh was never defined, so
DEV_MODE_MOTD has silently done nothing.
- alpine-install.func sourced lib/alpine.func through a bare
source <(curl ...), which hides the exit code: a failed download sourced
nothing and left every helper below missing with no explanation. It now
goes through _bootstrap_source like the rest of that file's bootstrap.
- get_header had no timeout at all. It stays without retry, since it only
decides whether an ASCII banner appears, but an unbounded connect meant a
black-holed network waited out the OS TCP timeout per candidate.
Verified against a local server that 503s twice then succeeds: three
requests, body returned, nothing on stderr. A 404 still fails on the first
request in under a second with curl's message intact.
0 commit comments