1

Related, but solved by workaround: In Archlinux, it has a valid ip, but no connection could established

My Arch system has gone "offline" some time ago. I didn't bother to much because I used the Windows VM that had internet via network bridging. The funny thing is if I open NetworkManager and delete my connection, it immediately resets and internet is available under Arch until i3wm shows the IP in the status bar (~3s). Now I am trying to get it running normal again the third time and need some help.

uname -a 
Linux iamgroot 4.16.12-1-ARCH #1 SMP PREEMPT Fri May 25:30:31 UTC 2018 x86_64 GNU/Linux

cat /etc/resolv.conf
\# Generated by resolvconf #escaped for stackexchange codeformatting
domain fritz.box
nameserver 192.168.178.1

ip route
default via 192.168.178.1 dev en3ps0 proto dhcp src 192.168.178.37 metric 202
default via 192.168.178.1 dev bridge_qemu_0 proto dhcp src 192.168.178.37 metric 203
192.168.178.0/24 dev en3ps0 proto dhcp scope link src 192.168.178.37 metric 202
192.168.178.0/24 dev bridge_qemu_0 proto dhcp scope link src 192.168.178.37 metric 203

ping stackexchange.com
ping: stackexchange.com: Temporary failure in name resolution

ip addr
1: lo <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc nonqueue state UNKOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: en3ps0 <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge_qemu_0 state UP group default qlen 1000
    link/ether d4:3d:7e:bd:ec:ce brd ff:ff:ff:ff:ff:ff
    inet 192.168.278.37/24 brd 192.168.178.255 scope global noprefixroute en3ps0
        valid_lft forever preferred_lft forever
3: bridge_qemu_0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d4:3d:7e:bd:ec:ce brd ff:ff:ff:ff:ff:ff
    inet 192.168.278.37/24 brd 192.168.178.255 scope global noprefixroute bridge_qemu_0
    inet6 fe80::2b75:33d9:ac58:3c55/64 scope link
        valid_lft forever preferred_lft forever
4: tap0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge_qemu_0 state UNKNOWN group default qlen 1000
    link/ether fe:0d:6e:2d:8f:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::8a0b:fb95:5201:6d6a/64 scope link
        valid_lft forever preferred_lft forever
    inet6 fe80::fc0d:6eff:fe2d:8faa/64 scope link
        valid_lft forever preferred_lft forever

I would really appreciate all ideas.

fra-san
  • 9,931
  • 2
  • 21
  • 42
Falk
  • 11
  • 1

1 Answers1

0

Either some peculiarity of your configuration is interfering with the resolconf package, or you were manipulating/copying over /etc/resolv.conf or some of your packages does not take into account having installed resolv.conf. Knowing arch linux, I do bet on the late probability.

The path of less resistance may be really better por an inexperienced user deleting the resolvconf package instead of trying to fix the resolv.conf symlink and/or finding out which package should be (re)configured.

resolvconf is also known to interfere also with VPNs, and I usually prefer to uninstall the package in my servers and desktops, even knowing my way how to deal with it.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227