Ty, did some reading, found it too.
thatâs maybe not true
as I used the supervised method it was years back and there was no such restriction
this has changed over the years.
and now Iâm in trouble and need to change my whole set up
4 Likes
Yeah I know it is a bugger. I donât like the restrictions supervised imposes, but I have learned to live with it.
I canât recall dates when various changes were made, but when the major restrictions on supervised were introduced, there was a lot of traffic on this very forum. I find it hard to accept that people currently running supervised are blind to the restrictions.
Why portainer has made a previously unsupported install into an unhealthy one is unknown to me. My understanding is that the boundary between unsupported and unhealthy is interference with the supervisor. Beyond that, I simply donât have the time to trace it all through github history, if you are that exercised about it, Iâll leave that to you (or others).
Nevertheless the commit is here Add portainer as container orchestra (#3889) ¡ home-assistant/supervisor@262fd05 ¡ GitHub
In addition, when someone suggested removing portainer from the list of âunhealthyâ the PR was closed. It is worth quoting the response in full, as a lot of people seem to be enquiring. See Remove Portainer as container orchestra by kfulko ¡ Pull Request #3942 ¡ home-assistant/supervisor ¡ GitHub
Unfortunately, we have seen cases where Portainer possibly interferes. In normal setups, it should also not be needed to run Portainer directly, nor does the general goal of running Portainer fit Home Assistants architectural guidelines/goals (Supervisor and Portainer both have the goal of orchestration, which is conflicting).
In most cases, it will actually cause more problems for lesser experienced users that have no idea what they are getting themselves into. Yet, those lesser experienced users, are the main target audience for this installation method and the ones that need to be protected from getting themselves into impossible situations. More often resulting in support requests, issue reports, end-user frustrations, and an overall bad user experience.
If one really wants to work directly with Docker and has the experience, we, of course, offer the Home Assistant container installation method; which would be a much better fit for you in that case.
Anyways, we provide the means to override/disable these checks, if you really wish, using the CLI tools: ha jobs options --ignore-conditions healthy
Please note, this will render your system into an unsupported state (as running additional containers is not supported anyways, as is also documented).
Going to close the PR on this end, as an advanced option/alternative is offered.
âŚ/Frenck
2 Likes
Hi, in my case I would need to install the âTerminal and SSHâ plugin, but it wonât let me precisely because the installation is Unhealthy.
Iâm quite new and Iâm a bit lost, I donât know if you could help me.
Thank you very much.
We are talking about a supervised install right? Then you have shell access to the underlying debian operating system and can run the ha command there.
Thank you very much, it works fine for me. Can you tell me how can i set it back?
I have all the system mounted on docker, with regular raspbian, I also use the sistem to host other docker containers, does not make sense to block the updates because I have portainer on other container
I have removed Portainer, but still get the âunhealthy: errorâ
How do I find out what is causing this ? Nothing obvious in the logs
Once a system is marked unhealthy only a restart of supervisor removes it. Easiest way is do an ha supervisor restart after fixing the issue. Supervisor will start with a clean bill of health and not mark it unhealthy again.
Or reboot the host if you prefer
I have rebooted the host more than once. Same issueâŚ
When you say âremoved portainerâ did you remove the image as well as the container?
YesâŚ
docker stop portainer
docker rm portainer
docker image prune
docker volume prune
Supervisor logs then.
Hi guys. I came here after posting my own question about this recent developement with not being able to update Home Assistant when running Supervised on generic linux distro install method, and using extra containers. Which Iâve been running with no apparent issues for many years now, until just a week ago, when it refused to update.
At this point I think itâs worth asking one question. With current restrictions in place, and possibly more restrictions coming - are there any benefits left to running this installation method? If we canât install our own containers, if weâre restricted by many things, what benefits are still here (and wont be taken away) by running it this way, instead of running HassOS in a VM? Because Iâm starting to question this. Iâm one step away at throwing a weekend on migrating my setup to HassOS VM and moving all other containers into my other existing Docker VM. Iâm hoping for someone to talk me out of this, tbh.
1 Like
If you are already adept at running containers, the other question to ask is what benefits would you gain from running HAOS. It really depends on how many addons you use and how easily you could run HA container vs HAOS. Especially if you can already handle the networking and VM stuffâŚ
Nothing has been taken away as you were already acting contrary to the prescribed method of using Supervised.
There is no suggestion of more restrictions, where did you get that idea?
hass.io moved to supervisor(and OS). Supervisor has moved to more locked down.
Definition of an âOfficially supported installation methodâ
Today we are introducing a classification between what is âOfficially supportedâ vs âCommunity supportedâ. An officially supported installation method in the Home Assistant context means:
âA way of installing and running Home Assistant that is officially supported by the Home Assistant project. It means the installation method is tested and documented in the official documentation. Running Home Assistant using such a supported method, leads to the optimal user experience, now and for the future.â
The Home Assistant team will not prevent you from running Home Assistant using an unofficial method. However, we cannot help with issues that you encounter. We are open for contributions that improve compatibility with a community supported method as long as they do not impact officially supported methods, add a significant amount of code exceptions or future maintenance burden on the Home Assistant development team.
I do use quiet a bit of addons, and they come preconfigured for use with Hass, so Iâd say itâs a large time saver over running it all myself. My original idea was that everything related to smart home is running inside one VM and one system as much as possible. Which included homebridge, and this ideology has to be broken now because of this new restriction.
1 Like
There is. As it turns out they are consistently adding additional checks that mark installation as unhealthy. Anything that they consider to not comply with their description of the âsupported supervised installationâ is potentially going to become a blocker for updates. My installation was happily updating for over 3 years if not more, until last week when they decided to add a check whether Portainer is installed, and blocking updates for that. It was not a problem last time I updated like a month ago, now it is.
And I see no objective reason for this restriction to be enforced like that. Unless they really hate having to âofficially supportâ this installation method. Which they apparently do.
And it became 'non prescribed method of using Supervised" not long ago. Iâve used it for years as a âsupported prescribed methodâ. Oh, and Portainer was not even on the list of ânon prescribedâ things until recently.
2 Likes