I know, I just overlooked it. Frustration and concentration are not the best friends… 
2 Likes
What is an “add-on option”
What installed things. How did you install them?
What exactly did you do? The installer doesn’t just install the supervisor, it does lots of shit, none of which remove anything as far as I can see.
I had to do the same, but the warning is still present - although I’m not sure that the service has been configured properly, not sure what the configuration is supposed to be though
systemctl --state=running --type=service shows me:
UNIT LOAD ACTIVE SUB DESCRIPTION
containerd.service loaded active running containerd container runtime
cron.service loaded active running Regular background program processing daemon
dbus.service loaded active running D-Bus System Message Bus
docker.service loaded active running Docker Application Container Engine
[email protected] loaded active running Getty on tty1
haos-agent.service loaded active running Home Assistant OS Agent
hassio-supervisor.service loaded active running Hass.io supervisor
NetworkManager.service loaded active running Network Manager
polkit.service loaded active running Authorization Manager
rsyslog.service loaded active running System Logging Service
ssh.service loaded active running OpenBSD Secure Shell server
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running User Login Management
systemd-resolved.service loaded active running Network Name Resolution
systemd-timesyncd.service loaded active running Network Time Synchronization
systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files
udisks2.service loaded active running Disk Manager
unattended-upgrades.service loaded active running Unattended Upgrades Shutdown
[email protected] loaded active running User Manager for UID 1000
wpa_supplicant.service loaded active running WPA supplicant
the supervisor ugpraded from 1.2.2 to 1.3.1, but the error’s still popping - going to ignore it for now, I have work to do
BAH, I reinstalled my supervisor using the link from above and now I’ve lost my add-on options and many of my previously installed things!
How do I get them back?
I thought I’d restore the backup but I don’t even have backup listed in the settings/system menus!!
I’m seeing this in my ha su logs:
22-11-03 20:16:29 ERROR (MainThread) [supervisor.homeassistant.api] Can't update Home Assistant access token!
22-11-03 20:16:30 ERROR (MainThread) [supervisor.homeassistant.api] Can't update Home Assistant access token!
I was originally using the -d option (for an alternate directory) with the original supervisor install.sh script which was apparently deprecated for the deb file which forces everything into /usr/share/hassio, from what I can tell. This is causing my installation to be borked now. I’m attempting to remove all my customizations so I can perform a fresh install to the /usr/share/hassio location and then restore a backup…
The full restore from backup sorta worked, the system is “up” but several sub-systems are semi-broken. The Add-ons are all greyed out like Home Assistant doesn’t know that they’re running even though I can see them in the docker container ls results. Also they appear to be up when I query them directly (bw, unifi), however ESPHome/Studio Code Server thinks they’re down and the ingress is unreachable because of that “Add-on is not running. Please start it first”. The Z-wave JS integration is broken, all devices offline and won’t load properly even though I can see in ha su logs it is complaining that core_zwave_js is already running!
How can I get my system back up and running at full strength?
Hello,
After clearing the “systemd-journal” unsupported error , i got the following errors when searching the host log
Nov 04 09:20:25 Debian11-KVM systemd-journal-gatewayd[4081]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported
Nov 04 09:20:25 Debian11-KVM systemd-journal-gatewayd[4081]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not supported
Nov 04 09:20:25 Debian11-KVM systemd-journal-gatewayd[4081]: microhttpd: Failed to push the data from buffers to the network. Client may experience some delay (usually in range 200ms - 5 sec).
Same with command " sudo systemctl status systemd-journal-gatewayd.service"
Any advice please ?
1 Like
It’s reported
here
We are all waiting for solution. The systems are working at least for majority of us.
1 Like
I can understand the unsupported OS messages in the above case. However, seeing " Unsupported system - Operating System" errors when using the latest version of Home Assistant Operating System is hard to fathom. I’m fine handling this issue on my own, but this certainly is unexpected.
- Unsupported system - Operating System
- Unsupported system - Systemd issues
- Unsupported system - CGroup version
I installed the new supervised HA deb file on top of my supervised HA script install. When I originally installed it, I used the -d option to install it to a custom directory. That isn’t a thing with the deb install, it always goes to /use/share/hassio.
Anyway, ever since then I can’t use the script method to use my custom directory because the script is long gone and I tried using the deb by stopping the supervisor, removing all containers, deleting /use/share/hassio, reinstalling from the deb, then restoring the backup but the add-ons still aren’t recognized as running by HA.
I brought it into the discord and the guys there apparently just want everyone to run the HassOS and aside from recommending that they wouldn’t help me. At this point I think that might be the only way I can restore this thing since I know very little about the supervisor’s operation/integration.
another core breaking update, i get so fed up of this every time it updates to a new version.
isnt anyone testing this before hand
these errors are related to your Operating system…
There are already instructions - and a complete dedicated thread about these issues available:
1 Like
FYI, you’ve had those issues for a while. HA just tells you now. You should look into the community guides or documentation for assistance. Each repair describes how to fix it. Lastly, these typically wouldn’t be an issue if you were using another os.
2 Likes
but let me state that this is an update, not an installation and it should say this prior to allowing the update to continue. its just poor. I shouldnt have to dig into the bones of it to check whether or not the update is for my standard raspberry pi install.
2 Likes
Your issues existed before you updated. HA is now telling you about the issues. So all that changed this release was letting you know about supervised unsupported issues. Had you checked the system health page prior to updating, you would have seen these issues as well.
4 Likes
i rolled back and checked health, nothing to see
You didn’t look in the right spot
Settings → system → repairs → … menu → system health
2 Likes
Read this post for the directions to the two places places you can look after rollback. Read this post for a detailed explanation on why updating to 2022.11 did not change whether or not your system was supported.
Also please move further discussion about this to that thread so the thread doesn’t get hijacked by things unrelated to the release again.
3 Likes
Hello,
I’ve run into similar issues after updating to the 2022.11 release. My HA instance is a supervised version on a Raspbian Bullseye installation. Some of the issues were easy to resolve, here’s what I did:
- AppArmor
Make sure apparmor is installed (it was already for me) and enable it with a kernel boot parameter. E.g. if you are running HA on a Raspberry Pi add “apparmor=1 security=apparmor” to /boot/cmdline.txt - Systemd-Resolved
Enable the systemd-resolved service “systemctl enable systemd-resolved.service && systemctl start systemd-resolved”.
You can check if it’s working with e.g. “systemd-resolve home-assistant.io”. - CGroup version
I was using docker (unknowningly) with CGroup version 2, which is still not fully supported. Seemed to work fine, though. Nevertheless, you can force version 1 with a kernel parameter in /boot/cmdline.txt, add “systemd.unified_cgroup_hierarchy=0”.
You can also check your version with “grep cgroup /proc/mounts”, it will print “cgroup” for version 1 and “cgroup2” for version 2 in the first column.
After a reboot the corresponding warnings were gone. Still working on the Sytemd Journal issue…
Thomas
1 Like
here are my 2 cents worth that may help someone.
my system is bullseye with home assistant in a docker (pi3 running ssd)
i putty ssh into my system.
appamor wasnt running, docs say add to grub, that didnt work for me, it needed to be added to /boot/cmdline.txt
lsm=apparmor apparmor=1 security=apparmor
i also needed to set cggroup to use 1 by setting the unified_cgroup_hierarchy to 0
systemd.unified_cgroup_hierarchy=0
my cmdline.txt looks like this
lsm=apparmor apparmor=1 security=apparmor console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait systemd.unified_cgroup_hierarchy=0
you can edit yours
sudo vi /boot/cmdline.txt
press i to insert
make your changes then press esc
type :wq! to write and quit
sudo reboot
that fixed the cggroup and appamour issue for me
2 Likes