AFAIK, the OS side is pretty much off limits to customization.
I run my MariaDB database on another machine in my house and I love it being independent. I can completely wipe and replace my HA machine and the historical data is still intact… not that I do it that often but the two or three times I have done it, all the historical data just comes along without a second thought.
I love portainer! And actually, that was one of the “unsupported installation” items I had to resolve over the last few years because I run the portainer-agent on all my clients running docker. When I had it installed on my HA machine, eventually a release came along and HA complained that you can’t have your own containers running next to the HA containers. So, I had to remove it to be brought back under the “supported installation” umbrella.
It was nice to see the HA machine’s containers at a glance from my master portainer instance but, in all honesty, that was all I ever did with it. It’s not like I was using the portainer-agent on the HA machine to upgrade/maintain containers/images like I do with all my other machines. HA’s ecosystem takes care of all that on its own. So, in the end, I just removed the agent to get it back to “supported” status.
Looking back at my supervised installation experience (since 2018), I realize that every time it complained about “unsupported installation”, I did something that moved me slightly closer to HAOS operation anyway. The thing it wanted me to change had almost no impact to my usage. At this point, I’m glad I’m running HAOS, and fingers crossed, hopefully I don’t have any OS-level issues going forward.
I just finished my migration to Home Assistant Operating System, problem solved. I’m using a second Raspberry Pi to run docker containers that are not part of the Home Assistant eco-system.
Quite some work to figure out a good migration path, but moving to Home Assistant Operating System will save you a lot of maintenance in the future.
This is definitely new as I’ve been watching system-health quite a lot. For me, I started getting a systemd_journal with beta 7, beta 6 did not have this unhealthy situation. It may have started at a previous beta, but it certainly did not exist prior to any betas.
I fixed it pretty quickly by re-installing systemd-journal-remote & rerunning the .deb script. Running an addblocker though, so it took longer than I expected because it killed my dns server and I had to temporarily use another one for the script to succeed.
True that one is really new. Most don’t see that one yet as it comes from this pr which has currently only in the beta release of supervisor.
But I guess my point was that none of the unhealthy/unsupported reasons were added by core. Supervisor still manages that. The only new thing here is that core asks supervisor if it is unhealthy/unsupported and shows a repair per reason.
After updating I noticed a Supervisor update. That prompted an error and Repair entry saying…
Unsupported system - Systemd Journal issues
System is unsupported because Systemd Journal and/or the gateway service is missing, inactive or misconfigured . Use the link to learn more and how to fix this.
I’m running a Supervised Debian install (I’m not a Linux pro) for 2 years, rock solid, but following the link in the message, doesn’t help me. The commands aren’t recognized.
Maybe I installed systemd-journal-gatewayd and then ran the script, either way, install then turn the service on. I used the script to turn the service on in case there were extra options I didn’t know about.
root@ShuttleDomotica:~# apt-get install systemd-journal-remote -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
systemd-journal-remote is already the newest version (247.3-7+deb11u1).
The following packages were automatically installed and are no longer required:
libbotan-2-17 libtspi1 linux-image-5.10.0-17-amd64
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@ShuttleDomotica:~#
The second two commands did work fine.
After restart, the issue is not solved, I get one more issue with network manager.
The reinstall of HA supervised removes the connectivity check. I know how to solve that.
So I repaired that, restart the host. Still unsupported because the systemd journal.
Knocking my head against the table. Again a issue, that never has been there and is introduced by an HA update… …there goes my lazy evening
I have the same problem *System is unsupported because Systemd Journal and/or the gateway service is missing, inactive or misconfigured * I’m using Debian 11 supervised install
I did
sudo apt install systemd-journal-remote
when I run
sudo systemctl status systemd-journal-gatewayd.service
I get this
● systemd-journal-gatewayd.service - Journal Gateway Service
Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
Active: active (running) since Thu 2022-11-03 19:16:50 CET; 8min ago
TriggeredBy: ● systemd-journal-gatewayd.socket
Docs: man:systemd-journal-gatewayd(8)
Main PID: 18663 (systemd-journal)
Tasks: 2 (limit: 9334)
Memory: 3.9M
CGroup: /system.slice/systemd-journal-gatewayd.service
└─18663 /lib/systemd/systemd-journal-gatewayd
Nov 03 19:16:50 homeassistant systemd[1]: Started Journal Gateway Service
but error in home doesnt go away. In supervisor I have this
22-11-03 19:20:54 ERROR (MainThread) [supervisor.host.logs] No systemd-journal-gatewayd Unix socket available
