For those on raspbian buster…
I’ve just changed /etc/apt/sources.list.d/docker.list
from
deb [arch=armhf] https://download.docker.com/linux/raspbian buster edge
to
deb [arch=armhf] https://download.docker.com/linux/raspbian buster stable
Then I just updated docker and rebooted the host
sudo apt update
sudo apt upgrade
sudo reboot
Thank you all 
This worked! Thank you so much. For some reason in the UI, I couldn’t update the OS beyond version 5.13. I forced it to update to HAOS version 7.0 via the CLI and now the docker version is 20.10.9 and the latest supervisor runs!
Thanks a lot everyone. I thought too that my SSD or rpi was dying. Did some fsck with no errors, and was going to pull up some old backup to compare the init.py file of the supervisor since it is the last line in logs before crash. Then googled “”/usr/src/supervisor/supervisor/docker/init.py"" got here directly, apt update and upgrade, back on track !
Thanks to all the great community ! Happy to have my automations back ! 
PS: For info I am running docker on a personalized rpi install
There is an “intermediate” fix for the crash in Supervisor 2022.07.0, but docked should be updated to 20.10.0
I was also hit by this… Running HA Supervised on a old Lenovo Tiny system. Thought the SSD had died or something, but it passed all the tests I could run on it. But kept getting the same errors without changing anything. Didn’t find this thread last night.
Ended up wiping it and switching to HA OS. Restored my last backup and was good to go again.
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.
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.
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.
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
