After i’ve updated my system today and rebooting normally (had like 4.7GB of pending updates!), it caused a complete mangling of my network configuration, no longer connecting to internet and was endlessly trying to configure my interface.
checking NetworkManager logs with journalctl, it was constantly entering into loops, stopping at ip-config-unavailable and restarting the whole process again, restarted the NetworkManager service worked, once, reboot the system, the bandaid fix not longer worked.
The aging X79 motherboard has 3 network devices (which only one doesn’t work because it’s broadcom, the rest is LAN):
00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network Connection [8086:1503] (rev 06)
DeviceName: Onboard LAN
Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard [1043:849c]
Kernel driver in use: e1000e
--
0b:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4352 802.11ac Dual Band Wireless Network Adapter [14e4:43b1] (rev 03)
Subsystem: ASUSTeK Computer Inc. Device [1043:855c]
Kernel driver in use: wl
Kernel modules: bcma, wl
--
0d:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)
Subsystem: ASUSTeK Computer Inc. AM1I-A Motherboard [1043:859e]
Kernel driver in use: r8169
Kernel modules: r8169
So i’m not entirely sure if some update caused a huge mess and caused the network interfaces to misbehave.
I’ve able to kind of fix it, but tried to reconfigure the second LAN interface, thankfully the first one works normally now, so it was easy to disable it via KDE System Settings.
So the steps i did was:
Unplug the ethernet cable.
Uninstall Docker and remove the docker0 virtual interface, i haven’t used Docker for a while, so why bother.
Put eno1 interface to DOWN via sudo ip link set eno1 down
Check my eno1 (the interface i having problems with) configuration via sudo nmcli connection show and copy the connection uuid of eno1.
Delete the connection via sudo nmcli connection delete
Reenable the interface again with sudo ip link set eno1 up
Reboot the computer
This restored my internet connection back again, but KDE recreated the network profiles for the 2 unused network interfaces (LAN and WiFi), and the LAN one was trying to reconfigure itself over and over, but has no ethernet cable plugged into it (the same problem i had at the beggining) but disabled both profiles and works normally now.
What kind of network managing was used before the update?
Maybe also mention from what old version to what new version you went, maybe snapshot numbers, else you need detailed package numbers of involved tools.
I remember long time ago wicked based networking also failed as interfaces were renamed. That was on a Raspberry Pi 4B, so I logged in via serial console and switched from wicked to NM (done in YaST text mode).
But still naming issues might occur, depends on for example if you used a net.ifnames kernel cmdline setting of udev rules or .link files etc are or where there.
Your 2 Ethernet devices should be no problem for Tumbleweed. The WiFi device might lack proper firmware, but else this should all be no problem.
An issue might be that mixing the low-level ‘ip’ with high level ‘nmcli’ might easily cause non-persistent issues. ip does change things runtime while nmcli also can modify config files.
What I usually do is, assuming NetworkManager is used, e.g. not wicked nor systemd-networkd, is to use the text tool nmtui to create profiles for all network HW and only set autoconnect for the one I want to use under normal circumstances, so what should work after computer powered on. You can always then use ‘nmcli connection up/down ’ later on.
it was NetworkManager, used nmcli only to remove the problematic configurations, forgot to mention this SSD had changed different motherboards a couple of times, so probably the old dangling configuration catched up to them, and caused this issue i don’t know.
So far i having no issues but unfortunately i kinda regret not saving the sudo zypper dup output, i haven’t updated since the 28th of July to yesterday (9th of August), so it backlogged a lot of updates.
So far i’m having no issues with the internet right now, but one of these days if i move this SSD back to a better motherboard, it could cause issues in the future i might never know.
That’s a habitual habit (aren’t those two words redundant?) I have.
I have a text file that lives on my Desktop called “update.txt”. When I run a “zypper up” and there are updates, I copy them to the file (with date executed). After accumulating three months of updates, I archive that file and create a new one.
I find it’s advantageous (for me) to save past updates, in case I have to figure out, “when did this app change / etc”.
I separate each update with recognizable string to make it easy to find specific dates - example from today:
You don’t need to manually save anything to a text file. The zypper history can easily and graphically be reviewed in Myrlyn → Extras → Show history
Myrlyn parses the zypp history files and properly presents them in a visual way. So any text file is redundant to the already existing /var/log/zypp history files.
before I update. That way, there is a record of any problems in the file “screenlog.0”. But I only keep that for one update. The zypp logs provide a good history for the long term.
Running updates under “screen” is partly as a protection in case the desktop crashes during the update. The update is somewhat isolated from the desktop, and will continue even with a desktop crash.
Tried,but i really want to know get the old Tumbleweed version to the new version before starting to distro upgrade, the so 202607_01 -> 202608_03 for example, but the logs just shows the packages installed during that update, and since i had backlogged a lot of updates the log is quite large.
Gonna use this then when i do big updates, because i have an habit of updating every monday or tuesday of next week, but sometimes i kind-of forget and i end with 4.32GB worth of updates, i have this habit since i started to play with OpenSUSE back in 2021 and ran a couple of hard-bugs i had to reinstall the OS (NVIDIA Drivers-Kernel incompatibility, updated too soon before NVIDIA catch up), and the Sudoers bug.
And always on terminal because i never trusted graphical tools, probably my bitter experiences in the old Ubuntu App Store (the old one from Sypnatic long long ago used to work), always some package failed to install and had to use the terminal to finish it.
You cannot download the older ISOs. You can download ( back to 20260712 currently ) packages, and use https://download.opensuse.org/history/20260712/tumbleweed/repo/ ( change snapshot# ), disable your current repos and then dup from it. But, that might lead to issues.
The method with ‘screen’ I also used in the past when GUI/drivers did crash sometime, but nowadays not needed anymore.
Other reason to use screen is when updating a remote computer via ssh, but also NetworkManager in Tumbleweed and recent other distros perfectly re-loads when also NM is updated.
But when networking is the issue, I use mostly just serial console (so CLI only). Intel/AMD computers/laptop mostly lack it, but I have more ARM computers than x86 operational actually and those all have easy and cheap options to attach a serial cable for console and/or debug. Some have extra USB-C port dedicated for it. Tumbleweed has also some nice extra ’ press ‘t’ ’ option for GRUB so you can select the previous kernel or edit kernel commandline before boot also via that.
If you don’t have previous kernel installed, you might find the .rpm package by browsing file on the repo servers/mirrors. Never needed that for Tumbleweed, but needed several times for Debian based distro (ARM SBC’s where kernel versions is a major thing).
I use Btrfs for rootfs and snapper to automatically do snapshots, so I never really needed zypper logs, but needed several times rollback to previous snapshot as sometimes Tumbleweed breaks things. Last time was (and still is) that wireguard and apparmor failed to cooperate, so no (remote) internet for me which is fatal, so then boot from previous snapshot. I do that manually, but SuSE supports it completely automated.
If you don’t have Btrfs and snapshots for rootfs, I would advice the use that at net fresh install. You can also in-place convert Ext4 to Btrfs (or even NTFS to Btrfs) but needs then anual setup of subvolumes and snapper etc (custom fstab).
Specially for this topic, one could use snapper’s diff option to see what has changes in /etc/NetworkManager/system-connections/ from one snapshot to the other. Also available via GUI in YaST. See man snapper. snapper status [options] number1..number2