This is a boot-time race condition. The NIC eno1np0 isn't initialized by the kernel yet when ifupdown2 runs, but it's available moments later, which is why systemctl restart networking fixes everything.
The log confirms this: all NICs on PCIe bus 6 (eno2np1, eno3np0) and bus 112 (ens8191f*) enumerate in the netlink dump, but eno1np0 is completely absent. It's likely on a different PCIe bus/slot that takes longer to probe.
The "random DHCP address" is probably because eno1np0 is your actual uplink to the LAN, the bridge gets its static IP but has no physical path to the gateway without that port, and the NIC may later grab a DHCP lease outside the bridge context.
Check for recent kernel/firmware updates that shifted initialization timing:
# Recent apt activity
grep -E 'pve-kernel|linux-image|firmware|ifupdown' /var/log/apt/history.log
# Or more broadly
cat /var/log/apt/history.log | tail -80
Also check dmesg for how late eno1np0 initializes:
dmesg | grep -i eno1np0
dmesg | grep -i 'pci.*net\|eth\|rename'
Fix the Race Condition, make the networking service wait for the device via a systemd drop-in:
systemctl edit networking.service
Add:
[Unit]
Wants=sys-subsystem-net-devices-eno1np0.device
After=sys-subsystem-net-devices-eno1np0.device
This tells systemd to wait for the kernel to register eno1np0 before starting networking.service. If the NIC appears within the default systemd device timeout (typically 90s), networking proceeds normally. If the NIC is truly dead/missing, the boot will eventually continue without it (same as today, but with a delay).
Alternative, if you'd rather not delay the whole networking service, add a wait loop directly in /etc/network/interfaces on the vmbr0 stanza:
iface vmbr0 inet static
...
pre-up /bin/bash -c 'for i in $(seq 1 30); do [ -d /sys/class/net/eno1np0 ] && break; sleep 1; done; true'
This polls for up to 30 seconds for eno1np0 to appear before the bridge tries to enslave it. The trailing ; true ensures the bridge still comes up (degraded) if the NIC never shows.
Verify after applying either fix, test with a reboot. You should see eno1np0 in the bridge and a clean exit status 0 in /var/log/ifupdown2/.
Most likely a pve-kernel or pve-firmware update changed PCIe/NIC driver probe timing. This is a common class of issue after kernel bumps, NICs that were "fast enough" before suddenly aren't. The systemd device dependency is the robust, proper fix because it doesn't rely on timing assumptions.
