I am trying to run an update, which I neglected for some time. I am now on core 2022.9.6 trying to move to 2022.11.1. I am getting no internet error in logs:
homeassistant.exceptions.HomeAssistantError: Error updating Home Assistant Core 'HomeAssistantCore.update' blocked from execution, no host internet connection
I googled a lot, but nothing works, seems that supervisor is getting false connection status - is there a way to force it to ignore connectivity status?
Server is connected, all is up an running, I am just stuck with the update.
I see unsupported status, which is driven by systemd-journal, but I gave up trying to solve it. Perhaps this is connected?
Systemd error below:
ERROR (MainThread) [supervisor.host.logs] No systemd-journal-gatewayd Unix socket available
Managed to solve this it seems. nmcli g status showed “portal” under CONNECTIVITY column. I am not using wifi for connection, but still, it seems it affected the connectivity check. I have commented out all lines in file /etc/NetworkManager/conf.d/20-connectivity.conf and rebooted the machine. After rebooting, I could see “full” under CONNECTIVITY in nmcli g status output and all updates went fine.
I did an update on HA was getting a the same no internet connection. I run a supervised install. Checking “nmcli g status” showed “limited” connectivity even though there were no network issues. On my system I had set a static IP address using /etc/network/interfaces. I believe this was why NetworkManager reported “limited” connectivity. So I reconfigured networking so NetworkManager would assigned the static address. This then change the reported connectivity to “full”. At which point the error in HA went away. So thanks for the hint. The steps I took are documented here.
Ping for any external resource, if OK, then go to next step
type in terminal nmcli g status. On this step i got STATE: disconnected, but in fact the internet connection was OK.
Nmcli is NetworkManager tool. I,m using netplan on my machine, so I checked my netplan config (/etc/netplan/***.yaml) and added string renderer: NetworkManager
Next type sudo netplan apply and recheck status with nmcli g status, now got the status connected, so this what worked for me.
Evening,
I am new to docker but not new to linux. I followed the instructions here official instructions but when I got to the point of installing home assistant (dpkg -i homeassistant-supervised.deb) it would just loop with 100% packet loss.
state connectivity wifi-hw wifi wwan-hw wwan
connected full enabled enabled enabled enabled
when I run “docker network ls” I get
network id name driver scope
<id> bridge bridge local
<id> host host local
<id> none null local
There are no containers in docker. Debian is a fresh install and I followed the steps. Does anyone know how to fix this?
*I have ha installed on an old raspberry pi 3, I am setting this up on debian for a friend. Compared to the complications around this supervised setup and following the official instructions exactly and still can’t get it working, I would happily change to a non-supervised version of ha if someone can point me to where instructions are for doing that
After the docker install command was complete, I ran ifconfig to get my ip address for the host. On the same wifi, went to the home assistant port with that ip address and had access.
After a lot more knowledge tranfer from google fu, I was able to determine root cause of supervised installation not working. For some reason the ethernet port on the board I installed debian on wasn’t working (orange pi 3 lts…apparently a known issue). When connected to wifi, during the home assistant install step the network cuts out and then back on, which caused the loop issue because the setup process for some reason wouldn’t recognize the reestablished connection.
So, fixing the ethernet port issue and not attempting to run the supervised setup over wifi. The install step I found above is just for the container install. So no addon store. Which means getting zwave to work is a pita, but I did find a good walk thru here
I hope all of this helps the next person. I spent almost a week trying to hunt all of this down
I’m sad to confirm that it’s indeed likely a DNS issue. I was using pi-hole but the container failed to restart so everything here fell apart because I didn’t add a redundant DNS server option.
It makes helping very difficult. 
