There’s not going to be a gui option here. If you want to run unsupported or unhealthy that’s a choice you can make and the cli gives that option. Spending dev cycles to make it easier for people to run unsupported easier isn’t really how software works? Dev cycles are spent on the making it easier for people to run the software as intended, users running in other ways are on their own.
This option exists though, it’s in the cli. I mean if you have portainer it was obviously installed via the cli so you have access to that.
Also tbh this isn’t really about safety. Running a container from some random image you found on the internet is the same level of safe as installing a hacs component or installing an addon outside of the official repo. There’s likely one developer responsible with merge access that is also the only one doing reviews. They’re software now has pretty extensive access to your network and system so hopefully you trust them. Maybe more safe in some cases if there is a well-known team behind that particular piece of software.
The main reason behind all this is trying to clearly lay out the bounds of what the HA team supports. Because there is continuous wasted cycles on issues where the root cause turns out to be “user installed x or changed y via the host shell, docker cli, portainer, etc. and it broke”. Which then means the issue is rejected, the developer is unhappy they wasted their time and the user is unhappy because “if it used to work and doesn’t it’s your fault!”
So I’m sorry but it’s not going to be made easier to run unsupported. And more checks will keep being added as things come up in issues. Because otherwise there will eventually be no one left to work on supervisor and addons if developers have to spend all their time debugging issues on unsupported systems.
Here is a workaround that actually helped me to ignore the unhealthy state:
With this file created the superviser won’t complain anymore about the portainer running (and anything else that makes your system “unhealthy”) and will update the HA to the latest version.
Of course, do this only if you are sure what you are doing and WILL remember about this change in the future, in case it becomes a some kind of an obstacle by itself.
P.S. this file should be created in /usr/share/hassio of the host system. Not inside the system of a HA container.
One correction to this: feel free to post whatever you want to this forum. This is community space, if you’re struggling with an unsupported system its a fine place to post and see if anyone else happens to run the same config as you and solved it.
Just don’t create any github issues on HA repos. They will be ignored/rejected unless reproduced on a supported and healthy system.
So i stumbled across the same problem and i was like WTF!?
I am glad i found this topic here so i know what the reason was.
after removing the portainer container from my docker setup and restarting the whole system my system went to healthy again and i could update again. now i reinstall portainer as a container and redo the same procedure when i want to install the next update.
but i mean… come on…
i understand this change happens due to security issues but there should be a way to exclude these checks for certain containers (like portainer). everyone with access to cli can do this tedious workaround with downtime of all containers…
please revert this back or give us users a way to exclude portainer from this “unhealthy list”
There’s no downtime required. Scroll literally one post up from yours to see how.
As I said earlier, this isn’t really about security.
This is primarily about developer time. There is a very small set of developers working on supervisor and unfortunately a lot of that time is spent digging into issues that turn out to be “user did something unsupported and it broke”. Every unsupported or unhealthy check that is added is done so because its a source of at least one issue in supervisor/addons/ha, most of them many.
As to why portainer is unhealthy vs unsupported, its container orchestration software. There’s no one thing it does that is bad, it makes it easy to change any number of things about the docker setup in ways that break HA and supervisor. Plus its job is literally the same as supervisor, to manage your system and the docker network. So if you want to use portainer, just switch to a container install and get rid of supervisor instead of having putting two pieces of container orchestration software on the same system.
I think it’s easier to get rid of portainer than switching the installation methods and dependencies of all add ons.
And I think that is what I will do.
I see your arguments but I don’t think this will be the best solution to your problem.
As you see there are already two workarounds for this and portainer could still work with supervised install.
So people who want to run portainer with supervised could still do it. Mostly they are not the same people which will break there System and ask for help.
I think you will have some hard time to justify this decision when every supervised user with portainer wants to update
And I hope you will implement some gui switch to switch the healthy check on/off or a button which says“ I know I do crap and my system can break but I won’t ask for help when I update and something went wrong“
EDIT: when i would disable the health check is it save to run ha supervised? or do i need it?
That’s ok. In fact if there were no workaround that would be a real problem. It is your hardware after all.
The goal isn’t to stop people from shooting themselves in the foot if that’s what they really want to do. That’s not possible and trying to do so is a waste of time.
The goal is simple:
Make sure people are aware what they are doing is unsupported, untested, has broken systems unexpectedly and very likely will do so again without warning in any update (major, minor or patch)
Make sure developers can easily identify and filter out issue reports from users choosing to run unsupported systems since those aren’t bugs. Users running unsupported systems must either reproduce their issues on a supported system or fix any issues they encounter themselves.
Yeah but this seems a bit hard for me. There should be a message or something but not an error you cant fix in an easy way.
But thats just my opionion i can live with any of the workarounds. Im still very happy that you and all other devs are doing such a great job and giving me some good time with my smart home.
I hope that i didnt sound too angry, i just paniced a little and i my only thought was why in the world would anybody do this. now some hours later i can totally agree with this.
the only thing which should be done is to notify supervised users (maybe with portainer) what they should or can do.
I have just seen this error in supervisor log which is blocking HA updates:
— Found image in unhealthy image list ‘portainer/portainer-ce’ on the host…
I assume from this thread, that it is because I installed portainer as a container manager on the same system (which I assumed 2 years ago was a totally passive/acceptable thing to do).
Can anyone help me out and advise what I should be doing with a supervised install from now on. Also is there an inference from this topic chat that I cannot install any containers (outside selected HA addon’s) on my server?.
