Network Interface Down After Reboot – Real Fixes

1. NetworkManager vs systemd-networkd Conflict

If you've got both NetworkManager and systemd-networkd running, they'll fight over the interface. On reboot, whichever one loses the race leaves the interface down. I see this most on Ubuntu 22.04+ and Debian 12 where you upgrade from an older install. What's actually happening here is NetworkManager brings the interface up first, then systemd-networkd takes over and drops it—or vice versa. The log shows the interface flapping up then down in journalctl -u NetworkManager.

The fix: Decide which one you want and stop the other. If you're using NetworkManager (common for desktops and laptops), run:

sudo systemctl stop systemd-networkd
sudo systemctl disable systemd-networkd
sudo systemctl mask systemd-networkd  # Prevents any start, even by dependencies

If you're using systemd-networkd (common for servers with static configs), stop NetworkManager:

sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl mask NetworkManager

The reason mask matters here is because NetworkManager has socket activation—a symlink in /lib/systemd/system/ can re-enable it on boot if you only disable it. Masking replaces the unit file with a symlink to /dev/null, so nothing can start it.

2. Missing or Incorrect Netplan / interfaces Config

On Ubuntu (since 17.10) and some Debian spins, networking is configured via Netplan. The config lives in /etc/netplan/*.yaml. After a reboot, if the interface is down, nine times out of ten the YAML file is either misnamed, has a syntax error, or references the wrong interface name.

I helped a guy last week whose 01-netcfg.yaml had a tab instead of spaces. YAML doesn't tolerate tabs. netplan apply ran fine because it only validated the current state, but on reboot the parser choked.

The fix: Check your Netplan config explicitly:

sudo netplan try   # This validates AND applies temporarily. If it breaks, it reverts in 120 seconds.
sudo netplan apply

If you get errors, look for indentation issues. Use cat -A /etc/netplan/01-netcfg.yaml—tabs show as ^I. Replace them with two spaces.

Also verify the interface name matches what ip link shows. Modern kernels use predictable names like enp3s0 or ens33, not eth0. If your config says eth0 but the actual interface is enp3s0, it won't come up. Fix it:

network:
  version: 2
  ethernets:
    enp3s0:   # not eth0
      dhcp4: true

For older Debian systems still using /etc/network/interfaces, check for a missing auto line. Without auto eth0 (or whatever the interface is), ifup -a won't bring it up on boot. The config should look like:

auto eth0
iface eth0 inet dhcp

3. Kernel Module Not Loading or Firmware Missing

This one is rarer but hits specific hardware. I've seen it on Realtek RTL8111/8168 and some Broadcom chips. The NIC driver isn't loaded at boot because the kernel module either isn't built, is blacklisted, or the firmware file is missing.

How to check: after reboot, run lspci -k | grep -A 3 "Ethernet". If it shows Kernel driver in use: r8169 but the interface is down, the driver might be loaded but the card needs a firmware blob. Check dmesg | grep -i firmware for lines like Direct firmware load for rtl_nic/rtl8168f-2.fw failed. That means the firmware package isn't installed.

The fix: Install the firmware package for your distro:

# Debian/Ubuntu
sudo apt install firmware-realtek

# RHEL/CentOS/Fedora
sudo dnf install linux-firmware

If the driver isn't loaded at all, check /etc/modprobe.d/blacklist.conf—someone might have blacklisted it. Remove or comment out the relevant line. Then regenerate initramfs:

sudo update-initramfs -u   # Debian/Ubuntu
sudo dracut --force        # RHEL/Fedora

The reason you need to rebuild initramfs is that the driver is loaded before the root filesystem is mounted. If the blacklist is in the initrd, it won't load the module until after boot, and by then the network bring-up scripts have already failed.

Quick-Reference Summary