HAOS update failing

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.

Relevant line from the log:

homeassistant.components.hassio.handler.HassioAPIError: Can’t fetch OTA update from https://github.com/home-assistant/operating-system/releases/download/12.4/haos_green-12.4.raucb: Cannot connect to host github.com:443 ssl:default [None]

Any clues would be welcome.

Hi, strange because that link is OK.
What happens if you visit https://github.com/home-assistant/operating-system/releases/

From my laptop, on the same house net, that’s fine

That link falls because of the trailing “:”

It downloads without it.

Should I be doing something different, not just hitting the “Install” link for the update offered on the Settings page?

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?

Hi,
I’m going to suggest either DNS, or some other comms issue where the HAOS device is behaving differently than other devices on your LAN.

I’d install a web shell like the Terminal & SSH Add-on and try some commands…

# 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.

If this helps, :heart: this post!

Hi James

Yes, it often is.

Yeah, thought so.

Good suggestion to tackle this! :+1:

dig and host look good. The traceroute is feasible, if github is a CDN-farm with endpoints in London:

8 lonap01.msn.net (5.57.81.17) 19.089 ms 28.478 ms 21.427 ms
9 ae29-0.icr03.lon22.ntwk.msn.net (104.44.55.206) 18.991 ms ae25-0.icr03.lon24.ntwk.msn.net (104.44.50.168) 19.988 ms *
10 * * *
(no useful info beyond there)

A manual wget works fine.

Hmm! (scratches head).

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.

If it is any consolation, 12.4 has a few intermittent USB issues so you might want to hold back.

As you’re on 12.1, how about trying 12.2 (to avoid 12.3 / 12.4)?

ha os update --version 12.2

(My Yellow is sticking on 12.2 until there’s more data to help fix the USB driver issues, although there are options with kernel options.)

The manual 12.2 update fails the same way.

Can I tell it to update using a wget’d local file?
If not, I guess I just have to keep trying until it magically works :unamused:

Hi,

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…) :man_mage: :grin:

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 :unamused:

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:

Only done “restart” so far :slight_smile: so an actual power-cycle is next.

Nothing at all from those log commands.

Power cycle: no help.

A new supervisor version has just been released so it might be worth an update and try again.