Unsolved Troubleshooting Help Requested
-
I guess I'll just restore the VM and see what happens from it.
-
@DustinB3403 said in Troubleshooting Help Requested:
This is what I get from the non-working VM.
yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile- base: mirror.atlanticmetro.net
- extras: bay.uchicago.edu
- updates: centos.s.uw.edu
http://repos-va.psychz.net/centos/7.6.1810/os/x86_64/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: repos-va.psychz.net; Unknown error"
Trying other mirror.
It just keeps going through all of the mirrors, obviously.
I've disabled and turned off yum-cron and have reboot numerous times. So that isn't it. I can ping locally by IP and DNS from the non-working machine.
Did I see right that
tracerouteisn't installed? -
@travisdh1 yes.
-
And it isn't required either, as this system has updated fine for months.
-
@DustinB3403 said in Troubleshooting Help Requested:
@travisdh1 yes.
Makes it difficult to see weather there are peering-point issues between you and the mirror sites.
edit: Yes, I've seen networks block distribution mirror sites before. So much fun trying to get those fixed.
-
@travisdh1 said in Troubleshooting Help Requested:
edit: Yes, I've seen networks block distribution mirror sites before. So much fun trying to get those fixed.
But on the very same network, just a different host nothing is blocked. I could of course look at the firewall to see if something was changed. But if changes were to be made, I think I would've been made aware.
And every mirror is blocked. It's as though this device itself is blocked.
-
Try
ping -4 google.com
It’s probably using ipv6 instead of ipv4 -
@black3dynamite said in Troubleshooting Help Requested:
Try
ping -4 google.com
It’s probably using ipv6 instead of ipv4Will test that in a moment. The restore is going.
-
@black3dynamite said in Troubleshooting Help Requested:
Try
ping -4 google.com
It’s probably using ipv6 instead of ipv4No change.
And the backup from yesterday has no change either. Grr. . . I don't want to rebuild this VM. . . going further back.
It isn't mission critical either, just irritating.
-
Are you using NetworkManager? If so, turn that shit off.
-
Try adding 127.0.0.1 to /etc/resolv.conf
-
@Obsolesce said in Troubleshooting Help Requested:
Are you using NetworkManager? If so, turn that shit off.
Not using NM.
-
@Obsolesce said in Troubleshooting Help Requested:
Try adding 127.0.0.1 to /etc/resolv.conf
No change with adding the loopback.
-
@DustinB3403 : The fact that you can ping the gateway/router by name and IP makes me suspect it's the firewall.
AFAIK, there is nothing on a linux box that would allow it to distinguish between LAN and WAN when performing lookups. -
@manxam said in Troubleshooting Help Requested:
@DustinB3403 : The fact that you can ping the gateway/router by name and IP makes me suspect it's the firewall.
AFAIK, there is nothing on a linux box that would allow it to distinguish between LAN and WAN when performing lookups.the firewall, OR the default gateway is messed up. Check the routes on the VM.
-
@scottalanmiller I have 1 route on the VM, and its a mirror image of the route on the working VM, with the exception of the device name, and IP.
-
Working
Not Working
-
@DustinB3403 : Yes, but that doesn't mean the firewall doesn't have a rule (or is a Sonicwall -- see my old post) to block outbound on WAN from that IP.
-
Double check mac address so you don't have two VMs with the same. That and conflicting ip addresses can cause some strange effects.
-
Clear arp caches and Mac address tables on your gateway or firewall sounds like a Mac address conflict at the gateway
