efahl

> luci-app-attendedsysupgrade There's your culprit in this case. Everything else (`auc`, `owut`, firmware selector) specifies the `version_code` in the build blob, which the ASU builder verifies request and imagebuilder as...

Right now (2024-06-15 18:40Z) the ASU server is ahead of the downloads site: ``` snapshots x86/64 generic r26634-7d9b9762c9 ASU Server r26633-22f92cce22 Build Server ``` But the ASU builder is still...

> The GitHub token ran out over the weekend causing the webhook to never run any container updates. GAH! That explains a lot.

I'm still seeing the same issue. Ran two builds on different x86 machines, about a half hour apart. ``` Received incorrect version r26657-531b3f667c (requested r26670-5f9fb964c3) ``` ASU and downloads profiles...

Ok, just tried again with the old 'add "#" to uci-defaults' trick for force a new hash, and it worked (i.e., got a valid image and installed it), so the...

> requested 26674, not 26620 What upgrade client did you use that gave this? This typically happens when the sysupgrade metadata lags behind the build, which is the issue that...

> according luci-app-attendedsysupgrade (git-23.339.51123-138595a) That would be as expected, as that version doesn't contain the `version_code` fix, so works most of the time. If no `version_code` is supplied, then neither...

It's not so much luck, but rather LuCI ASU did the right thing like 99% of the time. It all depends on the state of the ASU server's cached builds,...

> specifying `version_code` to an older revision doesn't work on snapshots Older snapshots isn't a use case for any upgrade tool. The only way to get a non-current snapshot is...

@aparcar I've been tracking the server updates for about two months now, and currently the most prevalent one is that it looks like the CDN is not flushing caches. Here...