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.
