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

Kernel 5.12.12-300 breaks host resolution https://bugzilla.redhat.com/show_bug.cgi?id=1976371

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 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 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 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?

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

not unavailable

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

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

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?

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.

If you mean how do I make the alteration, I used the test editor from h*** ("vi").

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!

# Do not modify this file manually.

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.