On a “Green”, 12.1 → 12.4
This has persisted for attempts on several days.
An update of the “Core” just ran ok, so it’s not all external comms being down.
Hi other Nick: is that trailing colon only in the error or does this mark a problem with the update system?
I’m about to post a bug report; should I go ahead?
# can HASS resolve an IP address for the site containing the update..
# look for an 'ANSWER section'
dig github.com
# look for 'has address'
host github.com
# look for a hop-by-hop network trace end to end
traceroute github.com
The next step would be to test directly downloading the link URL as a test via wget <URL>.
PS The trailing : colon is very likely log formatting.
My traceroute sees a load of similar UK-based Internet exchange nodes, but assumed that was due to a UK-based ISP peering locally.
A manual wget works fine.
That’s got me stumped - if a shell on the HASS container can connect and xfer fine, then there’s only oddities with headers / Python libraries / out of disk space or a short-term problem that’s gone away.
I’ve seen a few similar reports of OTA updates failing from others but assumed network issues getting to a local CDN node, not something client-side (i.e. Cannot connect to host).
I guess the host HASOS might have a different set of libraries / cut-down network stack from the HASS container itself, but if this persists, some grepping in the source code and a GitHub issue might be worth it.
As you seem to know one end of a command line from another, let’s dig a bit deeper (the best way to learn how stuff works…)
The HAOS GitHub has a few logged issues with debug commands that might be worth a read:
The Supervisor updates HASS and the HAOS image in one of the two OS boot slots. Looking at the Supervisor code confirms where your error message is coming from (complete with trailing :)
This error message is seems to be thrown from a TimeoutError - slow network or DNS resolver timeout? But why is the supervisor different from a manual HASS CLI dig or wget? Dunno.
Based on this dev comment, I wonder if host logs -t rauc or host logs -t OTA might show something more:
If not, I guess I just have to keep trying until it magically works
The simple option would be “turn it off and on again” a few times to see of something DNS/ IP/ moon phase changes (bet you’ve done that…).
Can I tell it to update using a wget’d local file?
Sort-of - the docs reference creating a specialy names CONFIG USB drive with the kernel *.raucb:
I’ve found a GitHub issue reported for this (yes my laptop in the same network also does successfully connect ), but devs responded it’s a network error and they cannot do anything about it. Given that I can access Github from the HA machine, it’s probably not the case though. I posted a comment there, let’s how it unfolds.
I don’t think github failed when I tried – I run wget and update attempt one after another. wget started downloading the file and update attempt failed to connect.