It’s always the user his fault… Yeah, we all did overlook that. But still, there are changes made, which caused this becoming an issue, which was not there before the change.
I know, you are helping out, and really appreciate your effort and your time. It’s just, that the user always gets a cold shower, when overlooking a change, he has not made him self… You could be a bit easier on that.
If you see how people are coming here claiming 2022.11 caused the issue, I’m just clearing up that miss conception. It was caused by the supervisor update about 3-4 weeks ago. You may have missed it, but the developer replied directly to me in the release thread with those details and backed it up with PRs.
You for some reason think that this is a knock towards the user, but it’s just really clearing up a miss conception that’s occurred multiple times in this thread.
Not to mention, a few of the miss conceptions are unnecessarily hostile…
It IS the users fault here that is what petro is trying to explain
I think you guys and girls should stop complaining and start contributing. You are using this awesome software probably for free because you are running supervised… I am doing that , too and I am grateful that the team tries to make this still possible.
This project is so awesome… Reading through these comments makes me sad as a dev… Do you know how much effort it takes to maintain and develop a project in that scale?
Sorry, I don’t want to offend anyone but this just had to come out.
Addressing the thread’s problem: I had the repair suggestion, too. As explained before this was an issue also in previous versions… My personal solution for this repair suggestion is to ignore it, because the system runs as smooth as always. The only thing that is not working for me is showing the host system logs in homeassistant. But as I am running supervised, I can just read the logs myself, if I want to.
It’s not the users fault, but correcting it is in the user hands. Every new feature that’s added to the supervisor will require all supervised users to fix some unhealthy status. Any time a new feature requires a new os dependency, we will get an unhealthy status. That’s just par for the course. If people don’t want to deal with that, they should be running hassos instead of supervised.
Please, stop with assumptions like that. How good your intentions may be, assumptions are the mother of all fuck ups.
In this case you, even if maybe not mentioned hard, are making me just even more mad.
Because you are talking to a years long member, daily spending time on this forum helping others out, contributing on GitHub, contributing with language translations of HA, contributing with Nabu Casa subscription and so on.
This is again a nice example, how you can hurt people without even noticing.
Think, before you write…
In gnu/linux world complaining = contributing.
Without a complaining no one will know that there is a problem/bug and it will never be resolved.
So if you want to contribute please do complain.
Sorry if I hurt you, that was not my intention. Although I replied to your post, I was not adressing you personally, but the majority of people in here with unconstructive critical comments, as if the dev team would have any obligations. I used the reply to have a context - sorry if that was not clear. I really tried to not be toxic
I do not agree that every form of complaining is equal to contributing.
What was my intention though is to disrupt this thread so the whining would stop and the solutions can stand out again.
Well, I appreciate the fact, you are ready to say sorry immediately after seeing, that your words had other effect, than intended. That makes you a hero in my eyes!
I just wish, more people around here will be ready to do so…
Ah yes, I fell into .1 .2 problem myself. Thanks for pointing out. That’s why we have version numbers in package filenames HA should fix homeassistant-supervised.deb naming, and also signal the updates to os-agent and supervised in the GUI - only yesterday I found out how much lagging have I been in updates. GUI repair message wasn’t particularily imformative, it didn’t say the package versions were outdated.
I believe the supervised installer fixed a few things like socket location. For the guys trying to start systemd-journal-gatewayd.service - it is triggered by a socket systemd-journal-gatewayd.socket, which by default is disabled and stopped. That’s how it is for me now:
root@automat:~# systemctl status systemd-journal-gatewayd.socket
● systemd-journal-gatewayd.socket - Journal Gateway Service Socket
Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.socket; enabled; preset: disabled)
Active: active (listening) since Sat 2022-11-05 14:31:17 CET; 10min ago
Until: Sat 2022-11-05 14:31:17 CET; 10min ago
Triggers: ● systemd-journal-gatewayd.service
Docs: man:systemd-journal-gatewayd(8)
Listen: /run/systemd-journal-gatewayd.sock (Stream)
CGroup: /system.slice/systemd-journal-gatewayd.socket
Nov 05 14:31:17 automat systemd[1]: Listening on Journal Gateway Service Socket.
root@automat:~# systemctl status systemd-journal-gatewayd.service
○ systemd-journal-gatewayd.service - Journal Gateway Service
Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.service; indirect; preset: disabled)
Active: inactive (dead)
TriggeredBy: ● systemd-journal-gatewayd.socket
Docs: man:systemd-journal-gatewayd(8)
PS. An afterthought - may be a smart idea to set up a small DEB repository for supervised packages so that they can get updated by APT
I completely agree! Stop arguing! Start contributing! petro is just trying to help. It’s time to get this back on the right track. Complaining doesn’t help, but constructive input will. Thanks for all your help and support petro.
I upgraded a second system and have further thoughts on upgrade process.
First some background: that was an older supervised install which was probably set up using install scripts, somewhere around 2021, there was no homeassistant_supervised.deb at that point. As a sysadmin I did what I usually do - moved my docker data dir and hassio config into /srv structure.
Now comes the DEB installer package. Without question it moved my docker daemon config aside (dpkg-divert) and put in a default one, effectively causing docker to start blank. This would cause addons to loose their volume contents. But it has also reverted to /usr/share/hassio as HA data location and that caused my installation to basically start from scratch. I had to change data path in /etc/hassio.json . Once I sorted these things out, I restarted Docker, HA services and it was back up.
As a dirty workaround for the future I added symlinks in default locations which lead to correct data. In CentOS this wouldn’t work because of selinux but in Debian, I guess it’s fine.
thanks for the info @p0wertiger; I’m sure this will help others! I had handled about four or five of these “unsupported installation” messages over the last few years and with this final “forced migration” to /usr/share/hassio I finally bit the bullet and moved to HAOS. The transition was pretty clean since I had just made a full backup of my setup a few days ago, hopefully, now I don’t have to worry about that message popping up in the future.
I would have gone with HAOS but I can see two issues: MariaDB and additional containers on the same machine. Haven’t tried HAOS so I don’t know if you can actually access the base OS and set up any software by yourself?
With MariaDB there’s a problem with official add-on - it does not allow you to change too much in its configuration which for me is for example InnoDB buffer size.
About other containers, there’s software that I’d love to run one day that’s not in the addons. I think you can go with Portainer to set these up. The other way would be packaging them up in a custom addon A task for long lazy winter evenings.
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.
A task for long lazy winter evenings.