While you're here, please consider supporting GamingOnLinux on:
Reward Tiers:
Patreon. Plain Donations: 
PayPal.
This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Reward Tiers:
Patreon. Plain Donations: PayPal.This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register
- Linaro reveal they're collaborating with Valve for the Steam Frame
- Steam Frame and Steam Machine will be another good boost for Flatpaks and desktop Linux overall too
- Canonical call for testing their Steam gaming Snap for Arm Linux
- Valve update the Steam Workshop to allow mods to support multiple game versions
- SteamOS 3.7.20 adds the ntsync driver to help improve some game performance
- > See more over 30 days here
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck- Welcome back to the GamingOnLinux Forum
- grigi - Will you buy the new Steam Machine?
- grigi - Game recommendation?
- JSVRamirez - Weekend Players' Club 2026-01-09
- Minoscereb - Will you buy the new Steam Frame?
- Arehandoro - See more posts
So the issue is the DNS resolver, that is the piece of software that turns www.gamingonlinux.com (the URL) into 69.16.242.65 (the IP address) and for some reason your DNS resolver (systemd-resolved) in Pop_OS! are having issues when trying to go over the Wi-Fi card instead of over the wired card.
Luckily you can see the log from systemd-resolved with:
f.ultra@Sineya:~/$ journalctl -u systemd-resolved.service --since today
mar 21 17:54:18 Sineya systemd[1]: Starting Network Name Resolution...
mar 21 17:54:19 Sineya systemd-resolved[1126]: Positive Trust Anchors:
mar 21 17:54:19 Sineya systemd-resolved[1126]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
mar 21 17:54:19 Sineya systemd-resolved[1126]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.>
mar 21 17:54:19 Sineya systemd-resolved[1126]: Using system hostname 'Sineya'.
mar 21 17:54:19 Sineya systemd[1]: Started Network Name Resolution.
f.ultra@Sineya:~/$
I added "--since today" to the journalctl so you only will see logs from today and not have to scroll through days and days of logs. Hopefully it will show what is going wrong when you connect over Wi-Fi. One tip here is to open a terminal and simply do a "sudo journalctl -f" this will make the journal log everything that happens from now on to the screen as it happens so you can then see if anything suspicious are being logged when you switch from wired to Wi-Fi and back and forth.
Last edited by F.Ultra on 21 Mar 2022 at 8:33 pm UTC
The "search Home" option makes the dns-resolver in glibc try both host and host.Home when trying to resolve hostnames. This is useful if you say work for company x so you have to e.g ssh to mail.x.com or server1.x.com then you can add a "search x.com" and now you only need to ssh mail and ssh server1. That feature I use extensively.
View PC info
If I use either Google or Cloudflare's IP address under the 'DNS' section (with 'Automatic' disabled), there is no change... I did not enter anything under the 'ROutes' section, which has 'Address', 'Netmask', 'Gateway' and 'Metric' fields.
Here's the respective output using my Wi-Fi (wireless) connection:
https://pastebin.com/tQNayHwp
And with my ethernet (wired) connection:
https://pastebin.com/UpDwB1iU
Oh, I like this command... This will come in super handy in the future!
Anyway, here's the output of my Wi-Fi (wireless) connection):
https://pastebin.com/DrhrWMNj
And here's the output over my ethernet (physical) connection:
https://pastebin.com/q6tn00Nq
This last output will probably be of most help, because I changed back and forth between my Wi-Fi (wireless) and ethernet (physical) connection a couple of times...
Does connecting to WiFi and then running
systemctl restart systemd-resolvedresolve things?If restating the resolver above doesn't work then I would try to simply disable the resolver and just use the router or google as the resolver. Found a full step by step guide here: [https://bobcares.com/blog/disable-systemd-resolved-in-ubuntu/](https://bobcares.com/blog/disable-systemd-resolved-in-ubuntu/) , basically one disables the systemd-resolver deamon (disable simply means that it won't be launched at boot, later you can enable it again so this will not botch your system). Next they remove the /etc/resolv.conf file which is the file that tells the machine where to look for a DNS resolver, by default this is linked to a runtime generated file by systemd-resolved so by stopping that deamon, removing the file and restarting NetworkManager, NetworkManager will see that the file is not there and create it again but this time linked to NetworkManager. Likewise to get back one simply deletes the file again and then starts systemd-resolved and everything should be back to how it was before.
View PC info
It's uh, working. For no apparent reason, it's working since I made my post this morning. 😕
I didn't apply any updates this morning or anything (though there are some there waiting to apply, according to the Software Center), just ran the Terminal commands as noted above; but when I went to run the (Terminal) command in your post I'm quoting, I was surprised to find that my Internet connection is running perfectly!
How bizarre.
It should be interesting to see if this continues into the night / into tomorrow or if I experience the same problem tomorrow.
Whilst I'm keeping an eye on it, I'm going to have a read of that bug report and see what it contains... Ubuntu "Jammy Jellyfish" is about to drop - which means Pop!_OS 22.04 also should not be too far away - and one would hope that a bug like this has been addressed in the upcoming upgrade.
Annnd it's dead.
I get up to Step 3, but I can't seem to find the 'resolv.conf' file... It wasn't in the 'NetworkManager' directory. If I go to /etc/, there is a 'resolveconf' directory, which contains a 'resol.conf.d' under it; that directory in turn only contains the files 'base', head', original' and 'tail' in it.
If I skip Step 3,
sudo service network-manager restartgives me asudo: unable to resolve host admin-vaio-tap20: Temporary failure in name resolutionerror.---
Well, well, well... Look what just popped-up on Reddit:
https://www.reddit.com/r/pop_os/comments/tl36i8/no_wifi_after_upgrade/
That looks awfully similar to my issue.
Whilst networking is not my strong-point, I think @whizse and @F.Ultra and are probably onto something with their theory that this is a bug.
I don't have a Reddit account (the few social media accounts I actually have are used exclusively for work purposes - and I'd get rid of them in a heartbeat if I could!); but if it is a bug, more eyes on the issue is a great thing, because it means a fix might not be too far away.
That's not to say you guys (and girls?) haven't been helpful. The Gaming on Linux Community has (unsurprisingly) been extremely helpful thus far and as somebody that has used Ubuntu since 4.10, I can honestly say that the Gaming on Linux Community reminds me of what the (official) Ubuntu Forums used to be like... But we're not really making any progress here, so hopefully this gets some more people to pay attention to what appears to be a bug.
Of course, if it turns out to be confirmed as a bug or some update fixes it, I will definitely be sure to post back here...
Last edited by Cyba.Cowboy on 24 Mar 2022 at 5:44 am UTC
lrwxrwxrwx 1 root root 37 jan 11 2019 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
But if it's missing it's easy to just create a new one with "sudo nano /etc/resolv.conf" and just insert this single line:
nameserver 8.8.8.8
to force the whole system to always ask the google dns server for every single resolving. Just don't forget to rm this file before restarting systemd-resolved when you want to restore everything back.