Why Your Linux Network Interface Name Changed After Reboot — and How to Fix It

ByPriya Nair

Why “predictable” doesn’t mean permanent

If you rebooted a Linux server and found it off the network, a silently renamed interface is a likely cause. Not a glitch — just the predictable naming scheme working as designed, only against you.

Systemd introduced predictable interface naming in v197 (2012). Before that, names like eth0 were assigned in whatever order drivers happened to initialise at boot. On a multi-NIC machine that order wasn’t guaranteed, so eth0 and eth1 could swap between reboots. Firewall rules and scripts keyed to an interface name would silently apply to the wrong device. The fix was to derive the name from the physical location of the hardware in the system.

The problem is that “physical location” is partly something the firmware tells the OS — and firmware changes.

How a name like enp1s0 is built

Break down enp1s0:

  • en — Ethernet (wireless uses wl)
  • p1 — PCI bus 1
  • s0 — slot 0 on that bus

Other prefixes you will encounter: eno (on-board device with firmware-supplied index), ens (PCIe hotplug slot), enx followed by the MAC address. udev works through a priority list to pick a naming scheme:

  • Firmware/BIOS on-board index — e.g. eno1
  • Firmware/BIOS PCIe hotplug slot index — e.g. ens1
  • Physical PCI location — e.g. enp2s0
  • MAC address — e.g. enx78e7d1ea46da
  • Classic kernel naming as a last resort — e.g. eth0

It uses whichever level has reliable data. Change what the firmware reports, and the level it lands on may change too — and the name changes with it.

Four things that cause a rename

  • Firmware or BIOS update. The naming scheme reads PCI device metadata that the firmware supplies. A BIOS update can alter the reported slot index, which feeds directly into the name.
  • systemd or udev version bump. The naming algorithm has changed across systemd releases. A distribution upgrade can apply a newer scheme to the same hardware and produce a different name.
  • Adding or removing PCIe hardware. A new card can shift bus numbering for existing devices, renaming them as a side effect.
  • Kernel driver update. Less common, but a driver change can alter how a device is enumerated on the PCI bus.

Machines that rarely reboot are most exposed. Two years of uptime can quietly accumulate a BIOS flash, a kernel update, and a systemd bump — all of which might shift the naming logic. The rename only surfaces on the next boot.

The Netplan fix: match by MAC, pin the name

On Ubuntu (and other systems using Netplan), you can match an interface by its MAC address and assign it whatever name you choose. That name survives any future kernel or firmware change:

network:
  version: 2
  ethernets:
    lan:
      match:
        macaddress: "aa:bb:cc:dd:ee:ff"
      set-name: eth0
      dhcp4: true

Three things worth knowing about this config:

  • The key under ethernets: — lan here — is just an internal Netplan label. The interface will appear on the system as eth0.
  • Find the MAC address with ip link show. It is on the link/ether line for each device.
  • Test before rebooting: sudo netplan try applies the config and rolls it back automatically after 120 seconds if you do not confirm.

The udev alternative

Not on a Netplan system? A udev rule does the same job at a lower level and works on any systemd-based distro. Create /etc/udev/rules.d/70-persistent-net.rules:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", ATTR{type}=="1", NAME="eth0"

ATTR{type}=="1" selects Ethernet devices (ARPHRD_ETHER). Reboot to apply. Custom udev rules run before the automatic naming scheme, so this wins. This approach also works if you are on a distro that uses NetworkManager rather than networkd as its backend.

What about net.ifnames=0?

Adding net.ifnames=0 to the kernel command line reverts everything to classic eth0, eth1 style naming. On a single-NIC machine that is harmless. On anything with multiple interfaces, you are back to driver-initialization order — the exact problem predictable naming was built to solve. MAC pinning is safer because it ties each name to specific hardware, not to how many NICs happen to be present at boot time.

Recovering when the machine is already offline

You need console access — physical, IPMI, or serial. Once you have a shell:

ip link show

This lists every interface with its current kernel-assigned name and MAC address. Update your Netplan config or udev rule to match on the MAC and pin a stable name, then reboot.

journalctl -b 0 | grep -i renamed often shows a udev log entry recording exactly what got renamed during the failed boot — useful if you want to understand what changed and why.

Sources

Similar Posts