Avahi-daemon is no longer a pre-requisite for Superised. Resolved is but it’s not even enabled unless you manually enable it
I’m using Room-Assistant too so I modified the /etc/systemd/resolved.conf to disable the DNSStubListener.
But I noticed my systemd-resolved was disabled so I enabled it with:
systemctl enable systemd-resolved
One reboot later and the warning message is gone.
Thanks for the tip. 
1 Like
For anyone coming here in the future (like I just did)
The change to the supervised-installer comes from PR#163 (Oct 29, 2021), Release 1.02 (Nov 02, 2021) as mentioned by @DavidFW1960.
The test was introduced only in March 5 in the supervisor project, PR#3487 followed by documentation updates in the home-assistant.io site (PR#21922) at:
Systemd-Resolved - Home Assistant
(That’s 4+ months after the fact)
A new change in the supervisor installer script was introduced in PR #202 (March 22nd), on the heels of issue #197 (March 15th).
All part of the 1.1.1 release (March 23rd) of the supervised install (currently the latest)
Again, 4+ months after the original change.
It seems to me, that because there isn’t a meticulous tracking of features and changes like in the supervisor and core project, this ball was dropped, and because it’s unsupported, we get this thread instead, where we as a community make the bulk of the documentation for troubleshooting.
I hope this helps someone who gets here and wants to understand what happened.
Links:
1 Like
just had exactly the same fix on my system, which also for some reason lost its’ DNS resolver in the upgrade from 2022.4.0 to 2022.4.1 …
I find it interesting that the System logs now identify why I’m running “Unsupported” - given I knowingly installed these containers, is there some way I can get HA to ignore them when it health checks?
22-04-22 13:55:01 WARNING (MainThread) [supervisor.resolution.evaluations.base] Found unsupported images: {'alturismo/xteve', 'portainer/portainer-ce'} (more-info: https://www.home-assistant.io/more-info/unsupported/software)
1 Like
yeah no supervisor will crack the shits if you have any container it’s not controlling.
1 Like
Looks like I’ll just suck it up then… 
1 Like
@DavidFW1960 am getting the same error
Blockquote
mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
mDNS-IPv6: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
i don’t have any other mdns running as per my knowledge how to fix this warning .
Just a note to reiterate your frustrations @DavidFW1960 - these automatic supervisor updates have a habit of borking the supervised installation on my system with neither warning nor documentation. I try to behave well and keep up with the latest docs on how to stay “supported”, but it’s not enough. My system dies anyway because a supervisor update fails. The annoying thing is that sometimes, the full impact of a failed update might not show up until I next reboot my box, which can be days or weeks.
As described in this post, I’ve become pretty quick at rebuilding my installation - it seems to be the quickest way to bring a supervised installation back from the dead.
I’d love it if the wonderful HA team could put a bit more effort into notifying of upcoming changes to supervisor that might break supervised installations.
running the installation script again is probably the quickest way. I did this hundreds of times till a few months ago when my system started behaving again
Got this new unsupported warning on the latest HA version. Rerun systemd-resolved does not resolve the problem. Usually on the old template it will resolve by itself. So open for a suggestions. Thanks
if you have ANY docker container not installed/managed by supervisor you will be unsupported.
no… its just say systemd.resolved problem. I got this working fine on the previous HA version. Just the latest 2022.5.0 its broken
the latest supervisor is blackbanning any docker at all apart from HA.
True, although the original installation script has been replaced by the .deb package that is now offered to new users of supervised installation builds. The procedure I describe is equivalent to rerunning the installation script noting that the .deb package adds some complexity by introducing the /etc/hassio.json bootstrap file. It also pays to be nice to the systemd services along the way.
I learnt this the hard way. A few months back when my build died after an automated supervisor update, I tried to rerun the original installation script and found that it only partially resurrected my build. At that point, I discovered that the supervised installer (GitHub) had changed to the .deb package and at some point (who knows when) certain dependencies were introduced to the HA supervisor that only the .deb package satisfies.
I switched to the .deb package when they introduced it. They did change the pre-requisites removing avahi and adding resolved.service at some point. No biggie. You’re never going to break anything by running the install again.
Sorry I kind of missed this thread when it was posted or I would’ve said something sooner. The reason systemd-resolved is required is because all LLMNR and mDNS queries are delegated to it from containers managed by supervisor. There were a lot of issues around mdns names not working properly within HAOS such as this one and this one (there’s others if you want to search around in plugin-dns, supervisor, or esphome repos or just search around this forum). This was because the DNS plugin had some code that tried to handle mdns and frankly wasn’t very good at it. And LLMNR wasn’t handled at all.
Now we delegate all queries of those types to the host system itself. This has eliminated these issues as we use the native systemd-resolved service, as long as the host can resolve those names then anything managed by supervisor can as well. But because of this supervisor needs that service running otherwise anything managed by supervisor is completely unable to resolve mdns or llmnr names.
Unfortunately it looks like changing the supervised installer was missed as a part of that, sorry that created a hassle for you all. Hopefully this better explains why it occurred at least. I thought I had explained it in the unsupported help for that message but maybe it needs an update. If folks have a suggestion for how to make the unsupported systemd-resolved page more intuitive let me know or please feel free to submit a PR.
4 Likes
I appreciate your update @CentralCommand. Hearing the back story is always interesting and valuable. Missing stuff from time to time is normal and understandable - you and the HA team do a sensational job across a massive project with a huge user base. My HA installation is big and complex and it almost never breaks - it’s amazing.
My main beef is not that the docs aren’t good enough (we’d all love better docs, but let’s be reasonable). It is that there doesn’t seem to be any push comms (eg the blog / HA update notes) that are targeted to supervised installation users. For HA core, the quality of the release notes are just brilliant - deprecations, breaking changes, new features the whole shooting match - it’s fantastic.
It would be awesome if something similar could be done with supervised installation users in mind.
I’m not good at going back to the docs to find updates like the unsupported systemd-resolved note. Maybe that’s on me, but I’d love it if there was some kind of notification (like the main blog or the developers blog or something) that flagged changes to the requirements needed to stay “supported”, to the HA supervisor or to the supervised installer (which sometimes indirectly indicates things that need to change on already deployed supervised installs).
2 Likes
“You are never going to break anything by running the .deb install again…”
Quick question. I have several processes running on the host, and using HA Supervised on - Raspbian - not Debian. So my question is, would that change my OS to Debian and not ‘disturb’ my host processes (I have a bummer of a feeling you will just start laughing and say NO!!..)? (UGH)
No. . You can’t switch raspbian to debian like that.
Yeah I know it was a ridiculous question… ugh
1 Like