Hi All,
Fedora 34 Xfce 4.14
I am in real trouble here. My business is most shutdown over this. My browsers, Thunderbird, and ping won't work. Nothing that used the Internet worked. Well, almost.
I can not find anything about this issue on Google or Duck Duck Go.
After installing Tor yesterday, all was well. Tor Browser worked well and all my other browsers and eMail continued to work along side it. I was happy. But that was about to change.
After booting up this morning, only Tor Browser and Brave in Tor mode worked.
ALL my qemu-kvm virtual machines work perfectly (I am writing this from one of them and I despise web mail).
`host xxxx` worked. $ host gbis.com gbis.com has address 207.228.37.200 gbis.com mail is handled by 0 mx.greatbasin.net.
`ping host-name` did not $ ping gbis.com ping: gbis.com: Name or service not known
If I look up the IP address with "host" and used that instead, `ping IP` worked. All my browser also worked with the IP address. "traceroute" only works with IP as well.
So I removed Tor: $ rm -rf ./.local/share/torbrowser/tbb/x86_64/tor-browser_en-US # dnf remove tor torbrowser-launcher torsocks $ rm -rf ./.local/share/torbrowser $ rm -rf ./.cache/torbrowser $ rm -rf ./.config/torbrowser # rm -rf /etc/tor
Reboot. No change.
What the <expletive deleted> is going on? And how do I recover my machine?
Many thanks, -T
On 6/25/21 3:20 PM, toddandmargo via users wrote:
Hi All,
Fedora 34 Xfce 4.14
I am in real trouble here. My business is most shutdown over this. My browsers, Thunderbird, and ping won't work. Nothing that used the Internet worked. Well, almost.
I can not find anything about this issue on Google or Duck Duck Go.
After installing Tor yesterday, all was well. Tor Browser worked well and all my other browsers and eMail continued to work along side it. I was happy. But that was about to change.
After booting up this morning, only Tor Browser and Brave in Tor mode worked.
ALL my qemu-kvm virtual machines work perfectly (I am writing this from one of them and I despise web mail).
`host xxxx` worked. $ host gbis.com gbis.com has address 207.228.37.200 gbis.com mail is handled by 0 mx.greatbasin.net.
`ping host-name` did not $ ping gbis.com ping: gbis.com: Name or service not known
hi,
I don't use tor nor brave, but try booting with the previous kernel.
I updated to kernel 5.12.12 and has the same symptoms, booting with the old kernel fixed the problems
regards
On 6/25/21 1:50 PM, Gabriel Ramirez wrote:
On 6/25/21 3:20 PM, toddandmargo via users wrote:
Hi All,
Fedora 34 Xfce 4.14
I am in real trouble here. My business is most shutdown over this. My browsers, Thunderbird, and ping won't work. Nothing that used the Internet worked. Well, almost.
I can not find anything about this issue on Google or Duck Duck Go.
After installing Tor yesterday, all was well. Tor Browser worked well and all my other browsers and eMail continued to work along side it. I was happy. But that was about to change.
After booting up this morning, only Tor Browser and Brave in Tor mode worked.
ALL my qemu-kvm virtual machines work perfectly (I am writing this from one of them and I despise web mail).
`host xxxx` worked. $ host gbis.com gbis.com has address 207.228.37.200 gbis.com mail is handled by 0 mx.greatbasin.net.
`ping host-name` did not $ ping gbis.com ping: gbis.com: Name or service not known
hi,
I don't use tor nor brave, but try booting with the previous kernel.
I updated to kernel 5.12.12 and has the same symptoms, booting with the old kernel fixed the problems
regards
Hi Gabriel,
That did the trick. Tor was falsely accused! Thank you!!!!
-T
I removed 5.12.12-300 and am running on perfectly on 5.12.11-300
On 6/25/21 2:07 PM, ToddAndMargo via users wrote:
On 6/25/21 1:50 PM, Gabriel Ramirez wrote:
On 6/25/21 3:20 PM, toddandmargo via users wrote:
`host xxxx` worked. $ host gbis.com gbis.com has address 207.228.37.200 gbis.com mail is handled by 0 mx.greatbasin.net.
`ping host-name` did not $ ping gbis.com ping: gbis.com: Name or service not known
hi,
I don't use tor nor brave, but try booting with the previous kernel.
I updated to kernel 5.12.12 and has the same symptoms, booting with the old kernel fixed the problems
regards
Hi Gabriel,
That did the trick. Tor was falsely accused! Thank you!!!!
-T
I removed 5.12.12-300 and am running on perfectly on 5.12.11-300
I just posted:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
On 26/06/2021 05:33, Tom Horsley wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
What I find equally weird is that in the BZ he states that his qemu VM's are working just fine. If the VM's are working and they have been updated to the same kernel then what would be the difference? A proxy setting perhaps?
On 6/25/21 2:45 PM, Ed Greshko wrote:
On 26/06/2021 05:33, Tom Horsley wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
What I find equally weird is that in the BZ he states that his qemu VM's are working just fine. If the VM's are working and they have been updated to the same kernel then what would be the difference? A proxy setting perhaps?
More funny! The VM's are using my caching name server ON MY HOST !!!!
On 26/06/2021 06:23, ToddAndMargo via users wrote:
On 6/25/21 2:45 PM, Ed Greshko wrote:
On 26/06/2021 05:33, Tom Horsley wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
What I find equally weird is that in the BZ he states that his qemu VM's are working just fine. If the VM's are working and they have been updated to the same kernel then what would be the difference? A proxy setting perhaps?
More funny! The VM's are using my caching name server ON MY HOST !!!!
Sure, that's pretty much the default if your VM's are using DHCP.
The one thing to recall is, and this is from memory, is that "host" and "dig" don't make use of the system's resolver library. They query dns servers directly. So, another thing to check is if the /etc/nsswitch.conf on the VM's are the same as the host.
On 6/25/21 3:33 PM, Ed Greshko wrote:
On 26/06/2021 06:23, ToddAndMargo via users wrote:
On 6/25/21 2:45 PM, Ed Greshko wrote:
On 26/06/2021 05:33, Tom Horsley wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
What I find equally weird is that in the BZ he states that his qemu VM's are working just fine. If the VM's are working and they have been updated to the same kernel then what would be the difference? A proxy setting perhaps?
More funny! The VM's are using my caching name server ON MY HOST !!!!
Sure, that's pretty much the default if your VM's are using DHCP.
The one thing to recall is, and this is from memory, is that "host" and "dig" don't make use of the system's resolver library. They query dns servers directly. So, another thing to check is if the /etc/nsswitch.conf on the VM's are the same as the host.
Dig did not work either.
function GetPublicIP () { local WIP=$(dig +short myip.opendns.com @resolver1.opendns.com) # echo "WIP = <$WIP>" > "/dev/tty" if [[ "$WIP" == *"not found"* || "$WIP" == *"no servers could be reached"* ]]; then WIP="Not Found" fi
echo $WIP }
On 26/06/2021 07:25, ToddAndMargo via users wrote:
On 6/25/21 3:33 PM, Ed Greshko wrote:
On 26/06/2021 06:23, ToddAndMargo via users wrote:
On 6/25/21 2:45 PM, Ed Greshko wrote:
On 26/06/2021 05:33, Tom Horsley wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
What I find equally weird is that in the BZ he states that his qemu VM's are working just fine. If the VM's are working and they have been updated to the same kernel then what would be the difference? A proxy setting perhaps?
More funny! The VM's are using my caching name server ON MY HOST !!!!
Sure, that's pretty much the default if your VM's are using DHCP.
The one thing to recall is, and this is from memory, is that "host" and "dig" don't make use of the system's resolver library. They query dns servers directly. So, another thing to check is if the /etc/nsswitch.conf on the VM's are the same as the host.
Dig did not work either.
function GetPublicIP () { local WIP=$(dig +short myip.opendns.com @resolver1.opendns.com) # echo "WIP = <$WIP>" > "/dev/tty" if [[ "$WIP" == *"not found"* || "$WIP" == *"no servers could be reached"* ]]; then WIP="Not Found" fi
echo $WIP } _______________________________________________
I don't know were that snippet comes from. But, the "Not found" may be due to dig using the system's resolver to first get the IP of resolver1.opendns.com. So, I would have used the IP of that instead.
I would still check the nsswitch.conf files.
On 6/25/21 5:00 PM, Ed Greshko wrote:
On 26/06/2021 07:25, ToddAndMargo via users wrote:
On 6/25/21 3:33 PM, Ed Greshko wrote:
On 26/06/2021 06:23, ToddAndMargo via users wrote:
On 6/25/21 2:45 PM, Ed Greshko wrote:
On 26/06/2021 05:33, Tom Horsley wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
> Kernel 5.12.12-300 breaks host resolution > https://bugzilla.redhat.com/show_bug.cgi?id=1976371 Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
What I find equally weird is that in the BZ he states that his qemu VM's are working just fine. If the VM's are working and they have been updated to the same kernel then what would be the difference? A proxy setting perhaps?
More funny! The VM's are using my caching name server ON MY HOST !!!!
Sure, that's pretty much the default if your VM's are using DHCP.
The one thing to recall is, and this is from memory, is that "host" and "dig" don't make use of the system's resolver library. They query dns servers directly. So, another thing to check is if the /etc/nsswitch.conf on the VM's are the same as the host.
Dig did not work either.
function GetPublicIP () { local WIP=$(dig +short myip.opendns.com @resolver1.opendns.com) # echo "WIP = <$WIP>" > "/dev/tty" if [[ "$WIP" == *"not found"* || "$WIP" == *"no servers could be reached"* ]]; then WIP="Not Found" fi
echo $WIP } _______________________________________________
I don't know were that snippet comes from. But, the "Not found" may be due to dig using the system's resolver to first get the IP of resolver1.opendns.com. So, I would have used the IP of that instead.
I would still check the nsswitch.conf files.
My computer is functioning perfect under the prior kernel.
I am not sure why you want the /etc/nsswitch.conf, but it is anyway. Kernels should not affect it.
Host:
passwd: sss files systemd shadow: files sss group: sss files systemd hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: nisplus sss publickey: nisplus automount: files nisplus aliases: files nisplus
FC34 VM:
$ uname -r 5.11.16-300.fc34.x86_64
passwd: sss files systemd shadow: files sss group: sss files systemd hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: nisplus sss publickey: nisplus automount: files nisplus aliases: files nisplus
On 26/06/2021 08:24, ToddAndMargo via users wrote:
On 6/25/21 5:00 PM, Ed Greshko wrote:
I don't know were that snippet comes from. But, the "Not found" may be due to dig using the system's resolver to first get the IP of resolver1.opendns.com. So, I would have used the IP of that instead.
I would still check the nsswitch.conf files.
My computer is functioning perfect under the prior kernel.
I am not sure why you want the /etc/nsswitch.conf, but it is anyway. Kernels should not affect it.
I try not to discount anything when I have no idea where the problem lies.
FC34 VM:
$ uname -r 5.11.16-300.fc34.x86_64
So, the nsswitch.conf files are the same. But you've not updated your VM. So, to just state you VM's are working didn't disclose that bit.
Since you can take snapshots of VM's. Why not take a snapshot before an upgrade, then upgrade to the latest kernel and see if you can reproduce the error?
On 26/06/2021 10.31, Ed Greshko wrote:
On 26/06/2021 08:24, ToddAndMargo via users wrote:
On 6/25/21 5:00 PM, Ed Greshko wrote:
I don't know were that snippet comes from. But, the "Not found" may be due to dig using the system's resolver to first get the IP of resolver1.opendns.com. So, I would have used the IP of that instead.
I would still check the nsswitch.conf files.
After a (late May update) I had problems with name resolution and tracked it down to this line on the name server host: hosts: files myhostname resolve [!UNAVAIL=return] dns and this fixed it for me hosts: files myhostname resolve dns
YMMV
My computer is functioning perfect under the prior kernel.
I am not sure why you want the /etc/nsswitch.conf, but it is anyway. Kernels should not affect it.
I try not to discount anything when I have no idea where the problem lies.
FC34 VM:
$ uname -r 5.11.16-300.fc34.x86_64
So, the nsswitch.conf files are the same. But you've not updated your VM. So, to just state you VM's are working didn't disclose that bit.
Since you can take snapshots of VM's. Why not take a snapshot before an upgrade, then upgrade to the latest kernel and see if you can reproduce the error?
On 26/06/2021 08:39, Eyal Lebedinsky wrote:
After a (late May update) I had problems with name resolution and tracked it down to this line on the name server host: hosts: files myhostname resolve [!UNAVAIL=return] dns and this fixed it for me hosts: files myhostname resolve dns
Thanks for pointing that out. I did some searches on that and found that other users have also had issues with that after a kernel update.
Being Saturday, I didn't do too much to see if a root cause was identified or a fix is pending. :-)
On 6/25/21 5:39 PM, Eyal Lebedinsky wrote:
After a (late May update) I had problems with name resolution and tracked it down to this line on the name server host: hosts: files myhostname resolve [!UNAVAIL=return] dns and this fixed it for me hosts: files myhostname resolve dns
YMMV
Hmmmmmmm.... What does `[!UNAVAIL=return]` do?
On 26/06/2021 14:18, ToddAndMargo via users wrote:
On 6/25/21 5:39 PM, Eyal Lebedinsky wrote:
After a (late May update) I had problems with name resolution and tracked it down to this line on the name server host: hosts: files myhostname resolve [!UNAVAIL=return] dns and this fixed it for me hosts: files myhostname resolve dns
YMMV
Hmmmmmmm.... What does `[!UNAVAIL=return]` do?
It means that if name resolution via systemd-resolved is not unavailable then return the result you have and stop.
So, if it is available but let's say returns "nothing/not-found" then that would be the result returned for the query.
If one could replicate the failure it would be helpful in debugging.
On 26/06/2021 15:13, ToddAndMargo via users wrote:
On 6/25/21 11:56 PM, Ed Greshko wrote:
not unavailable
double negative
Yes, that is what [!UNAVAIL=return] means. It is a double negative as that is what ! does. It checks the opposite condition of "UNAVAIL"
The valid "status" entries for nsswitch tests are "success", "notfound", "unavailable", and "tryagain".
See "man nsswitch.conf" for details.
On 6/25/21 5:39 PM, Eyal Lebedinsky wrote:
After a (late May update) I had problems with name resolution and tracked it down to this line on the name server host:
hosts: files myhostname resolve [!UNAVAIL=return] dns and this fixed it for me hosts: files myhostname resolve dns
YMMV
As James pointed out, you have to be using bridge networking to reproduce this.
And Eyal's removal of [!UNAVAIL=return] correct my problem.
also, if I did not make the issue clear, Tor is innocent.
On 27/06/2021 07:02, ToddAndMargo via users wrote:
On 6/25/21 5:31 PM, Ed Greshko wrote:
Since you can take snapshots of VM's. Why not take a snapshot before an upgrade, then upgrade to the latest kernel and see if you can reproduce the error?
My VM's are not configured with bridge networking, only the host
Sure. But, of course, that wasn't known at the time I made my suggestion. :-)
On 6/26/21 4:15 PM, Ed Greshko wrote:
On 27/06/2021 07:02, ToddAndMargo via users wrote:
On 6/25/21 5:31 PM, Ed Greshko wrote:
Since you can take snapshots of VM's. Why not take a snapshot before an upgrade, then upgrade to
the latest kernel and see if you can reproduce the error?
My VM's are not configured with bridge networking, only the host
Sure. But, of course, that wasn't known at the time I made my suggestion. :-)
But, But, But ...
I did not know it either!
I updated the bugzilla
:-)
On Fri, 25 Jun 2021 17:33:04 -0400 Tom Horsley horsley1953@gmail.com wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
I had name resolution break on one of my F34 computers after the latest kernel update. Restarting systemd-resolved fixed the problem. I rebooted and the same thing happened: no DNS until systemd-resolved was restarted.
None of systemctl status, dmesg, or journalclt showed anything suspicious or interesting.
My other Fedora computers are fine. I suspect the difference is that the problem computer is using bridged networking instead of a direct ethernet connection. Perhaps a timing issue with the bridge?
Jim
On 6/26/21 10:19 AM, James Szinger wrote:
On Fri, 25 Jun 2021 17:33:04 -0400 Tom Horsley horsley1953@gmail.com wrote:
On Fri, 25 Jun 2021 14:20:30 -0700 ToddAndMargo via users wrote:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Very weird that the kernel could break name resolution since that all works at library level. Maybe some "deprecated" interface is being used by 99% of the lookup code, and they got rid of it completely in the new kernel?
I had name resolution break on one of my F34 computers after the latest kernel update. Restarting systemd-resolved fixed the problem. I rebooted and the same thing happened: no DNS until systemd-resolved was restarted.
None of systemctl status, dmesg, or journalclt showed anything suspicious or interesting.
My other Fedora computers are fine. I suspect the difference is that the problem computer is using bridged networking instead of a direct ethernet connection. Perhaps a timing issue with the bridge?
Jim
Hi Jim,
My only computer with the issue is also using bridge networking.
Eyal recommendation to alter nsswitch.conf
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve dns
worked for me.
-T
On 27/06/2021 05:16, ToddAndMargo via users wrote:
My only computer with the issue is also using bridge networking.
Eyal recommendation to alter nsswitch.conf
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve dns
worked for me.
Oh, just to confirm, when you made the change you did so using authselec, yes?
On 6/26/21 4:50 PM, Ed Greshko wrote:
On 27/06/2021 05:16, ToddAndMargo via users wrote:
My only computer with the issue is also using bridge networking.
Eyal recommendation to alter nsswitch.conf
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve dns
worked for me.
Oh, just to confirm, when you made the change you did so using authselec, yes?
What is "authselec"?
If you mean how do I make the alteration, I used the test editor from h*** ("vi").
On 6/26/21 6:00 PM, Joe Zeff wrote:
On 6/26/21 6:53 PM, ToddAndMargo via users wrote:
If you mean how do I make the alteration, I used the test editor from h*** ("vi").
If you hate it that much, why do you use it? There are others, you know, such as nano.
I was abeing sarcastic. I actually like vi and have been using it for over 30 years. The remark was becasue vi creates more of a storm than what topping to get on a pizza!
:-)
On 27/06/2021 08:53, ToddAndMargo via users wrote:
On 6/26/21 4:50 PM, Ed Greshko wrote:
On 27/06/2021 05:16, ToddAndMargo via users wrote:
My only computer with the issue is also using bridge networking.
Eyal recommendation to alter nsswitch.conf
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve dns
worked for me.
Oh, just to confirm, when you made the change you did so using authselec, yes?
What is "authselec"?
Should have been "authselect".
The /etc/nsswitch.conf has the following information and I wanted to make sure you followed that as subsequent updates could revert the changes without your knowledge.
# Do not modify this file manually.
# If you want to make changes to nsswitch.conf please modify # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
On 26/06/2021 05:20, ToddAndMargo via users wrote:
I just posted:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Don't forget to update your BZ to add the knowledge about needing a bridge network to reproduce the issue.
On 6/26/21 4:57 PM, Ed Greshko wrote:
On 26/06/2021 05:20, ToddAndMargo via users wrote:
I just posted:
Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371
Don't forget to update your BZ to add the knowledge about needing a bridge network to reproduce the issue.
Did so a few hours ago. I did mention it on one of my posts, but with so many, they can get lost.
-
Ed Greshko -
Eyal Lebedinsky -
Gabriel Ramirez -
James Szinger -
Joe Zeff -
toddandmargo -
ToddAndMargo
-
Tom Horsley