If you wanted to, you could post your /etc/resolv.conf and /etc/systemd/resolved.conf here. I don’t know if there might be a configuration directory option for systemd-resolved, so keep an eye out for a potential directory like /etc/systemd/resolved.d that might have the configs instead.
- 0 Posts
- 28 Comments
Joined 2 years ago
Cake day: July 1st, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Did you ever come back to this and figure it out? My curiosity is killing me :)
And I think it’s probably not in resolv.conf, that’s a stub that kind of redirects things to systemd-resolved. So I think it’s in the forwarder config of that.
Be careful, I was just looking over the Arch docs I linked you to, and I think the configs have changed substantially in the last few months. There’s a good chance that the configs in Mint look substantially different.
Agreed, though I don’t think they disabled systemd-resolved, because it still works using 127.0.0.53 when they’re connected to the VPN. So the daemon must be running, unless Mullvad itself has a DNS forwarder using the same loopback. I suspect they either hard coded some upstream DNS server for Mullvad, because Mullvad might not have supported systemd-resolved yet. Or maybe they set a permission on the configs, and something changed with the user context of Mullvad processes.
Interesting that it works when the VPN is connected, though. I also believe that systemd-resolved is installed on just about any system using systemd, but often isn’t enabled, without problem. Enabling it would generally involve a resolv.conf symlink and a config, so maybe that config was hijacked by Mullvad (or OP configuring Mullvad), and there’s no upstream DNS server available when the VPN isn’t connected.
I missed that it’s Linux Mint in the original post, and it looks like Mint has started using systemd-resolved. The Arch wiki might be useful to OP on how things are configured:
Ok, so something setup 127.0.0.53 as your DNS server, and isn’t removing it correctly. I think it’s safe to say it’s Mullvad, since it works using that DNS server IP when connected. Is that IP in your resolv.conf, or is resolv.conf maybe a stub, and you’re using systemd-resolved?
Ok, so does the VPN bring it’s own DNS? Some VPNs do, so it may explain why everything suddenly works fine when you connect.
When not connected to VPN, are you able to dig or nslookup internet names? Local names? A server timeout will be very different from an nxdomain or an empty SOA, in the response.
Are you able to telnet to a public web server on TCP/443?
One thought I’m having is, maybe at some point you set a static IP on your wifi interface, but screwed up the subnetting.
Have you ever messed with network manager or systemd-resolved internal settings, maybe trying to setup multicast DNS or caching?
Hopefully they plan to stabilize what they see as core functionality, and then build out features. Some people won’t consider it ready until this or that feature is added, but many of us who just want a WM+ can start using it once it’s relatively stable.
1·8 months agoOk, but you’re still dealing with the guest desktop as a windowed container. Unity mode in VMware presents individual windows to the desktop environment, not the entire desktop.
Things like Distrobox will obviously be better for most Linux on Linux workloads, but for BSD or Windows, it’s pretty damned cool.
But they don’t break windows from within the guest, into the host desktop environment. You see the entire desktop as a container.
It really depends, but generally, I want to use as much Linux as possible, and for me a bigger part of that is the UI than the hypervisor.
Microsoft pays extra attention to Ubuntu LTS and RHEL. Not my first choices, but in particular you’ll see stuff like AAD auth on Azure VPN supported on Ubuntu LTS. There will also be some work going into proper Intune support, if that matters.
I would prefer Fedora or Debian for a more stable environment, and use Arch at home, but we have to keep interoperability in mind sometimes.
Another thing to look into, and I really hate to since Broadcom bought them, but you can run Windows inside VMWare, and use unity mode to break individual windows out into your DE. Beware of the new licensing.
What’s your use case that OSMC and LibreELEC don’t work? I think those are going to be common recommendations, so knowing why they don’t suit you would be helpful.
I was surprised to see it doesn’t suck anymore, I’m using it with my mailbox.org and old gmail account. The state of Wayland native email clients isn’t great, I’m really not sure what I’m going to do when I eventually switch to Cosmic.
A couple others, if MPD looks appealing, are Navidrome and Mopidy.
Yeah, I’m with you. 2001 and DDR… there’s something else going on with the failure to boot. I don’t think the Pentium 3 ever supported DDR, so this is probably a Pentium 4. If truly a model released in 2001, it would be Willamette, but that required RDRAM. DDR support was introduced with Northwood in 2002. On the other hand, it could be the P4 that was new in 2004, Prescott, and the 2001 statement comes from the first year the P4 was released.
Same here. I feel like Sid is there to catch problems, so devs and maintainers use it as such. Arch aims to be stable, though obviously not to the degree of Debian Stable, and so devs and maintainers aim for that. If one wants the Arch equivalent to Sid, there’s the testing repo, but there’s much less of a delta between stable and testing in Arch, so there isn’t much point unless you actually want to help test.
I’ve been wanting to find an alternative to Thinkpads since Lenovo bought them, but despite them not being what they used to be, I just haven’t been happy with any alternatives. I’m hopeful for Framework improving on their modularity, and the System76 in-house design that’s in the works has me intrigued.
Right now I’m looking forward to their eventual redesign of the Z series. I doubt they’ll do it, but I’d love a light workstation class version of the Z16, with slightly higher end graphics, and a vapor chamber. I’m also hopeful that they work on Linux support for their ARM offerings, and bring back the X13s that they offered with Snapdragon 8 a couple years back.
Ok, so the resolv.conf is being used to put systemd-resolved in the forwarding path, with it listening on 127.0.0.53. That’s how Mint does things, so don’t touch that file.
Your resolved.conf has no DNS servers or fallback DNS servers configured, so it should just use the DNS servers handed out by DHCP. Either your DHCP servers isn’t handing out a DNS server (unlikely, since other machines work), NetworkManager was configured to not use DHCP DNS servers, or you’re hitting some bug causing the same. I suspect you may have configured NetworkManager for this, maybe it was overriding the VPN DNS. Or maybe you accidentally set the NetworkManager DNS backend to dnsmasq, when it should be systemd-resolved in Mint.
You could try uncommenting that FallbackDNS line and adding a couple space separated DNS servers, maybe your router IP. Mine looks like this:
#DNS= FallbackDNS=1.1.1.1 1.0.0.1 #Domains=
That will hopefully allow VPN DNS to work when it’s connected, and fall back to other DNS servers when not. If not, we could try taking a look at NetworkManager configs. It’s been a bit, I use systemd-networkd now, but I could spin up a VM.