So you are running ha in a container and it’s showing as fully supported now?
It is possible to get it supported… If that was your question.
System information
Version core-2022.9.5
Installation Type Home Assistant Supervised
Development false
Supervisor true
Docker true
User root
Virtual Environment false
Python Version 3.10.5
Operating System Family Linux
Operating System Version 5.15.61-v8+
CPU Architecture aarch64
Home Assistant Supervisor
Host Operating System Debian GNU/Linux 11 (bullseye)
Update Channel stable
Supervisor Version supervisor-2022.08.6
Agent Version 1.3.0
Docker Version 20.10.18
Disk Total 218.8 GB
Disk Used 27.1 GB
Healthy true
Supported true <<<<
Supervisor API ok
Version API ok
cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=89a15c5a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false apparmor=1 security=apparmor rootwait
As long as you do not install any containers on your own (without using HA) there is no problem.
arch: aarch64
auto_update: true
channel: stable
debug: false
debug_block: false
diagnostics: false
healthy: true
ip_address: 172.30.32.2
logging: info
supported: true
timezone: Europe/Madrid
update_available: false
version: 2022.09.1
version_latest: 2022.09.1
wait_boot: 5
I know the intentions of limiting external docker containers but i prefer to install portainer and enable external access to it. This gives me direct access to docker without relying on supervisor and my system is marked as unsupported.
But, am i missing any gold level support with being unsupported or nice new features? I don’t know 
I find myself facing the same “connectivity check” issue on both of my Home Assistant instances (Debian 11 on both; one is a laptop and the other is an RPI3).
I tried the suggested busctl command in the documentation but, after a reboot, it didn’t eliminate the issue.
I followed Tamsy’s suggestion to if check avahi-daemon is running but it’s not.
Have you had any success fixing the problem?
1 Like
maybe this…
2 Likes
Nope, was waiting for someone smarter than me in linux to solve it.
I’ll try that when I get home tonight and update you. I have a feeling it will work as my setup is from 2017/18
1 Like
Sorry about that. I didn’t realize the supervised installer didn’t use to set the connectivity URI and doesn’t update NetworkManager.conf when re-run. Put in a PR to update that doc to include separate instructions for when the connectivity check is completely unavailable vs. just turned off.
3 Likes
Thank you!
I just tried it on the RPI3 and it eliminated the connectivity_check warning. FWIW, I increased the time period from 600 to 3600.
Now I need to eliminate the cgroup_version warning that is reported only on the RPI3 (not the laptop). I don’t recall setting the version manually so it appears I will need to perform the suggested fix which is to re-run the Supervisor installer. Are there any side-effects associated with re-running it on a working system?
2 Likes
Thank you for this great tutorial! I’ve installed successfully a supervised Home Assistant with a RPI4, even if there were some errors. In the last step, the installation of homeassistant-supervies.deb it gave me a warning regarding the switch to cgroup v1:
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the 'ha' cli
[warn] Could not find /etc/default/grub or /boot/cmdline.txt failed to switch to cgroup v1
[info] Within a few minutes you will be able to reach Home Assistant at:
[info] http://homeassistant.local:8123 or using the IP address of your
[info] machine:
The Web interfae was even after half an hour not reachable, on the display attached to the RPI were some messages regarding AppArmor, like
audit: type=1400 audit(1663799912.587:9): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor" pid=1320 comm="apparmor_parser"
and similar, with other names.
As well several
vc4_hdmi fef00700.hdmi: ASoC: error at snd_soc_dai_startup on fef00700.hdmi: -19
vc4_hdmi fef05700.hdmi: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19
messages.
However, after a “reboot” via CTRL+ALT+ENTF the RPI booted and the Home Assistant Web interface got reachable, except the mentioned messages during boot without any problem.
Two questions regarding this installation, even if I get an “unsupported” version by it.
Do you have experience with Desktop environments or at least a window manager like i3 on Debian11 supervised Home Assistant? It would be wonderful to access the Home Assistant without a second computer.
Does this installation method work as well with full disk encryption? As there is a lot of privacy related data stored on the device this would be awesome. Or do I have to expect an unbootable device?
@kanga_who Would it be possible to add information about the cgroup issue into the guide?
If not directly into instructions, than at least to the “Section 4”?
Fix is pretty simple and root cause is that the supervised installer clearly doesn’t support Debian 11 for RPi, as it is trying to switch to cgroup v1 by editing either /etc/default/grub or /boot/cmdline.txt none of which exists on Debian 11 for RPi…
Correct instruction that should be added to the guide is:
sed -i.bak 's/$/ systemd.unified_cgroup_hierarchy=false/' /boot/firmware/cmdline.txt
Without this in the guide there are hackish solutions in the discussion like this, which doesn’t solve the situation, only tricks the installer to not complain about not finding the files it wants to edit 
I have tried reporting it as a bug but that was already done before without much success…
Edit: I went on and fixed it so it should not happen anymore. Just use the latest release.
5 Likes
Hi everyone. I followed the guide in the first post and everything works… Except for logs.
None of the containers post any logs (supervisor, core, cli, dns… , and the same goes for the addons).
From portainer I see <<No log line matching the ‘’ filter>> , while in home assistant I can see only the logs from core. I tried installing an older version of supervised AND an older version of os-agent. Didn’t help.
Other containers works and post logs correctly.
Do you guys have any idea?
I installed the lastest version (1.3.1) and still get the warning [warn] Could not find /etc/default/grub or /boot/firmware/cmdline.txt failed to switch to cgroup v1.
I added systemd.unified_cgroup_hierarchy=false to the cmdline.txt file in /boot. I do not have a /boot/firmware/ directory. Is the next step to create the directory and the file?
Thanks for your advice.
Could you share the url from where you downloaded Debian 11 image you are using?
I used Raspberry Pi Imager v1.7.3 and installed Raspberry Pi OS Lite (64 bit)
Than that’s your source of trouble.
Sadly Raspberry Pi OS is not supported operating system for Home Assistant. Only Debian 11 is. Hence the installation script doesn’t work well with your OS.
OK - thanks for the info. After many attempts to uninstall, reinstall, reboot, repeat. I still got the error but HA started and is running without problems. All good at this stage.
Sure, it mostly works on other Linux distros, but if you check the system information, you will see your system as unsupported and from my experience you will hit issues sooner or later.
1 Like