[SOLVED] Upgraded to Debian Buster (presently stable release) and lost networking
DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Upgraded to Debian Buster (presently stable release) and lost networking
Today I upgraded to Debian Buster using the edit sources.list method. Everything appears to have worked until I rebooted. Then networking does not work. The SETTINGS menu shows only VPN as a network option, but my system is directly connected via eth0, so that is not an option. Without networking there seems to be no way to get on-line for backing out of Buster and no way to do any further download/install of necessary software packages for networking.
Am I at the point where a DVD based install is the only option (that sucks)?
If you boot into your old kernel (which should still be installed), does your network then work again?
Also, try the following things to collect some more information:
Code:
cat /etc/network/interfaces
ip add
lspci -nnk | grep -A 3 -i network
Probably we can get your network functioning again without a reinstall. If you can export the output of the commands I gave you and post them here, we'll be able to help much more, as well.
Did a restart using an older kernal and networking is back.
---
root@RadioRoom:/home/arv# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
root@RadioRoom:/home/arv# ^C
root@RadioRoom:/home/arv#
---
root@RadioRoom:/home/arv# ip add
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 85909sec preferred_lft 85909sec
inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute
valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv#
---
This was with the old kernal. Just realized that maybe I should be doing this same thing with the newest kernal and Debian Buster?
Is that correct? I will reboot into the latest kernal and then try this again........just a minute...
Now those commands using the Debian Buster install from earlier today:
arv@RadioRoom:~$ su
Password:
root@RadioRoom:/home/arv# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
root@RadioRoom:/home/arv#
root@RadioRoom:/home/arv#
root@RadioRoom:/home/arv# ip add
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#
root@RadioRoom:/home/arv# lspci -nnk | grep -A 3 -i network
root@RadioRoom:/home/arv#
Do an lspci -k (and put it in the [ code ] brackets as it will probably be rather long) with the old kernel. For some reason doesn't show up as a network device, we need to know what kernel the hardware is using.
Your ethernet is onboard, right? Not a USB dongle?
Last edited by Timothy Miller; 08-28-2019 at 11:12 PM.
Not sure what you mean by "put text in code brackets". I did put bounding brackets ahead and behind the text part.
I am an old, old, ancient, UNIX Sys-Admin (AT&T & Bell Labs) and probably not up to speed on modern methods.
Since there is no networking with the new kernal it would be impossible to install a new Realtek driver when running
on Buster, but would installing that driver while using the older Kernal make it available to Buster on the newest kernal?
I can do some searches but does anyone know where to find the Kernel driver that is in use: r8168 (Kernel modules: r8168)?
I find that driver at <https://softfamous.com/realtek-rtl8168-8111-pci-e-gigabit-ethernet-nic-driver/> but it is only in
Windows format. Will that work on Debian Linux?
This while running the older kernal. Do I need to run these commands using the New kernal on Buster?
[root@RadioRoom:/home/arv#
root@RadioRoom:/home/arv# apt list --installed | grep 8168
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
r8168-dkms/now 8.043.02-1 all [installed,local]
root@RadioRoom:/home/arv#
root@RadioRoom:/home/arv# apt search firmware-realtek
Sorting... Done
Full Text Search... Done
firmware-realtek/now 20161130-5 all [installed,local]
Binary firmware for Realtek wired/wifi/BT adapters
4.1.6 Verify network interface name support
Systems upgraded from older releases that still use network interfaces with names like eth0 or wlan0 are at risk of losing networking once they switch to buster; see Section 5.1.5 for migration instructions.
I upgraded from Stretch so the network names supposedly already deprecated in that release and should have been ready for the Buster release (see Release Notes 5.1.5). Unless...the wording in the release notes is incorrect.
The problem with network naming might have been more visible if we still had the "ifconfig" command that has been standard in UNIX and Linux for many many years. But, alas, that too has been deprecated in favor of a more Windows-like command.
It the network names are known and available via various commands, it maybe should have been the responsibility of the release managers to make this renaming an automated process.
Unfortunately this info is not made obviously available prior to doing the upgrade.
Once you are ready to carry out the switch, disable 70-persistent-net.rules either by renaming it or by commenting out individual lines. On virtual machines you will need to remove the files /etc/systemd/network/99-default.link and (if using virtio network devices) /etc/systemd/network/50-virtio-kernel-names.link. Then rebuild the initrd:
How does one go about "disable 70-persistent-net"? Where does it reside? How do I know if I am using a "virtual machine" or a real one? What should be done to "rebuild initrd"?
Apparently my system is still using eth0, even though that was supposed to have been deprecated in the Stretch releass, according to the Buster release notes. What should I do now, and how should I do it?
I don't think it's the name. The system is using networkmanager & systemd, and so the name shouldn't matter, it'll update and carry on without issues with the new name. I think it's because the 8168 driver is installed, which blacklists the 8169 driver. I think buster REQUIRES the 8169 driver now for this chipset from what I've read, ergo why ip add doesn't even SEE an interface assigned for that card. In theory should be able to confirm if you (with new kernel) ran (as root)
Code:
dmesg | grep 8168
dmesg | grep 8169
This should show the driver (8168) being unable to load.
I had issues with the systemd-style persistent interface names in Buster with and the Realtek wireless drivers. It was a fresh install in my case, not an upgrade, still it sounds like you need to revert to the old naming scheme.
I disabled the persistent naming using the tips in /usr/share/doc/udev/README.Debian.gz:
Code:
- Disable the default *.link rules with
"ln -s /dev/null /etc/systemd/network/99-default.link"
and rebuild the initrd with "update-initramfs -u".
After a reboot I had my wlan0 back and all was working.
root@RadioRoom:/home/arv# dmesg | grep 8168
[ 0.222827] pci 0000:01:00.0: [10ec:8168] type 00 class 0x020000
[ 0.955239] r8168: loading out-of-tree module taints kernel.
[ 0.955966] r8168 Gigabit Ethernet driver 8.043.02-NAPI loaded
[ 0.972731] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[ 0.972736] r8168 Copyright (C) 2016 Realtek NIC software team <nicfae@realtek.com>
[ 2.388168] ppdev: user-space parallel port driver
[ 6.924717] r8168: eth0: link up
root@RadioRoom:/home/arv# dmesg | grep 8169
root@RadioRoom:/home/arv#
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Upgraded to Debian Buster (presently stable release) and lost networking
