I experienced a similar issue recently. I had openresolv installed as the only resolver and with the systemd 257 update all the sudden systemd-resolved got installed additionally. This resulted in no dns resolving.
https://forum.manjaro.org/t/updating-systemd-to-257-1-resulted-in-no-internet-connection/172158
No. That did not happen - systemd-resolved is provided as part of systemd.
1 Like
For those who have systemd-resolved enabled intentionally and stumble on this thread - there is an issue in version 257 (currently available across all branches) - systemd-257: resolved needs manual restart after boot: Failed to get link data for 4: Unknown object '/org/freedesktop/resolve1/link/_34' · Issue #35654 · systemd/systemd · GitHub . Workaround is to restart systemd-resolved after every boot.
I have been using systemd-resolved for years - all my systems are configured to use systemd-resolved and none of them fails.
There must be some other factor involved.
That’s possible, I started using resolved after seeing this post [root tip] [How To] NordVPN on Manjaro 
and do this across all the systems I own.
The issue did not exist in versions prior to 257 (I rolled back as I use btrfs to test). All of my debugging efforts failed (disable nordvpn etc.) and there is nothing in the journal.
The only place where I get an error message is on running resolvectl status on boot - Failed to get link data for 4: Unknown object '/org/freedesktop/resolve1/link/_34', which matches the regression report that I linked above.
If you have any ideas, I’m happy to test them with you.
(I initially suspected some sort of conflict between kde-connectd and systemd which apparently now has mdns functionality? Or perhaps it always did and I did not pay attention).
I’ve also disabled mdns via systemd by a drop in file in /etc/systemd/resolved.conf.d/. That did not help.
systemd is 257.2-2 on all branches with 257.3 in Arch stable.
$ mbn info systemd -q | grep -e 'Branch' -e 'Version'
Branch : archlinux
Version : 257.3-1
Branch : unstable
Version : 257.2-2
Branch : testing
Version : 257.2-2
Branch : stable
Version : 257.2-2
I have not run into the issue and the bugreport linked is for systemd 257.1 - and since the issue doesn’t appear with the repo version 257.2 and to my knowledge not even consistent - it is difficult to deduce and has most likely been fixed.
mdns is an avahi micro dns thing - I fail to see the connection … could you please clarify the connection?
//EDIT
Strange - very strange - my journal contains entries dating back to late november 2024 - no entries match when querying the journal
journalctl | grep -e 'Failed to get link data for'
If I search on the unit - I have a rare occurence of a conflict - perhaps what you are referring to with relation to mDNS.
journalctl -u systemd-resolved
Nothing I’d worry about though …
jan 20 07:23:31 tiger systemd-resolved[28587]: mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstandi>
If I search on the unit - I have a rare occurence of a conflict - perhaps what you are referring to with relation to mDNS.
Yes, I saw that dns resolution was not working after the update to 257, searched through forum posts, did not notice others complain about it and went looking at the logs. Saw exactly the same message that you have in my logs and querying the port (5335?) showed me that kde-connectd was running there. Made the change hoping that it was the issue.
Thanks for your post, it motivated me to go back to looking at a way to solve it. I run pihole locally and decided to add an dropin override to force resolved to start after pihole.
#/etc/systemd/system/systemd-resolved.service.d/override.conf
[Unit]
After=pihole-FTL.service
Wants=pihole-FTL.service
I don’t think this has anything to do with the interaction of pihole and resolved, but some sort of race condition between some components of systemd. Forcing resolved to start later seems to “resolve” the issue for me.
Edit:
Strange - very strange - my journal contains entries dating back to late november 2024 - no entries match when querying the journal
Yes, unfortunately the journal does not contain this error. It only shows up when you run resolvctl status after boot. A simple systemctl restart systemd-resolved cleared things up for me making me suspect a race condition.
Yes, it did. Systemd-resolved became activated and became enabled. With the update. This is what I mean by “installed additionally” → additionally to openresolv DNS resolving functionality.
I did not mean installed as a package.
Why is my answer to @birdibird now all the sudden a support thread?
Yes, I’m having this issue too on my manjaro machine.