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.
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?
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
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.
