[SOLVED] Upgraded to Debian Buster (presently stable release) and lost networking

Firerat · 08-29-2019, 02:39 PM

Code:

cat /etc/udev/rules.d/70-persistent-net.rules

comment out each line

Code:

sed 's/SUBSYSTEM/#SUBSYSTEM/' /etc/udev/rules.d/70-persistent-net.rules

if the result looks good ( all lines start # )

Code:

sudo sed -i 's/^SUBSYSTEM/#SUBSYSTEM/' /etc/udev/rules.d/70-persistent-net.rules

the -i

Code:

-i[SUFFIX], --in-place[=SUFFIX]
 edit files in place (makes backup if SUFFIX supplied)

to revert

Code:

sudo sed -i 's/^#SUBSYSTEM/SUBSYSTEM/' /etc/udev/rules.d/70-persistent-net.rules

no ifconfig?

try

Code:

ip addr
man ip

arvid001 · 08-29-2019, 04:12 PM

Code:

root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ffroot@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroroot@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# ute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noproot@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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 root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# refixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv#

Makes no sense to me. What is a "valid_lft"? What happened to IP-V4?

Should I go ahead with the system mods suggested by "fireat"?
Or, is there a problem with drivers for the Realtek Ethernet board as suggested by Thinknix?

Thanks

arvid001 · 08-29-2019, 04:42 PM

My last post was result using "ip addr" with a boot to the old kernel (I got confused).
This post shows "ip addr" output using the newest kernel with Debian Buster release.

Code:

arv@RadioRoom:~$ su
Password: 

root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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

root@RadioRoom:/home/arv# ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.042 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.042 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 34ms
rtt min/avg/max/mdev = 0.036/0.040/0.042/0.003 ms

root@RadioRoom:/home/arv# ping 192.168.0.1
connect: Network is unreachable
root@RadioRoom:/home/arv#

So, is the problem with naming of port interface, or is it with Realtek drivers?
Or...is it something else? Is the newest kernal not usable with the Buster release?

Next step...?

Firerat · 08-29-2019, 04:48 PM

for now just

cat /etc/udev/rules.d/70-persistent-net.rules

lets see if it is forcing drivers not in the newer kernel

arvid001 · 08-29-2019, 05:30 PM

Code:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
arv@RadioRoom:~$

Does this indicate that the r8169 driver is being used, or that that driver is needed but not being used?

Firerat · 08-29-2019, 05:58 PM

Quote:

Originally Posted by arvid001

Code:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
arv@RadioRoom:~$

Does this indicate that the r8169 driver is being used, or that that driver is needed but not being used?

it looks like when that file was generated it was the r8169 driver that was being used

comment out the SUBSYSTEM line ( use the sed or edit manually by starting line with #)

the worst that can happen is you will lose net on the old kernel, but we just need to change teh file back to what it was

after a reboot you may see enp instead of eth when using "ip address" command

arvid001 · 08-29-2019, 10:30 PM

Code:

root@RadioRoom:/home/arv# cat /etc/udev/rules.d/70*
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="enp"
root@RadioRoom:/home/arv# 
root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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
root@RadioRoom:/home/arv# 
root@RadioRoom:/home/arv# ping 192.168.0.1
connect: Network is unreachable
root@RadioRoom:/home/arv#

Okay...NAME="eth" changed to NAME="enp". Nothing seems to have changed.
Still no networking using latest kernel and Debian Buster.
This change to NAME="enp" made no change in the old kernel...networking there still works fine.

What next?

Firerat · 08-30-2019, 08:06 AM

sorry, that enp eth comment may have confused you.

change it back ( to eth* and eth0 )
and comment that line out
that will in effect delete that rule and let the system manage the network device itself

arvid001 · 08-30-2019, 10:47 AM

OK, restored the "NAME=" part and commented out that line in the file, as instructed.
Still no networking when using the latest kernel.

What next?

Firerat · 08-30-2019, 10:59 AM

hmm,
maybe I should go read that release notes thing, to see what it was saying.
in the meantime,

Code:

lspci -k|grep -A3 Ethernet\ con

will list your Ethernet controllers including the kernel driver/module in use
mine as example

Code:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
        Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Kernel driver in use: r8169
        Kernel modules: r8169
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
        Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Kernel driver in use: r8169
        Kernel modules: r8169
--
07:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC
        Kernel driver in use: r8169
        Kernel modules: r8169

yeah, Abit a blast from the past

do that both on new and old so we can compare

Firerat · 08-30-2019, 12:19 PM

after reviewing the release notes it seemed more concerned with networking scripts not picking up the new net device names ( ethX -> enpYsZ )

so,
after commenting out the udev rules your eth0 shoulld be enp1s0

you will edit all your network related scripts and replace eth0 with enp1s0

alternatively, you could try re-enabling the rule, and have it

Code:

# PCI device 0x10ec:0x8168 (r8169)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enp1s0", NAME="eth0"

but the release notes do say that may not work

arvid001 · 08-30-2019, 02:43 PM

Code:

root@RadioRoom:/home/arv# 
root@RadioRoom:/home/arv# cat ./test_results
WITH OLD KERNEL: Version 4.19.0-5 AMD64

root@RadioRoom:/home/arv# lspci -k|grep -A3 Ethernet\ con
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Kernel driver in use: r8168
	Kernel modules: r8168
root@RadioRoom:/home/arv# 

============================
WITH NEW KERNEL: Version 4.9.0-5 AMD64

root@RadioRoom:/home/arv# lspci -k|grep -A3 Ethernet\ con
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Kernel driver in use: r8168
	Kernel modules: r8168
root@RadioRoom:/home/arv# 

============================
Cat of /etc/udev/rules.d/70* Now modified to show KERNEL="enp1s0" and NAME="eth0"

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enp1s0", NAME="eth0"

NETWORKING WITH NEW KERNAL:   It works!, It works!  8-)  8-)  

root@RadioRoom:/home/arv# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.463 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.425 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.360 ms
^C
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 56ms
rtt min/avg/max/mdev = 0.360/0.416/0.463/0.042 ms
root@RadioRoom:/home/arv# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=18.6 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 18.612/18.783/19.044/0.187 ms
root@RadioRoom:/home/arv#

Success at last. Thank you, thank you. Seems that the Kernal="enp1s0" change fixed everything.
Maybe a check could be put in the install script to test for this and automatically fix it if needed.

Thanks again. I could not have done it without your help.

arvid001 · 08-30-2019, 02:55 PM

OOPS! I spoke to quickly. After a reboot on the 4.9.0-5 AMD64 kernal, networking is still broken.
Present guess is that I was confused about which kernal I was actually running. 8-(

THIS IS ON THE OLD KERNAL (running Debian 10/Buster but with the old kernal)
Networking works on this kernal.

Code:

[root@RadioRoom:/etc# cat ./os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"

Are there any error logs that might shed some light on this situation?

Thanks.

Firerat · 08-30-2019, 04:44 PM

yeah, to be expected ( if I understand correctly )

the "new" udev rules are a just a hack to keep your network setup scripts happy
they will not work on the older kernel since udev fails to setup the network device ( no enp1s0 to rename ).

I would correct the network scripts, as per
https://www.debian.org/releases/bust...nterface-names

Code:

$ sudo rgrep -w eth0 /etc 
$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null

you don't need that udevadm one tbh,
we already know you need to replace eth0 with enp1s0

so for each file found with that rgrep
copy line and replace eth0 with enp1s0
comment out the old line, and comment on why
# 2019-08-30 pre-buster net device eth0 now enp1s0

and comment out the udev rule ( annotate that also )

I can't think of any reason would would need to boot the old kernel
It will probably be auto removed in a few months due to kernel updates.

It looks like I should do this myself, I still have the old /etc/udev/rules.d/70-persistent-net.rules , and I'm on Debian Sid.. It will probably break at some point in the future

Note you may need to fix other configs,
might be worth running that rgrep on ~/.config

arvid001 · 09-04-2019, 10:54 AM

Sorry about the delay.
After several days of peeking poking into why the latest kernal (4.19.0-5 AMD-64)and Debian-10 (Buster) breaks Debian-10, I have come to the conclusion that this latest kernal for Debian is just not compatible with much of the newer and faster hardware available from popular vendors. For this reason I decided to modify Grub-2 so that it boots to the prior kernal (4.9.0-9 AMD-64) and simply ignore the defective kernal release. Maybe later when a new kernal is released for Debian I can retry it to see if the problem has been fixed. Admittedly this solution is just kicking-the-can-down-the-road but it seems to be the best solution for right now.

Thanks for all the help and suggestions.