let the people decide if portainer is an issue or not. To be honest, this seems to me too strict.
It was running for years and now I’m not able to update anymore
4 Likes
Just read this thread…
Still I think this change misses the target, I assume that the unhealthy/unsupported info is to tell users if you don’t run HA according to official configuration you won’t get support, right?
Blocking HA from execution is another thing, you stop users from doing stuff they want to do, even if they are well aware they’re doing it at their own risk and they won’t be eligable for any kind of support.
There’s probably going to be a lot of complaints about this.
12 Likes
don’t need to remove portainer.
sudo docker stop portainer
sudo docker restart hassio_supervisor
Update HA and then you can start portainer again
(sudo docker start portainer)
22 Likes
ah, thanks for the hint
Thanks, I’ve updated my post.
1 Like
here is another workaround
4 Likes
Also, no need to reboot host,
sudo docker restart hassio_supervisor
is enough.
1 Like
…now updating. Evien with docker 20.10.5 (dont need to meet docker 20.10.17 for healthy from docs).
Clearly Portainer was the issue HA was having for this update. I will start portainer as soon as I finish my updates. Never have a problem with it.
docker container list
(my portainer image alias was agitated_johnson)
docker container stop agitated_johnson
docker container restart hassio_supervisor
(back to HA and update)
docker container restart hassio_supervisor
docker container start agitated_johnson
3 Likes
Ok, updated it again. Thought I tried that, but I might be wrong. Thank you again 
Was deprecated from the list of community addons a long time ago. Because it was a source of tons of issues in the HA repos. Where users used it to get in strange configurations and then reported issues when things didn’t work. Hence the unhealthy check.
This works, but also if we’re just going to do this anyways, why block us from using Portainer in the first place? For anyone who doesn’t know what Portainer is, they’re not even going to know how to find this thread 9 times out of 10 as the error message just says ‘Docker’. It doesn’t even say ‘Docker Orchestration Software’ to be a bit more insightful. It seems like a rushed decision by management on this one.
5 Likes
Yes, you do know I completely agree with you?
You did read my earlier post?
Whole thing doesn’t make sense, people will understand that they won’t get any support if they start making changes. Doing things this way will make some people stay away from HA.
It’s not a commercial product, no need to harden the software like this. (or are they preparing for some kind of commercial launch…?)
We should start some kind of vote for having this change revoked!
10 Likes
Sorry Nikler, I know you agree / I was agreeing with you. My comment was more to the mods instead of you so I probably shouldn’t have quoted you. Sorry about that. I 100% agree we should have a vote on revoking this.
You’re wrong, they don’t. There’s issues all the time from people with systems that tell the user they are unsupported or unhealthy who still expect support. Let alone systems that aren’t given this designation.
People assume that if something did work it should keep working, regardless of what it is or how they did it. The fact that it was never supported in the first place frequently doesn’t seem to register, its apparently always the fault of the update 
Portainer was particularly problematic. Not only did it expose so many options that could break the system, it used to be an addon the community repo and there’s still people running that addon. Which means people running it may have had no idea they were unsupported. Not to mention the software itself is now woefully out of date with no updates ever coming.
Sorry, but, again, all this seems overly strict to me too, especially for an “open source” project. We understand that one of the main goals this past couple of years has been to “dumb down” the project and/or to “Applefy it”, but this is WAY too excessive.
First of all where is it documented that “people updating to HA core 2022.9.2 and having portainer will immediately have an unhealthy installation and further on that they will not be able to update from that point on”? I was not able to find such a warning. I always had an “unsupported” installation for this reason, which I accepted, but not being able to update the software goes a long way. At least make it an option.
Secondly, having HA and various other docker containers on the same host should be a valid option for the users, especially those who have a supervised install. Because what is the point of having a supervised installation if the user cannot use the host for anything else? That’s why we opt for a supervised setup in the first place! I understand the “unsupported” state, but not being able to use the host for anything else unless I accept to have an outdated HA instance is unacceptable to my eyes.
“Inexperienced” users will: a) Either have HA OS installed and (should) not tinker further. b) Or not even know what Portainer is, how to install it out of the HA environment as mentioned above, let alone “play” with it and mess HA. Even then, the project would not be the one to be blamed but the user, doing things without any knowledge.
Anyway, all this should not justify the strict, unrelenting decision for everyone else “either have ONLY HA or have also something else but an outdated HA instance” .
7 Likes
Then I’m sorry to tell you but you made a decision based on a fundamental misunderstanding of the supervised install. As it says very clearly in the ADR:
- The operating system is dedicated to running Home Assistant Supervised.
- All system dependencies are installed according to the manual.
- No additional software, outside of the Home Assistant ecosystem, is installed.
Both supervised and HAOS are only supported as pure appliance installs. Neither was intended to be used alongside myriad other software that is not part of the Home Assistant ecosystem.
All checks and conditions that are added also come with options for advanced users to ignore them. Scroll up in this thread to see the one for this check. If you want to run this way nothing stops you, there’s a built-in option to allow that.
The checks are all added because it has come up in issues forcing developers to spend time digging into things that aren’t bugs. They are user caused from doing unsupported things. So to prevent this from happening again a check is added. Always with a way to ignore but want to make sure everyone is on the same page - “{x} is not supported”. Or in some cases “{x} is deeply problematic (i.e. unhealthy)”
I hear you and I get the part about people still expecting support.
However, wouldn’t it be better to make a habit of declining support when users ask for support for unsupported HA setups?
Perhaps adding some pop-ups everytime HA is restarted; This is an unsupported setup, please do not report tickets occurring on this system, you will not get help.
Also, the support is community driven isn’t it, there might be people willing to give support as long as it is clarified from the user what tweaks has been done?
Why not implement an option where you can disable those checks, making the above statement very clear when doing so?
1 Like
You very clearly failed to quote one sentence before that: “This installation method can easily be broken if one manages the operating system incorrectly.” All this seems like a simple, clear “recommendation” to me, not a strict “sorry, you will have to accept a new Apple-like environment”, where you will not be able to install anything else along HA. “Take it or leave it”.
Apart from that, is there an answer to my question, where was this BREAKING change clearly documented? Or did it just creep its way in the update just like the myriad other changes that slowly but steadily try to force us to abandon a supervised install?
Who is talking about “support”? All of our installs were “unsupported” almost from day one for this reason. We accepted it, we understand the “recommendation”, we note it. Now we are simply forced to abandon HA supervised or any other software on our hosts. It doesn’t get any more “Apple” than that.
Can’t understand why having Portainer was not deeply problematic for x amount of years and it suddenly is considered such.
6 Likes
If this is your stance then why has anything changed for you?
ha jobs options --ignore-conditions healthy
Done. Still unhealthy and unsupported but no more update errors.
Like I’ve said many times in this thread, there are no unignorable checks. No one is going to stop you from doing whatever you want. The goal is just to inform users of the risks and ensure developers know the situation if a ticket is opened.
EDIT: I guess I should say probably no more update errors. It won’t block you from trying. Whether it works or not I have no idea, depends what all was changed.
EDIT 2: I just realized I hadn’t shared the jobs options thing in this thread. So apologies for that, you couldn’t see it if you scrolled up. There’s a couple similar threads and I forgot where I shared what.
1 Like
This has been an unproven statement since the day HA decided to make supervised installs obsolete for unknown reasons and immediately took this decision back after a huge community backlash.
How many people asked for “support” and the problem was that they had Portainer installed outside of HA? Are there statistics about that? How much big of a deal is if someone has a couple of containers installed alongside HA? How are we supposed to troubleshoot a failed HA update if the whole HA docker ecosystem does not even start if we do not have Portainer to see what’s going on?
If someone “plays” with HA supervised and some containers alongside it and messes the system: a) They know they’ve done a boo-boo and do not expect “support” from the project. Anyway, it will not be War World III, it’s not software to control hospitals, it’s just a piece of automation software. b) The community could be willing to offer support in those cases too, what’s the big deal? c) Support could and was always rejected in such cases. Now an update of HA is prevented, this is an other whole story.
After this initial failed decision to make supervised installs obsolete, every 5-6 months we have another “change”, which tries to make supervised installs and having other software on the host as inconvenient and/or as difficult and complicated as it gets (=example: Os-Agent, with no easy way to install and update it or at least to have notifications for an update).
5 Likes