Also hit by this issue this morning. Running Supervised in Docker on Ubuntu. Panic ensued.
sudo apt-get install docker-ce docker-ce-cli containerd.io -y
per konradwalsh post above fixed this for me, after a reboot of host.
Armbian is just debian with with patches so OS runs on different arm boards. Armbian should be one of the supported platforms when doing testing.
Good stuff. I was on a similar version. 5.something. Once I got into the UI I had to do 3 or 4 consecutive OS updates to get to current. I thought I had kept it fairly well updated … apparently not!
Good morning. Same issue on rpi 4. No custom docker or os, everything is stock home assistant.
However I don’t have a normal shell on console to do apt-update. How do I break out? I logged in with ‘root’ and no pw.
Right so it’s not just debian. Supervisor has deep dependencies on the Host OS so even small differences far under the hood cause problems for it. This is why the ADR is very clear on this:
Supported Operating System, System dependencies and versions
- …
- Debian Linux Debian 11 aka Bullseye (no derivatives)
The only supported host OS for a supervised install is vanilla Debian. Not armbian, not ubuntu, not Linux Mint (as I saw earlier), Debian only. You’re welcome to run others as it is your system. But there will be no testing done on other OS’s prior to release and issues are only accepted if reproduced on a supported system.
1 Like
This highlights the continued need to disable auto updates for Supervisor. It should notify for an update, and then allow to SKIP just like HA core and all other addons.
I understand that the developers are worried about users disabling updates, then somehow forgetting, and then complaining when something breaks. But having an unsolicited supervisor update break the system is much, much worse.
Many of us require stable systems that don’t update anything. Only security patches after a changelog review. And many of us run Home Assistant completely offline with no cloud integrations. It would be nice if Supervisor would allow this and not throw errors every time it can’t get to github or try to babysit passwords with HIBP.
An offline Home Assistant should be stable and not need updates every few weeks for changes that aren’t even relevant. I want to review every update for security patches and/or relevant integrations/functions,… and skip if they aren’t relevant.
If something breaks eventually, I will remember that I’m not on the latest version and won’t complain to the community until updating everything.
2 Likes
It’s not that simple. The problem is supervisor manages all the other addons and core. Lets say for example a new config option was added and then an addon updated to use it. Or one of supervisor’s APIs was modified and then the CLI was updated to accomodate that change (since that happens every time). Or an addon (since they communicate directly with supervisor).
It’s being considered but the way it would work is supervisor would have to freeze the entire system while it was out of date. No updates could be installed for any components until supervisor was updated first to ensure that update works correctly.
That would still give control over when supervisor updates so it’s still a worthwhile change. But managing its updates like any other component in the system (skipping updates, rolling back to prior versions, leaving it out of date while updating other things, etc.) is very unlikely to happen.
That’s fair. Supervisor is above all other addons, so I get that it should get updated as a prerequisite for updating subordinate components/addons. Should be as simple as greying out the addon update options with a warning that Supervisor is not up-to-date.
It is just important that a stable system can be frozen completely to remain stable.
I get update notifications every few weeks for HA core and updates for addons get updates often too.
When I check the changelogs, usually there is no reason to update. It becomes a game of “update for the sake of keeping up with other updates”.
I don’t likely need any “new config option”. If my Home Assistant is working as is, it becomes more likely that an update will break something, than offer any benefit.
1 Like
Can the HA team point to the exact debian 11 arm distro download they support along with the accepted arm hardware platforms?
Based on the comment I don’t believe there is any straight arm based Debian 11 that will run HA. In this thread it’s pointed out that you need to modify kernel parameters changing cgroup v2 (The default) to cgroup v1 in order for HA to work on any install of Debian 11. Thus a change is required. I run what I view as straight debian, as no debian packages are modified to make it work, on the odroid N2+. It does required a kernel build and kernel parameter configuration. In addition I have to set the interrupts for mmc, usb and eth0 to insure the interrupts for each of these hardware components are handled on one processor. This is inline with what Debian 11 would call a Debian 11 install. While armbian does a few more hardware specific modifications they utilize the standard Debian arm packages.
The best platform for a standalone HA controller install is the odroid N2+. I know a lot of people run on the raspberry Pi 4, but it’s under powered compared to the odroid N2+.
I previously posted these instruction for loading what I view to be a valid debian 11 build for the odroid N2+. Supervisor also reports it as supported. With a couple of configuration tweaks you can also build a raspberry Pi4 based system.
I would really love it if the HA team point to the exact debian 11 arm distro download they support along with the accepted arm hardware platforms?
Thanks for all the great work.
Do you use the odroid N2+ for anything else but HA?
I do have a few scripts that I run on it to enable HA control/integration of other function such as my cellular backup, GPIO integration of wired door/window contact sensors and Cat feeder integration. It’s a straight Debian 11 build so you could run whatever you like on it.
This highlight people need to run supported installation methods; as set out by the requirements and keep their systems up to date. This didn’t show up in tests either, probably because everyone who did tests (and the beta channel) did have their systems in check.
If you want that level of control over your system, we suggest using a different installation method. For example, use the Home Assistant Container method instead.
-frenck
I guess the official response is still, “user’s fault for not adhering to the fine print (architecture/adr/0014-home-assistant-supervised.md at 73be016a4c933adc649a7b257da1aa2f1a070744 · home-assistant/architecture · GitHub)”.
“This method is considered advanced and should only be used if one is an expert in managing a Linux operating system, Docker and networking.”
I mean I haven’t tried it on an odroid myself but Debian has a whole guide for arm64 no?
Just as an aside, all of this is also unsupported in a supervised install. Well actually technically some of them aren’t but the way you’re describing it is.
From the published requirements for a supported supervised install:
- 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.
- Docker needs to be correctly configured to use overlayfs2 storage, journald as the logging driver, and cgroup v1.
- NetworkManager is installed and enabled in systemd.
You’re describing how to do tasks that requires changing things and installing additional software on the host outside of Supervisor. That breaks the one I bolded. Supervisor may not have an actual check for the specific thing you’re doing yet because it hasn’t broken anything yet. But your system is unsupported according to the ADR.
Of course not everything you’re describing has to be unsupported:
There’s a bunch of HACS integrations for GPIO integration. If you install and use one of those then that is supported. But if you muck around in the host OS to get this working then its not
The Let’s Encrypt add-on in the official addon repo supports generating wildcard certificates if you can prove ownership by either HTTP or DNS challenge (with more challenge options seemingly added regularly). If you use that then it is supported. If you install certbot and setup a cron job on the host then its not.
As with before nothing stops you from doing these things. If its all working for you and you prefer it that way then by all means go for it. I just want to note that there seems to be a misunderstanding about what constitutes a supported supervised install. It’s really not “HAOS but with Host Access!” Host access for anything other then keeping the dependencies of HA up to date most likely puts your system in unsupported territory.
That’s why if you want to run additional software on the system alongside HA I would suggest using a VM approach rather then a supervised install personally. Put HAOS in a VM and let it operate in its box. Then do what you want in other VMs or on the host OS outside it.
The ADR also says,
In case any abnormality is detected that prevents Home Assistant from functioning, the Home Assistant Supervisor will report this to the user and block updates to prevent installations from breaking.
So Supervisor still fails in it’s checks.
It’s true. It’s rather difficult to check for every possible piece of additional software that could be installed. Checks have been added for things that have broken supervisor. Checks have not been added for things that has yet to break it.
A lot of this stuff operates in a sort of gray area. Take installing certbot on the host OS as a simple example. Technically that makes the system unsupported. But as supervisor exists nothing breaks. So it has no real impact here. The checks all pass, any issue submitted by that user would say supported and its unlikely to come up because its not the cause of the issue. So its irrelevant.
Unless someday certbot starts depending on a version of a package that Supervisor also depends on and requires a different version of it. Now suddenly that is a problem, systems break and issues are reported. And it will either fail a check or a check will be added once the root cause is determined.
Is this a likely scenario? Probably not. You could probably have certbot installed for all time and no one would be wiser about it. But its also why its safer to simply put HA in its own box and let it manage its own dependencies without worrying about conflicts
2 Likes
It is solved in 2022.07.0, it does a check for the missing CgroupVersion. Bugs happen…
You could easily roll back your Supervisor with docker tag command, if you have access your OS, or your HA Core container through the SSH addon.
You got to love it when a stable repo has later versions than the edge one.
I mean I haven’t tried it on an odroid myself but Debian has a whole guide for arm64 no?
If Debian 11 worked out of the box on arm boards in general there would be no reason for armbian. But arm board (arm64) still are not x86. I got multiple Debian 11 distros, even one straight from the vendor forum, to load and run a couple of days, . They all crashed at some point. The distro I pointed out is the only distro I know of that works on the odroid N2+.
The next question will be, that the new release of Supervisor, which will require mandatory Docker 20.10.0 as minimum, will it stop updating due to a Docker version of 19.X?
I understand frenck’s point. I just think that even advanced/expert users could use a little leeway here. Not auto-updating in the middle of night, allowing to skip an update if there is a breaking change, give users a window of time to ensure the system is in a proper state.
My system was only down for a few hours while I searched the forums, but this is entirely avoidable with some basic considerations that have been requested for years. If devs could meet us half way, we can better meet those requirements.
3 Likes