Can't access home assistant after updating from 103.5 to 103.6

Hi

I tried to update home assistant from 103.5 to 103.6 today through hassio as I normally do. I am running on ubuntu 18.04 latest patch.

I can now no longer access home assistant, but I can ssh and some of my other containers are running. I’ve seen a few people mention stuff about the google backup addon so I’ve tried killing that. I’ve also read about the ip addresses in the containers, so I’ve tried stopping all containers, removing all containers and rebooting the server.

I notice in the images I have both home assistant 103.5 and 103.6. I also have hassio supervisor 193 and latest (the same image I think).

The containers that are being run are:
homeassistant/qemux86-64-homeassistant:0.103.5 and homeassistant/amd64-hassio-supervisor

Looking at the logs for both I’ve seen nothing alarming. I’ve also looked at the ifconfig by exec in to each and checking against the hassio dns hosts:

Supervisor

eth1 Link encap:Ethernet HWaddr 02:42:AC:1E:20:02
inet addr:172.30.32.2 Bcast:172.30.33.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6191 errors:0 dropped:0 overruns:0 frame:0
TX packets:707 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:511682 (499.6 KiB) TX bytes:133882 (130.7 KiB)

Homeassistant

hassio Link encap:Ethernet HWaddr 02:42:BD:B0:26:77
inet addr:172.30.32.1 Bcast:172.30.33.255 Mask:255.255.254.0
inet6 addr: fe80::42:bdff:feb0:2677/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41132 errors:0 dropped:0 overruns:0 frame:0
TX packets:50605 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5498167 (5.2 MiB) TX bytes:68291911 (65.1 MiB)

Hassio DNS

eth0 Link encap:Ethernet HWaddr 02:42:AC:1E:20:03
inet addr:172.30.32.3 Bcast:172.30.33.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7277 errors:0 dropped:0 overruns:0 frame:0
TX packets:1884 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:620752 (606.2 KiB) TX bytes:207709 (202.8 KiB)

And finally the dns hosts file:

127.0.0.1 localhost localhost.local.hass.io
172.30.32.2 hassio hassio.local.hass.io supervisor supervisor.local.hass.io
172.30.32.1 homeassistant homeassistant.local.hass.io home-assistant home-assistant.local.hass.io
172.30.32.3 dns dns.local.hass.io
172.30.33.0 core-mosquitto core-mosquitto.local.hass.io
172.30.33.1 a0d7b954-sonweb a0d7b954-sonweb.local.hass.io
172.30.32.1 core-samba core-samba.local.hass.io
172.30.32.1 a0d7b954-adguard a0d7b954-adguard.local.hass.io
172.30.32.1 a0d7b954-glances a0d7b954-glances.local.hass.io
172.30.32.1 a0d7b954-ssh a0d7b954-ssh.local.hass.io
172.30.33.2 a0d7b954-plex a0d7b954-plex.local.hass.io
172.30.33.5 a0d7b954-vscode a0d7b954-vscode.local.hass.io
172.30.33.3 a0d7b954-portainer a0d7b954-portainer.local.hass.io
172.30.33.4 ad758411-squeezebox-server ad758411-squeezebox-server.local.hass.io
172.30.32.1 a0d7b954-motioneye a0d7b954-motioneye.local.hass.io
172.30.32.1 15ef4d2f-esphome 15ef4d2f-esphome.local.hass.io
172.30.33.7 a0d7b954-nginxproxymanager a0d7b954-nginxproxymanager.local.hass.io
172.30.33.8 core-configurator core-configurator.local.hass.io
172.30.33.6 cebe7a76-hassio-google-drive-backup cebe7a76-hassio-google-drive-backup.local.hass.io

My supervisor logs after killing containers and restarting are:

20-01-08 22:56:08 INFO (MainThread) [hassio.snapshots] Found 4 snapshot files
20-01-08 22:56:08 INFO (MainThread) [hassio.discovery] Load 2 messages
20-01-08 22:56:08 INFO (MainThread) [hassio.ingress] Load 3 ingress session
20-01-08 22:56:08 INFO (MainThread) [hassio.secrets] Load Home Assistant secrets: 22
20-01-08 22:56:08 INFO (MainThread) [main] Run Hass.io
20-01-08 22:56:08 INFO (MainThread) [hassio.api] Start API on 172.30.32.2
20-01-08 22:56:08 INFO (MainThread) [hassio.addons] Phase ‘initialize’ start 0 add-ons
20-01-08 22:56:08 INFO (MainThread) [hassio.core] Hass.io reboot detected
20-01-08 22:56:08 INFO (MainThread) [hassio.tasks] All core tasks are scheduled
20-01-08 22:56:08 INFO (MainThread) [hassio.core] Hass.io is up and running
20-01-08 22:56:23 WARNING (MainThread) [hassio.tasks] Watchdog found a problem with Home Assistant Docker!
20-01-08 22:56:23 INFO (SyncWorker_5) [hassio.docker.interface] Start homeassistant/qemux86-64-homeassistant

Docker containers
https://hastebin.com/iqegitobac.nginx

Well I had a similar issue.
I was on the beta channel.
Last night system unresponsive.
rebooted
Woke up this morning and still the same, cpu % going crazy.
Checked docker ps
Only listed hassio_supervisor and hassio_dns
Paused the both and cpu % 0
Loaded portainer
Attempts to start the same issue
Found dns spiking cpu
Supervisor in a restart loop
Tried to start things some did others didnt
no samba, not much of anything
Checked images
Saw supervisor had two
194 and latest. I’m sure I was only a on 193
so it trying to upgrade itself and failing.
Remove the latest.
Restarted supervisor
and hooray
Slowly it fixed itself, updated and update home assistant to 104.b0 supervisor back to 193. I think.
will have to check.
Turned off beta channel.
Now my hassio is wanting to upgrade to 103.6 from 104.b0
well at least it all working
For now

I have the same issure running hassio in docker on debian.

How can I degrade to previous version? only aviable command for me trough ssh now is “homeassistant-supervisor”??

Same issue on docker not hassio when I upgraded to 0.104.0.0b0 dropped back to as far as 0.103.3 same issue.
Hopped back onto the dev channel now at 0.105.0.dev… same issue.

I think the two images for supervisor e.g. 194 and latest are the same image just with two tags, as in 194 is the latest (at least that’s what I do at work anyway). Whether this is a new process or it should only grab the version tag I’m not sure.

So am I correct in saying by deleting the latest supervisor image and restarting supervisor, seemed to get things back up for you? I’m not entirely sure what to do with two images for ha 0.103.5 and 0.103.6. I’m wondering if mine grabbed the new image for ha, perhaps the supervisor failed because of the latest tag like you’re saying, then failed and reverted to the 0.103.5 ha image.

I’m not going to be able to try anything till later tonight for me now, but I’ll post back if removing that latest image helps. As far as I could tell my supervisor was on 193 not 194 and I was on normal release channel.

For a total noob, how to remove the latset image from docker?

Get a list of your images:

docker images

Then remove the image:

docker image rm homeassistant/amd64-hassio-supervisor:latest

(Change your image name accordingly)

1 Like

if you on linux
install portainer its saved me
you can see whats happening, what is running, cpu, memory you can see the logs, containers, images
if i tried to do this from the cli i would have been lost as to what was happening

Removed latest image, now the one I have left is with tag 194, rebooted but can’t get in still. Webui starts when I use “docker start homeassistant” but hassio menu won’t load or deconz, z-wave loads fine…

dmesg:

[ 3464.892424] hassio: port 3(veth38b2ef3) entered forwarding state
[ 3464.896851] IPv6: ADDRCONF(NETDEV_UP): veth711baa6: link is not ready
[ 3464.897171] IPv6: ADDRCONF(NETDEV_CHANGE): veth38b2ef3: link becomes ready
[ 3465.118981] docker0: port 1(veth8344869) entered disabled state
[ 3465.119385] eth0: renamed from veth3d7ded7
[ 3465.146828] docker0: port 1(veth8344869) entered blocking state
[ 3465.146833] docker0: port 1(veth8344869) entered forwarding state
[ 3465.271202] hassio: port 3(veth38b2ef3) entered disabled state
[ 3465.271462] eth1: renamed from veth711baa6
[ 3465.291011] hassio: port 3(veth38b2ef3) entered blocking state
[ 3465.291016] hassio: port 3(veth38b2ef3) entered forwarding state
[ 3465.376742] udevd[6]: starting version 3.2.8
[ 3465.379238] udevd[7]: starting eudev-3.2.8
[ 3466.635458] audit: type=1400 audit(1578589107.460:33): apparmor=“STATUS” operation=“profile_replace” info=“same as current profile, skipping” profile=“unconfined” name=“hassio-supervisor” pid=25133 comm=“apparmor_parser”
[ 3466.635463] audit: type=1400 audit(1578589107.460:34): apparmor=“STATUS” operation=“profile_replace” info=“same as current profile, skipping” profile=“unconfined” name=“hassio-supervisor///usr/bin/gdbus” pid=25133 comm=“apparmor_parser”
[ 3466.635466] audit: type=1400 audit(1578589107.460:35): apparmor=“STATUS” operation=“profile_replace” info=“same as current profile, skipping” profile=“unconfined” name=“hassio-supervisor///usr/bin/git” pid=25133 comm=“apparmor_parser”
[ 3466.635469] audit: type=1400 audit(1578589107.460:36): apparmor=“STATUS” operation=“profile_replace” info=“same as current profile, skipping” profile=“unconfined” name=“hassio-supervisor///usr/bin/socat” pid=25133 comm=“apparmor_parser”
[ 3466.824913] hassio: port 2(veth560d3d2) entered disabled state

I’m back on looking at this now, something seems to have cause a problem in this last release… seeing a fair few people with similar issues in discord and elsewhere too. I’ll report back shortly…

When I try to open the Hass.io menu i get the following message:

Unable to load the panel source: /api/hassio/app/entrypoint.js.
Everything worked fine untill I rebooted.

If you can guid me I’m glad to show outputs of the logfiles if needed.

Thank you all for the help!

I have it installed, via the addons.
Problem is that it won’t load even…

I’ve seen this before, can’t remember exactly what it is but will have google around. Are you accessing by local-ip:8123?

I have it via lets encrypt, so connecting via domain.

Edit:
Just removed the certificate in the config file and tried interal ip, same error.

No add-on won’t help.
If your on Linux-docker-hassio
Install portainer on the linux host

So I had a play last night, stopped and removed all the docker containers and then rebooted the host. This resulted in no docker containers coming back up.

I then tried following frenks install instructions

sudu su
curl -sL https://raw.githubusercontent.com/home-assistant/hassio-installer/master/hassio_install.sh | bash -s

To no avail sadly.

Back to the drawing board… I did have a go at recreating the service under systemctl but no joy there either.

Install portainer
Issue is usually due to and image update thats not succeeding.

I’ve got portainer, but I currently can’t get the supervisor to run at startup. Going to go through my systemctl config this evening.

Check images

How many images are on the supervisor ?

Solved my issuie, I had two containers, one with tag “latest” & one with “194”

I pulled down the latest and removed the “194”, now it works… But in docker I have 2 containers again??

Version “latest” and “193” ??

I don’t get it…