-
DietPi version | G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=15
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘not applicable’
-
Distro version | bullseye
-
Kernel version | Linux DietPi 5.10.110 #1 SMP Sat Dec 3 01:06:07 CST 2022 aarch64 GNU/Linux
-
SBC model | NanoPi R5S/R5C (aarch64)
-
Power supply used | 5V 2,4A
-
SD card used | Amazon A2 class 64GB
-
Software title | AppArmor & CGroup
-
Was the software title installed freshly or updated/migrated? yes
-
Can this issue be replicated on a fresh installation of DietPi? yes
- Flash fresh DietPi image to SD dard, boot, configure essentials (keyboard, timezone)
- sudo sed -i -e “1 s/$/ systemd.unified_cgroup_hierarchy=0/” /boot/cmdline.txt
- apt-get install apparmor
- cmdline.txt says
systemd.unified_cgroup_hierarchy=false systemd.unified_cgroup_hierarchy=0 apparmor=1 security=apparmor
- CGroup is stuck with findmnt -lo source,target,fstype,options -t cgroup,cgroup2
SOURCE TARGET FSTYPE OPTIONS
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory
- AppArmor is inactive
This is mainly needed for a Home Assistant install.
Expected behaviour
- CGroup set to 1
- AppArmor active
Actual behaviour
- CGropup set to 2
- AppArmor inactive
Used this manual How to downgrade cgroup version on DietPi | sleeplessbeastie's notes to downgrade, not successful
I see it has been reported already to HA forum HA supervised install on Debian bullseye brings cgroup and apparmor warnings - Installation - Home Assistant Community
Just to avoid a misunderstanding, DietPi is not an own OS. It’s a set of bash script on top of Debian.
Depending on SBC / manufacture, we use different kernel / configuration. Therefore, you need to be careful which guide you are using as there might be differences depending on SBC. The guide linked above is dedicated to RaspberryPi. Configuration shown inside guide will not work on NanoPi R5S as they use completely different kernel. The configuration file /boot/cmdline.txt even did not exist on NanoPi R5S. Therefore your adjustments done will have no effect.
Actually I’m not 100% sure where to adjust cgroup on NanoPi R5S, but maybe @MichaIng knows.
in general, it is possible to install Home Assistant Supervised on DietPi but depending on your SBC some tweak might be needed. Personally I did a test a couple of years back Home Assistant Supervised on DietPi - #8 by Joulinar
Many thanks for the helpful clarification. So if there is any hint what could be the equivalent of the cmdline.txt of course I would try.
Thanks!
Why do you need to disable cgroup2? That apparmor is disabled is indeed problematic. The problem is that we do not have any access to the kernel cmdline on R5S/R6S as the config is flashed in raw format to one of these partitions 1-6 which cannot be mounted (no filesystem). Don’t ask me why FriendlyELEC chose to do it this awkward way. As fast as there is some mainline kernel support, we’ll provide new images with a proper kernel and all configs revealed.
In the meantime I can try to find out how to extract the cmdline from the respective partition. Not sure whether this is nicely possible since we’d need to somehow detect the ending bit of the config, which of course changes when the config itself is changed.
Many thanks for looking into this. I did not know that the config is “locked” by flashing it to one of those weird partitions. Very strange indeed, it fits into the very strange OverlayFS they normally usein the Bullseye setup. This by the way prevents Docker to run on their own Bullseye Core if you don’t do dirty tricks during the install.
So the reason why I tried to switch on cgroup1 and apparmor was the HA supervised install which requires those two.
For me this means two things:
- Overall the HA supervised install was really a hassle and maybe it is just not worth it. Maybe it is better to switch to the Docker version which has its drawbacks but at least it should run.
- It is giving me a weird feeling that apparmor cannot be activated. Why? So in hindsight I wonder if I want a piece of hardware that is restricting it - directly or indirectly.
But you simply could ignore the warning. Docker is running and your container are up as well. Because you are able to login. Otherwise, you would not see the warning messages 
Or did you find and issue, except the warnings inside HA?
maybe you need to run following to fully ignore the messages.
ha jobs options --ignore-conditions healthy
Correct, HA is running and until now I did not see any issues except the warnings.
It is a little bit with the “Check engine” light in the car, I am torn apart between “if two things don’t run as supposed, there is something wrong” and “as long it is running, it is running”.
Basically, it is your choice of hardware (not DietPi) that leads to these warnings. If you would be on supported hardware (like RPI4), HA installer could manipulate configuration as expected. 
Absolutely. It is my hardware choice that is incompatible with HA supervised. My hope was to manually fix the OS because the claim was “Supervised runs on Debian Bullseye” but in all my attempts there are different blockers - and in the case of this install, it runs way better that in other installs, I even could just ignore the error.
Overall, I did absolutely enjoy DietPi and would always recommend it. Of course I am sad that my idea “R5S plus Debian plus HS supervised” did not work but there is a reason why most people run HA either HAOS on a Raspi or Docker on Proxmox/NAS.
From what I discovered yesterday, you could stay with the R5S. Just run the above command to bypass the OS check completely. This way I was able to install some software title from HA store without issue.
Personally I’m lacking the benefits of HA store because most of software title are available as native installation on DietPi directly. The idea to have everything in Docker migh be cool, but what happens if Docker is failing? All your apps are offline immediately. This we had with Docker 23.0.0 where Docker introduce a bug themselves leading to failed startup on x86.
For sure I will keep the DietPi&HA installation a while - after all it is still a very well running system.
In parallel I will now trythe Docker versions and see if I really like them more.