So another day, another stink bomb hidden in a supervised install.
Now everything seems to be working and there are no unexpected errors in Supervisor. I have never touched systemd-resolved.service. Do I need to enable this service or is it something I can ignore?
Just as an aside in recent months, any docker or supervisor update has forced me to reinstall HA but with a recent supervisor/dns update, everything is working perfectly again.
The docs aren’t all that helpful. Systemd-Resolved - Home Assistant
I wonder if I should enable it and start it and wonder why this happened anyway?
For what it’s worth, I tried enabling it and then wasn’t able to access HA after that. So I disabled it again and just ignored the error, just like my ‘unsupported software detected’ message
Edit: after reading the other comments I realized I had to start it too, and only just enabled it lol.
I enabled and started it but still see the error. Running status says it’s running. It also says
david@debian:~$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-03-11 13:32:01 AEDT; 5min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 138964 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 9004)
Memory: 4.7M
CPU: 1.044s
CGroup: /system.slice/systemd-resolved.service
└─138964 /lib/systemd/systemd-resolved
Mar 11 13:32:01 debian systemd[1]: Starting Network Name Resolution...
Mar 11 13:32:01 debian systemd-resolved[138964]: Positive Trust Anchors:
Mar 11 13:32:01 debian systemd-resolved[138964]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Mar 11 13:32:01 debian systemd-resolved[138964]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18>
Mar 11 13:32:01 debian systemd-resolved[138964]: Using system hostname 'debian'.
Mar 11 13:32:01 debian systemd[1]: Started Network Name Resolution.
Mar 11 13:32:01 debian systemd-resolved[138964]: mDNS-IPv4: There appears to be another mDNS responder running, or previously syste>
Mar 11 13:32:01 debian systemd-resolved[138964]: mDNS-IPv6: There appears to be another mDNS responder running, or previously syste>
No idea what is going on. Maybe I should just disable it again and add it to the list of stuff HA thinks is broken but isn’t
Even though I had reloaded supervisor it didn’t clear systemd-resolved error until I restarted so now I am back to just ignored job conditions (because I set it to ignore unhealthy) and Unsupported software detected because I have the temerity to run other non HA containers. I’m eagerly awaiting the next unscheduled bastardry with great anticipation.
So I see from here Releases · home-assistant/supervised-installer · GitHub that they removed the previous requirement for avahi-daemon in version 1.02 released 3 Nov 2021. It would have been nice if they informed us of this change then. But it appears only now are they telling up there is an issue if systemd-resolvd isn’t installed.
I suppose this is probably the only way they can warn us of an issue in a current installation however I have reinstalled supervised 10’s of times since November as HA would not start/come back after a reboot or a docker update or a supervisor update. I never saw a warning about an issue (when I re-ran the installation package) with this till yesterday. It might be a good idea when a requirement changes or there is a breaking change like this to issue a blog post? Seems like a lot of very competent experienced users didn’t know they had this issue either until I posted this yesterday.
As long as there is no problem, there is little need to go see if your installation is still supported. It is only if I read something on the forum that alarms me that I go see if I’m affected.
I know supervisor auto-updates, but I just intent to look at the supervisor tab each time before or after the update, so I don’t forget to regularly watch that page Otherwise I will forget.
So, I am also suddenly unsupported for this same reason. I have tried the above and it has not fixed my condition.
“sudo systemctl status avahi” results in “Unit avahi.services could not be found”, so not running. I did go ahead and disable the DNSStubListener and rebooted the host with no change.
This is the only complaint in my supervisor log regarding d-bus.
22-03-16 09:57:00 WARNING (MainThread) [supervisor.dbus.manager] Can't load dbus interface de.pengutronix.rauc: The name de.pengutronix.rauc was not provided by any .service files
I do have a line of negative trust anchors when I check with “systemctl status systemd-resolved”. I am unable to copy them here because I do not have ssh access into the base OS, only console.
I am running Debian 5.10.103-1
I finally got mine to resolve by flushing cache and rebooting the system.
Otherwise I will forget.
