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.
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
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.
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?
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 …
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?
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.
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.
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.
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.
My question too. I don’t mind uninstalling portainer if it is posing a risk to developers, but give us tools/education in supervisor to run containers not in the ha add on library
Running containers which aren’t addons alongside supervisor is not supported. That’s one of the problems with portainer, it makes it easy to do exactly that. Why would the HA team provide guidance on how to do something which is explicitly not supported?
Users have made lots of open source software into addons. There’s many more then just what’s in the community and official add-on repositories. Search the forum here for the piece of software you’re interested, you may find someone has already made it into an add-on.
If not then there’s doc here on how to make an addon. So if you have an existing image you could probably make it into an addon.
If that still doesn’t work for you then I would suggest switching to a container install. That is only option supported where HA is running alongside containers which aren’t managed by supervisor in a docker setup. Or follow this guide to put HAOS in its own a VM and put the rest of the docker containers in another docker deployment.
