Found it thanks to your hint. Certainly well burried.
Somewhere up this thread I wrote instructions on how to upgrade from buster to bullseye the correct way. But it seems to be too late anyway.
I went from a RPI4 to a mini pc for my personal HA instance at home last April and installed bullseye as the base system to HA Supervised and all seems to be OK:
I actually followed your post to do the upgrade. The only grey area is how I originally installed supervised (in 2018/17). I may have ran the whole installation under root instead of my user as sudo. While Iām not a linux expert, Iāve heard that leads to issues. Thatās my only guess at this point.
No I have not, Iāll check when Iām home tonight. If I can avoid reinstalling the OS, I will.
Installed following the guide, using 2022-09-06-raspios-bullseye-arm64-lite.img Raspios 64 in a RPi4 4Gb.
To avoid the unsupported message I need to add lsm=apparmor to /boot/cmdline.txt
and run sudo systemctl enable NetworkManager.service
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
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).
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.
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?
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 cgroupissue 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
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.
