Network gone after todays update

[moserwi]

Hi,
I am facing network troubles within the last week.

whatever I configured... br0 or eth0 at /etc/network or systemd-networkd ...
first of all the DNS-resolution vanished but a dig got the correct data but a ping URL failed.

Systems 12.5:
radxa Rock 5b with upgraded bullseye image to bookworm. Kernel 5.10
rockpro64 with native bookworm, Kernel 6.1.85-1

Yesterday and this morning everything was fine and the sbc Rock 5b remained untouched
Obviously after an unattended-upgrade the network was gone

an ifconfig shows the br0 without static IP, the NIC seems to be at enP..scrap
ls /sys/class/net shows br0 lo and enP..scrap

Folks, I do have no Idea what to do now!
Ok, will try to remove the defs for networkd and implement /etc/network again... will eport effort

I think there is a serious bug in the latest updates!!!

About me:
Linux since 2000 former RedHat, Centos then debian only.
Working on sbc's with lxc since 2016

[moserwi]

Switched networkd from br0 to enP..scrap
furtermore I changed /etc/default/lxc.net from
USE_LXC_BRIDGE="true"
to
USE_LXC_BRIDGE="false"

then switched back to br0

looks like the net is here again. BUT I don't think this was the reason.
Will post further progress of the task.

[Aki]

Hello,

Are you running an OEM Debian release from the manufacturer of the single board computer (radxa Rock 5b) with arm architecture ?

What is the URL from which you have downloaded the ISO of the operating system?

[sinterva]

I have no idea if this is related to you, but the latest kernel killed my wifi, so I put the update on hold.

viewtopic.php?t=158892

[moserwi]

Downloaded it from https://github.com/radxa-build/rock-5b/ ... b39.img.xz and dist-upgraded to bookworm. (kernel 5.10!)
I had no issues with the image form 09/2023 until last week!

We tried another Image from https://github.com/inindev/rock-5b/releases (debian bookworm v12-6.7-rc7 for the rock-5b)
Issues... defined br0 with systemd-networkd
We do not have an internal dhcp-server and do get an IP 169.254.188.136 which is registered in the USA??? for enP4p65S0 which should not get an IP as it is bound to the br0!!!!
How can this happen??? Never ever had this problem before...

[Aki]

Hello,

Downloaded it from https://github.com/radxa-build/rock-5b/ ... b39.img.xz and dist-upgraded to bookworm. (kernel 5.10!)
I had no issues with the image form 09/2023 until last week!

We tried another Image from https://github.com/inindev/rock-5b/releases (debian bookworm v12-6.7-rc7 for the rock-5b)
Issues... defined br0 with systemd-networkd

It looks like not the official Debian release, but a Redaxa version. Perhaps you need to contact the Redxa community forum.

Moved to "Off-Topic" sub-forum.

[moserwi]

And the same problem with an rockpro64 and native debian-installer? How come?

[Aki]

Hello,

And the same problem with an rockpro64 and native debian-installer? How come?

Here are some thoughts:

1. you might consider that what you are reporting is not dependent on your operating system, as it affects different SBCs with different operating systems.
2. you might consider checking your network configuration for both clients and servers.
3. note that systemd-resolved is not the default service for name resolution in current Debian stable.
4. you wrote in the first post about lxc configuration, which is not usually used for single board computer (SBC) appliances.

Anyway, it's quite difficult to help without more detailed information about your hardware/software/network configurations.

Hope this helps.

[Linuxgaming1824]

If you're using a static or manual configuration for your networking, you're going to want to learn about the changes that have been implemented affecting your configuration.

https://wiki.debian.org/NetworkInterfaceNames
https://wiki.debian.org/NetworkConfiguration

O.O look at this I totally forgot this was possible...

THE ORIGINAL SIMPLE SCHEME

Back in the nineties, eth0, eth1, etc were simply assigned by the kernel.

Why it was abandoned

At least in theory, if module probes completed in a different order, eth0 and eth1 might switch places on successive boots. As boot processes became less linear and interfaces became more hotpluggable this became more of a concern.

How to get it back

If you wipe out all other name-assignment mechanisms then you'll be left with this one.

The simple way of disabling the whole current interface naming scheme (which you might want to try for one-off testing) is just to boot with the kernel parameter net.ifnames=0, which can be set in an interactive grub session at boot or made persistent by editing /etc/default/grub and running update-grub.

[moserwi]

looks like the discussion is a little bit off topic. What we found is that a non systemd daemon called dhcpcd is installed with the debian-installer and the radxa image and that it effects systemd-networkd and /etc/network definitions of static ip's refusing correct DNS resolutions. Since debian 12.5 something strange happened with the network definitions and the only may I can describe it is: "stoned kids" on the work.

It is time to skip all different network definitions (I know 4 ways) and to reduce it to systemd-networkd in future BUT NOT WITH A 12.5 VERSION. With 13.0 this might be OK!

[Aki]

Hello,

Perhaps it is worth nothing that in Debian the systemd-networkd service is not installed by default (even if it can be manually installed).

Debian installer usually installs by default other DHCP clients.

The disk image of your operating system is not built using the Debian installer, of course.