Just thought I’d add to this discussion. I had Watchtower installed at one point in my docker environment, but I had sense removed it because of the unhealthy system notification. However, even after removing the Watchtower container, I was still seeing the unhealthy system message. It seems that even if the Watchtower image has been pulled, but not in use in a container; HA will complain about an unhealthy system.
Removing the Watchtowers image from docker fixed it all. As well as updating my Ubuntu 20.04 install.
I’m on 19.10 and I had the hope I could wait until I had time to migrate my system to ProxMox for a supported installation. Oh well, fingers crossed. Going to 20.04… shit.
Thanks @dtalens. Ran into the same issue when trying to update to 2020.12.1 and restarting hassio-supervisor worked for me. I didn’t have to restart hassio-apparmor.
Hi All, I had the same issue - followed the instructions here and can now update
In-case people are unsure what steps to follow, mine was as simple as (this is all above but put the entire issue and resolution in a single post to make it easier for anyone new) - i’m running HassOS on Ubuntu:
Error Received (for both updating the core and an update to the latest version
WARNING (MainThread) [supervisor.jobs] 'AddonManager.update' blocked from execution, system is not healthy
WARNING (MainThread) [supervisor.jobs] 'HomeAssistantCore.update' blocked from execution, system is not healthy
I SSH’d into my server and executed three simple commands
Waited for it to restart and now i can succesfully update
INFO (MainThread) [supervisor.homeassistant.core] Updating Home Assistant to version 2021.1.4
INFO (SyncWorker_5) [supervisor.docker.interface] Updating image homeassistant/qemux86-64-homeassistant:2021.1.1 to homeassistant/qemux86-64-homeassistant:2021.1.4
INFO (SyncWorker_5) [supervisor.docker.interface] Downloading docker image homeassistant/qemux86-64-homeassistant with tag 2021.1.4
Note: This is a work around and is required each time you want to upgrade if your system isn’t completely up to dateThanks for clarifying this point @badabing
I had just installed Ouroboros, a python version of Watchtower, making updating my many containers running on my server very easy! Plus with a notification sent to my phone daily with the list of updated container.
But of course my HA supervisor didn’t like it, even though all HA related container were in the exclusion list in Ouroboros. As you said, after deleting the container and it’s image, HA was healthy and supported again.
Did you find any workaround? Auto-updating is super handy for sure…
I am thinking of a script, to:
Create the container - Image will be auto-downloaded if not there (Ouroboros has a “run once option”)
@mitch
That will only get you working temporarily,
Soon after you’d notice that it is back to being problematic.
@dtalens
Thank you, that approach is much easier and quicker then a full update / reboot
What I don’t get is that I had docker in Ubuntu method working for very long time and very steadily, and all of a sudden with some Supervisor upgrade this problem started happening, and on every Home Assistant Update or on every Add-on update I have to do this dance to get it working.
I get it, it is not officially supported, but as seen in this thread and many others, lots of people are using this setup.
Why intentionally break it?
If a reboot fixes it, or if a supervisor restart fixes it, it is obvious that at some point after the restart, supervisor is running some script process to check things out and declaring it to be unsupported, effectively blocking updates.
Seeing that people have no choice but to restart the system or supervisor to proceed, and are doing so, why not add a configuration option to allow ignoring this unsupported flag and proceed regardless? Put a big warning if you want to discourage people, but forcing people to find workarounds and loopholes is not the best deterrent.
I have one system, which is an Ubuntu system, it is powerful and runs many other services aside from Dockerized Home Assistant, asking us to switch to Debian where this setup has been working for a very long time is unrealistic.
I’m not asking for it to be officially supported, what I’m asking is for it not to be intentionally handicapped.
GNU Debian and latest version of Docker installed two weeks ago after my Raspian install would no longer run Supervisor reliably. Supervisor would stop after 5 mins to 1 day with no error.
Today I see supervisor has no access to the internet and getting similar messages in log. Reboot, update and upgrade reboot, remove WG and DuckDNS reboot, add loopback to etc/host reboot all failed. Tried restarting Docker container for Supervisor and have a clean log file. However, after a reboot i get
19-02-14 10:12:53 WARNING (MainThread) [supervisor.updater] Can't fetch versions from https://version.home-assistant.io/stable.json: Cannot connect to host version.home-assistant.io:443 ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate is not yet valid (_ssl.c:1125)')]
19-02-14 10:12:53 WARNING (MainThread) [supervisor.jobs] 'Updater.fetch_data' blocked from execution, no supervisor internet connection
19-02-14 10:12:53 INFO (MainThread) [supervisor.homeassistant.secrets] Loaded 6 Home Assistant secrets
19-02-14 10:12:53 INFO (SyncWorker_1) [supervisor.docker.interface] Attaching to homeassistant/raspberrypi4-homeassistant with version 2021.3.4
19-02-14 10:12:53 INFO (MainThread) [supervisor.hassos] No Home Assistant Operating System found
19-02-14 10:12:54 WARNING (MainThread) [supervisor.jobs] 'StoreManager.update_repositories' blocked from execution, no supervisor internet connection