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?
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"
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.
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.
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.
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.
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.
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.
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…
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
This is not true in my case… My system was healthy and supported Rpi 4 with Debian everything up 2 date. But after update it complaint about systems journal stuff
I thought the same but just downgrade, you’ll see the issue is still there. It’s coming from the most recent supervisor. The health page is buried, so you don’t see the issue unless you go to that page. All that changed 2022.11 was that they added these items to the repair page. So now you’re just getting notifications of the issues that already existed.
As for the other issue, I’m fairly certain people aren’t reading the errors and responses of the calls when using the documents. Iirc, I had to perform some extra actions because the CLI told me to do so. I had to fix a few installs and update a few Libs. If you pay attention to the command responses you should be good.
