Error updating Home Assistant Core 'HomeAssistantCore.update' blocked from execution

What would be a command to revert? I used the ignoring, did the upgrade and I am considering now to put it back - the warning I mean.

ha jobs reset
should restore the original configuration.

2 Likes

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.

May 2020 blog