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.