I switched my whole desktop-setup from windows to GNU/Linux + Debian 10. I am able to run the debian netinstaller and connect the mainboard for internet-software-updates.
But whenever I got the full setup up and running, Debian is not able to connect to the network via ethernet. Immediately after login the interface states, that the network is disconnected. After a motherboard change, I am fairly certain, that this is some kind of a software/driver problem.
My hardware setup consists of:
- Asus ROG Crosshair Hero VI
- Nvidia GTX 670 in PCI1
- Nvidia GTX 970 in PCI2 (aim is to passthrough in to a VM)
- Ryzen 7 2700X
- Samsung EVO SSD with encrypted LVM, no further partitions
This question is similar to https://askubuntu.com/questions/1135412/updated-to-19-04-and-no-ethernet-now, but my setup is different and research on stackexchange etc. brought no help.
Output of systemctl status NetworkManager
:
device (enp4s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
device (enp4s0): state change: config -> ip-config (reason 'none', sys-iface-state:'managed')
dhcp4 (enp4s0): activation: beginning transaction (timeout in 45 seconds)
DHCPrequests
dhcp4 (enp4s0): dhclient started with pid 1334
device (enp4s0): state change: ip-config -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
dhcp4 (enp4s0): canceled DHCP transaction, DHCP client pid 1334
dhcp4 (enp4s0): state changed unknown -> done
manager: NetworkManager state is now DISCONNECTED
Output of lspci | grep Ethernet
:
Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
/etc/network/interfaces remained unchanged, changing it to hotplug or static IP-addresses doesn't help. Same for setting up static network settings in nmcli.
Output of nmcli device show enp4s0
:
GENERAL.DEVICE: enp4s0
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 04:92:26:DA:16:CC
GENERAL.MTU: 1500
GENERAL.STATE: 20 (unavailable)
Output of uname -a
:
Linux NAMEOFPC 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux
Output of Dmesg | grep enp4s0
:
1.054338] igb 0000:04:00.0 enp4s0: renamed from eth0
[ 56.832109] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[ 56.857033] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[ 59.608583] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[ 59.608829] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[ 83.708581] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[ 147.966461] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[ 320.546500] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[ 323.280590] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[ 323.280831] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[ 326.168592] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
Physically disconnecting is no solution, NetworkManager immediately notifies, that the physical connection is not down again. The only solution seems to be ip link set enp4s0 down
followed by ip link set enp4s0 up
. It would be ps
I added nonfree repositorys as well - to no avail. The only solution I didn't try was the propietary intel I211 driver. But I don't know if this is the solution, since the mentioned askubuntu-post uses Kernel 5.x and a Realtek network card - with the same problems.
Edit: Furthermore, this problem seems to be seldomly metioned and I assume you would find more posts regarding this problem, if the only solution is to compile a new driver into the kernelspace. Additionally, Intel states, that the IGP-linux driver for the I211 is made for Kernels 2.x and 3.x...
Output of cat /sys/class/net/enp4s0/device/power/control:
"on"
A direct connection to the router enables a network connection immediately. Furthermore, the switch is indeed limited to 100mbps. I didn't have the time to install ethtool, yet. I will update when I had the time to do so.
Are there any solutions to this problem?
Maybe it is the message of NetworkManager "reason 'carrier-changed', sys-iface-state: 'managed'", which can give some hint to the problem? Maybe it is the fact, that encrypted LVMs remain in some kind of hibernating status after shudown? That's what the CLI tells you when shutting down and booting (e.g. resuming from hibernation).