169

When I run ifconfig -a, I only get lo and enp0s10 interfaces, not the classical eth0

What does enp0s10 mean? Why is there no eth0?

3
  • 14
    ifconfig is deprecated. Think about moving to ip from iproute2 soon.
    – solsTiCe
    Jun 13, 2015 at 8:21
  • 1
    As the answer says it's a change in systemd. To get your eth0 back use the kernel option net.ifnames=0 biosdevname=0 (see this thread). Using ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rule in below answer didn't work in Debian 10 (Buster)
    – MrCalvin
    Jun 2, 2019 at 10:22
  • @MrCalvin : the ln -s ... should be updated, see below
    – serv-inc
    Dec 16, 2020 at 10:44

5 Answers 5

235

Answer on "What does enp0s10 means?" question:

enp0s10:
| | |
v | |
en| |   --> ethernet
  v |
  p0|   --> bus number (0)
    v
    s10 --> slot number (10)

Source: udev-builtin-net_id.c on GitHub

4
  • 24
    Came looking for this.
    – ffledgling
    Mar 7, 2017 at 8:38
  • 10
    Since there is no ...fN part at the end of the NIC name, we can deduce that the function number is 0. After translating the numbers to hexadecimal (10 = "a" in hex), we know that enp0s10 means PCI device ID 00:0a.0.
    – telcoM
    Apr 13, 2019 at 6:13
  • 2
    There’s also freedesktop.org/software/systemd/man/… Dec 8, 2020 at 20:21
  • 2
    This explains eno (onboard) enp (pci) and enx (mac.) But it does not explain the name end0. What does the d in end0 stand for?
    – Bram
    May 20, 2023 at 17:47
118

That's a change in how now udevd assigns names to ethernet devices. Now your devices use the "Predictable Interface Names", which are based on (and quoting the sources):

  1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
  2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
  3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
  4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
  5. Classic, unpredictable kernel-native ethX naming (example: eth0)

The why's this changed is documented in the systemd freedesktop.org page, along with the method to disable this:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

or if you use older versions:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
5
  • 20
    Following the freedesktop,org link, the main point is: The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth" to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications...
    – lepe
    Oct 17, 2016 at 2:43
  • This also applies to docker images. So trying to setup a network bridge between 2 docker networks caused problems 2 years ago because the network ports could be reversed on next boot. an impossible situation for a bridge device.
    – U.V.
    Dec 16, 2020 at 12:01
  • 5
    funny enough, the "predictable name" of my ethernet device changed from enp5s0 to enp3s0 after a bios upgrade, rendering all my network configurations worthless...
    – GaspardP
    Jan 16, 2022 at 21:11
  • @GaspardP I would say that that's a bug in your bios, how the device enumeration order on chip changed?!
    – Braiam
    Jan 17, 2022 at 13:55
  • Absolutely agree, this should not be common - the bus ids should not change and names should be predictable. I suspect this happened because my hardware was new and the bios was not yet able to detect everything connected. After upgrading, it probably discovered new devices. It might still be worth aliasing devices for some people, especially in the context of restoring a system backup onto different hardware.
    – GaspardP
    Jan 17, 2022 at 18:46
44

As mentioned above, enp0s10 refers to ethernet (en), prefix 0 (p0), slot 10 (s10).

The bus number, device number, and function number are pulled from the Bus Device Function (BDF) notation for PCI devices to create the prefix, slot, and function portions of the Predictable Network Interface Name (PNIN).

If the function is 0, the f0 portion is sometimes omitted. I changed the prefix from p0 to p4, and the function from f0 to f1, for clarity in this example. BDF uses hex values which get converted to decimal values in the PNIN.

Expanding on the answer posted by DIG mbl:

enp4s10f1                        pci 0000:04:0a.1
| | |  |                                |  |  | |
| | |  |                   domain <- 0000  |  | |
| | |  |                                   |  | |
en| |  |  --> ethernet                     |  | |
  | |  |                                   |  | |
  p4|  |  --> prefix/bus number (4)   <-- 04  | |
    |  |                                      | |
    s10|  --> slot/device number (10) <--    10 |
       |                                        |
       f1 --> function number (1)     <--       1

https://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

I came across a device with a u7 at the end, for USB port. Some of the different label possibilities are included in this documentation on predictable network interface device names.

A second example for the case where the PCI domain is something other than 0 (P stands for PCI geographical location):

P1enp4s10f1                        pci 0001:04:0a.1
| | | |  |                                |  |  | |
P1| | |  |  --> PCI geo loc/domain <-- 0001  |  | |
  | | |  |                                   |  | |
  en| |  |  --> ethernet                     |  | |
    | |  |                                   |  | |
    p4|  |  --> prefix/bus number (4)   <-- 04  | |
      |  |                                      | |
      s10|  --> slot/device number (10) <--    10 |
         |                                        |
         f1 --> function number (1)     <--       1
0
7

You can use

net.ifnames=0

in kernel command line arguments and your interface name will be called eth0 again.

4
  • Can you elaborate on this? Where are the kernel command line arguments specified? Aug 13, 2022 at 8:20
  • 1
    add this to GRUB_CMDLINE_LINUX_DEFAULT section in /etc/default/grub. then run 'update-grub'. Aug 14, 2022 at 13:10
  • This is terrible advice. It broke my system and is not a good habit.
    – ohbrobig
    Jan 25 at 8:42
  • how does it broke your system? you always can revert it by edit the kernel command line (press 'e' ) at boot time Jan 28 at 16:09
2

To quote the full text on disabling linked by @Braiam:

I don't like this, how do I disable this?

You basically have three options:

  1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link
  2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See systemd.link(5) for more information.
  3. You pass the net.ifnames=0 on the kernel command line

TL;DR: it has been renamed to 99-default.link

1
  • This doesn't work (any more?) in Fedora 39; with method 1 I get "wlan0" back but "eth0" remains a mangled name. Method 3 works, but feels less desirable somehow... Dec 28, 2023 at 20:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .