David C Rankin <drankinatty@gmail.com> wrote:
On 6/29/25 12:19 AM, David C Rankin wrote:
Again, manually bringing up the interface and restoring the default route and starting dhcpd4 and all is fine. At least in my mind, that pretty much leaves a problem created by the recent "churn" in the firmware and some impact that has had at least on the Realtek r8169 binary parts.
Is it worth downgrading the firmware to check?
Okay, I give... It's not the firmware (sorry gromit). I downgraded the firmware:
# pmu *firmware*20250613*zst loading packages... warning: downgrading package linux-firmware (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-amdgpu (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-atheros (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-broadcom (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-cirrus (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-intel (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-mediatek (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-nvidia (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-other (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-radeon (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-realtek (20250627-1 => 20250613.12fe085f-9) warning: downgrading package linux-firmware-whence (20250627-1 => 20250613.12fe085f-9) resolving dependencies... looking for conflicting packages...
Packages (12) linux-firmware-20250613.12fe085f-9 linux-firmware-amdgpu-20250613.12fe085f-9 linux-firmware-atheros-20250613.12fe085f-9 linux-firmware-broadcom-20250613.12fe085f-9 linux-firmware-cirrus-20250613.12fe085f-9 linux-firmware-intel-20250613.12fe085f-9 linux-firmware-mediatek-20250613.12fe085f-9 linux-firmware-nvidia-20250613.12fe085f-9 linux-firmware-other-20250613.12fe085f-9 linux-firmware-radeon-20250613.12fe085f-9 linux-firmware-realtek-20250613.12fe085f-9 linux-firmware-whence-20250613.12fe085f-9
Total Installed Size: 349.27 MiB Net Upgrade Size: -1.04 MiB
and it failed in the exact same way, enp5s0 is brought up as normal and then enp5s0 is mysterously taken back down. I'm all out of ideas at this point. I can't even think of anything else that changed between 6/25 and 6/28 except the kernel, and that wouldn't also effect booting LTS?
I went ahead and updated to current (pacman -Syu) and the problem persists. So the easiest workaround at this point is to write a short script that runs after boot to bring the interface back up, add the default route and start dhcpd4, e.g.
#!/bin/sh
## bring up the interface ip link set enp5s0 up
## set default route ip route add default via 192.168.6.11 dev enp5s0
## start dhcpd4 systemctl start dhcpd4
I guess systemd has a after-boot type service that could call the script. Anybody have any other guesses to investigate at why the interface gets taken back down on boot?
-- David C. Rankin, J.D.,P.E.
1) What you need the firmware for? Can you leave out only the firmware package you are actually using? Just trying to narrow the factors involved. 2) Can you share your network config? 3) systemd has debugging features. Which I am not familiar with. Perhaps using them could reveal why the interface is taken down. 4) Can you roll backward? I mean, not only systemd. Not only the firmware. Not only the kernel. Just roll back to a full state that was prevoiusly working. -- u34