Problem with Supervised install and apparmor

I’m getting regular issues with my Supervised HA, installed on Raspbian on an RPi4-4Gb SD boot with the rootfs on an SSD. It seems a soft reboot fails to load the rootfs properly - I say ‘seems’. I think this mornings crash was due to the supervisor update. syslog extract;

Apr 23 02:40:54 hassio systemd[1]: Stopped Hass.io AppArmor.
Apr 23 02:40:54 hassio systemd[1]: Stopping Hass.io AppArmor...
Apr 23 02:40:54 hassio systemd[1]: Starting Hass.io AppArmor...
Apr 23 02:40:54 hassio hassio-apparmor[26405]: Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
Apr 23 02:40:54 hassio hassio-apparmor[26405]: Use --subdomainfs to override.
Apr 23 02:40:54 hassio hassio-apparmor[26405]: [Error]: Can't load profile /usr/share/hassio/apparmor/hassio-supervisor
Apr 23 02:40:54 hassio systemd[1]: Started Hass.io AppArmor.

What is hassio-apparmor looking for in /proc/mounts that it cannot find? A hard reboot is fine - and on that occasion there are no log messages about apparmor at all.

Digging around. The last part of this bug report may offer a clue. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921667

[edit]
apparmor is installed but

$ aa-enabled
No - not available on this system.

and

$ sudo apparmor_status
apparmor module is not loaded.

It would seem that on first boot, hassio checks successfully, but on a soft reboot forces the service which fails.

[edit]
Doing some more research, I find that apparmor is not compiled into the kernel of Raspbian - explains the messages above and why it fails :grinning:. https://www.raspberrypi.org/forums/viewtopic.php?t=257495

I would think that supervisor should check, not for the presence of apparmor, but its availability for use.

2 Likes

Any chance we’ll get a response here?

If you run a supervised on raspbian, switch to debian.

This is quite old and things have moved on (notably to Raspberry OS).

However, I did propose a change to core that would not just check to see if apparmour was installed, but actually usable, but I got the ‘not a supported system’ response even though it could happen on any system. I did also suggest a note for the docs which got a similar response.

I don’t know when it changed, but these days Supervisor actually checks if apparmor is enabled on your system.

I think what I discovered is that the current test can show that apparmor exists, without it actually being available to use as it checks for the parser, not if it is complied into the kernel. As you can see from the associated issue I raised, there is an alternative check that can be used to confirm if apparmor is available for use.

Current test

My test;

# Available for use?
if ! aa-enabled --quiet 2>/dev/null; then
    echo "[Warning]: apparmor not available on host system!"
    exit 0
fi

But the suggestion was rejected.