Unhealthy System reported on Arch Linux

So this appeared a while ago, but everything still worked.

20-12-02 23:12:23 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.SETUP
20-12-02 23:12:24 WARNING (MainThread) [supervisor.resolution.evaluations.base] Detected unsupported OS: Arch Linux (more-info: https://www.home-assistant.io/more-info/unsupported/os)
20-12-02 23:12:24 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
20-12-02 23:12:24 INFO (MainThread) [__main__] Running Supervisor
20-12-02 23:12:24 WARNING (MainThread) [supervisor.core] System running in a unsupported environment!
20-12-02 23:12:24 CRITICAL (MainThread) [supervisor.core] System running in a unhealthy state and need manual intervention!

Then tonight, to fix an issue, I tried moving to the dev branch of zigbee2mqtt. I was not able to install the new addon due to a block. The error message was vague, but the above logs are the only thing I could find that could be related and led me to various other related and recent complaints online.

I’m running, and have been for some time, Arch linux as the host OS, with HASS supervisor on docker.
The error gives a link to a list of possible issues, such as out of date docker (i’m running docker 1:19.03.14-1), non HASS docker containers (I’m not running any and never have), or running LXC, which I am not.

I’ve been seeing other folks having this issue where their systems were broken by a health check while running in a NAS environment. I am running in a very bare-bones arch install that I keep up to date, and has not given me grief in the year it’s been running.

This feels to me like a bug in the recent HASS code that introduces a brake due to failed health checks, but in my case the host is operating just fine. I’m going to try downgrading and see if that fixes it, but wanted to post here, and if anyone else encounters this I will gladly switch back to this broken code to help troubleshoot.

So I found a temporary workaround…

disclaimer: ONLY DO THIS IF YOU KNOW WHAT YOU’RE DOING. MAKE A NOTE THAT YOU DID THIS. DON’T POST PROBLEMS TO FORUMS WITH THIS ACTIVE. ONLY DO THIS IF YOU KNOW THAT YOUR PROBLEM ISN’T GOING TO START LITERAL FIRES IRL. k phew.

Find your Hassio directory. For me it was /usr/share/hassio. It will have a bunch of json files like this:

/usr/share/hassio » ls                                                                                                                   
addons       audio       backup       discovery.json  homeassistant       jobs.json       observer.json  ssl
addons.json  audio.json  cli.json     dns             homeassistant.json  media           services.json  tmp
apparmor     auth.json   config.json  dns.json        ingress.json        multicast.json  share          updater.json

Create the jobs.json file.
In it, put {"ignore_conditions": ["healthy"]}

This isn’t safe, but things are working now. I will have my coffee in the morning when my Hass routine makes it :slight_smile:

I had the same problem, but the ugly solution didn’t work for me. In the Supervisor logs I’m now getting:

20-12-03 02:58:48 CRITICAL (MainThread) [supervisor.jobs] The following job conditions are ignored and will make the system unstable when they occur: {<JobCondition.HEALTHY: 'healthy'>}
20-12-03 02:58:48 WARNING (MainThread) [supervisor.jobs] 'AddonManager.update' blocked from execution, no host internet connection

Technically the first line is actually a warning and not a critical error, and the second line is an error not a warning. The second line occurs when trying to upgrade an addon. Given it prevents the upgrade from working, it is an error.

The only related issue I’ve found is this, which has been closed without resolution.

To me it looks like this version of the Supervisor has completely broken supervised installations on Linux.

1 Like

Exactly. I think the health checks have gotten a bit too harsh, with a harsh punishment. Unfortunately, without the above fix I shared, even downgrading wasn’t an option.

I’ll have you know I did the ugly hack and I don’t know what I’m doing, thank you very much.

So do you have any idea what the actual solution here is? My best guess so far is maybe we’re supposed to start from scratch and just reinstall HA from their new fancy Home Assistant OS thing, and once the base is up and running, reload from a snapshot?

Seems it’s being address upstream…

It was fixed for me by running the install script again on my ubuntu server.
I had to do the same some time ago when udev wasnt running privileged. Seems this issue popped up again for me. But for now the “reinstall” worked fine

Hello. I’m a newbie here …
When installing HA for the first time, I also encounter this error … :frowning:
I would like you to help me, as I don’t know how I find my Home assistant install directory.
I have a virtual machine with Ubuntu Server running, so how do I do the steps mentioned?

Thanks a lot!

I had the same issue with Ubuntu Server. With my installation, the first symptom was the inability to update Visual Studio Code. When I looked through logs, and in addition to a message regarding an “Unhealthy System”, Supervisor was fussing over not having the NetworkManager daemon running. Before I took any action, I took a configuration snapshot and rebooted the host. When boot was complete, it came up clean. The next time something similar happens, I might be motivated to try OS or move to Debian.

2 Likes

Thanks for sharing this. It worked for me too!

2 Likes

I have the same issue, rebooting doesn’t solve issue for me.

I am running Proxmox 5.4 (so Debian 9 based) and HassIO supervised on Debian 9 VM.
Should I upgrade Debian 9 VM to Debian 10?

EDIT: upgraded to Debian 10 Buster following this guide and issue disappeared

not clear to me if it is a recognized bug or not: is it something going to happen hence just need to wait for an update?

Same here with Ubuntu 18.04.4 LTS

it worked for me too!
As always, when something is not working… have you turned it off and on again? :joy:

Rebooting worked for me two days ago. Today it crashed (first time ever for me) and the ‘unhealthy’ indicator is back. Reports ‘Supervisor is not privileged’ and that Network Manager is an unsupported version and must be a minimum of 1.14. However, 1.10 is the latest version for Ubuntu 18.04.5.

I changed nothing so I can’t point a finger at something I upgraded/modified recently.

Interesting tactic to nudge users towards Debian.

1 Like

It’s quite clear to me that the HASS developers/maintainers are not even remotely interested in fixing this issue, nor are they interested in being polite about it.

Luckily, the Arch linux maintainers were quite fast to fix this.
https://bugs.archlinux.org/task/68833

1 Like

One more for rebooting! Let’s see for how long it works.

There are two different flags

  • Unsupported
  • Unhealthy

Unsupported would be set if you’re running on any platform that is not officially supported, and Ubuntu falls into this category.
Usually unsupported flag does not block installation, at worst all you have to do is restart the supervisor container and it proceeds normally.

Debian 11 is officially supported, so I moved from Ubuntu to Debian to be supported, and this worked for a while, and now my system is unsupported again.
That is because I’m running other stuff on my system in addition to running Home Assistant, it looks like the Home Assistant developers want untouched system to declare it supported,
I can understand that, however blocking our ability to update because we’re running docker containers that have nothing to do with Home Assistant is a bit drastic, for the very least give us a flag that allows us to acknowledge that we’re running additional services, it works anyways if we restart supervisor.
It’s wasteful to dedicate a powerful host just for Home Assistant, if one has a good system.

Unhealthy, with my experience this usually is set when the OS has updates, specially if there are docker updates, and the only way to go past this is to update the OS / Docker, and this often requires reboots, however you might get away with supervisor restart.