Context for newbies: Linux refers to network adapters (wifi cards, ethernet cards, etc.) by so called “interfaces”. For the longest time, the interface names were assigned based on the type of device and the order in which the system discovered it. So, eth0, eth1, wlan0, and wwan0 are all possible interface names. This, however, can be an issue: “the order in which the system discovered it” is not deterministic, which means hardware can switch interface names across reboots. This can be a real issue for things like servers that rely on interface names staying the same.

The solution to this issue is to assign custom names based on MAC address. The MAC address is hardcoded into the network adaptor, and will not change. (There are other ways to do this as well, such as setting udev rules).

Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve while making it much harder to type and remember interface names.

To disable predictable interface naming and switch back to the old scheme, add net.ifnames=0 and biosdevname=0 to your boot paramets.

The template for this meme is called “stop doing math”.

    • renzev@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      10 months ago

      Thanks, glad you like it! I spent quite some time re-making the template from scratch in inkscape, because the original meme din’t have enough space for the text

  • bitwaba@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    10 months ago

    “the order in which the system discovered it” is not deterministic

    This is the same problem they had with hard drive names and it seems to have been solved in a sensible way, i.e. /dev/sda still points to the first disk detected by the system, but you can look look in /dev/disk/by-path (or by-uuid, etc) to see the physical address of the devices on the system and what they are symlinked back to, and set your fstab or mdadm arrays to be configured based on those unique identifiers instead.

    So, I guess what I’d like to know is why hasn’t this been solved the same way? When you boot up they should present every hard wired Ethernet port as ethX, and the hardware address interface should be present as well but aliased back to the eth. Then you can build the your network configs based on either one.

    Shouldn’t be that hard right?

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      0
      ·
      10 months ago

      But nobody uses /dev/sdX anymore (not after they wipe the wrong disk once anyway). They either use logical UUIDs or hardware WWN/serial.

      • renzev@lemmy.worldOP
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        10 months ago

        idk man I use /dev/sdX when running commands interactively and PARTLABELs in my /etc/fstab. All those letters and numbers in UUIDs are too much for my monkey brain to handle lol

      • bitwaba@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        10 months ago

        Yeah, the point is “you can use eithee one”, instead of “we made the choice for you”

      • partizan@lemm.ee
        link
        fedilink
        arrow-up
        0
        ·
        10 months ago

        Taking a sip of Rum and chuckles at the look on the name of my OS partition: /dev/mapper/vg-root and /dev/mapper/vg-home 🙃

    • thisisnotgoingwell@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      10 months ago

      As a data center engineer of 10+ years, I struggled to understand this at first. In my world, the hardware does a POST before the OS boots and has an inventory of what hardware components are available, so it shouldn’t matter in what order they are discovered, since the interface names should make a correlation between the interface and the pcie slot that NIC exists in.

      Where the water gets muddled is in virtualized servers. The NICs no longer have a correlation to a specific hardware component, and you may need to configure different interfaces in the virtualized OS for different networks. I think in trying to create a methodology that is agnostic to bare metal/virtualized OSs, it was decided that the naming convention should be uniform.

      Probably seems like bloat to the average admin who is unconcerned with whether these NICs are physical or virtual, they just want to configure their server.

    • jj4211@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      10 months ago

      And at least in some distributions, they do exactly that, a number of aliases for the same interface. And you can add your own.

  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    10 months ago

    me setting my interface into monitor mode manually because it can’t handle being split into mon and managed.

  • Badabinski@kbin.earth
    link
    fedilink
    arrow-up
    0
    ·
    10 months ago

    I always just derive the interface name from first principles. Like, if I want to know which interface will be used to get out to the internet in a script, I’ll just find the one that’s L2 adjacent with the default gateway. If I’m given an egress or cidr, I’ll just find the interface that has that IP. Modern iproute2 has a JSON output option which makes getting this information pretty trivial. Doing that means that it doesn’t matter what scheme your OS is using.

    I personally prefer the persistent names for Ethernet, although I don’t like them for WiFi. Luckily, it seems like my wireless adapter always just ends up as wlan0. I’m not sure why that’s the case, but it works out well in the end for me.

    • Murdoc@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      10 months ago

      I came here to say this. I don’t really do networking so I don’t have much care for this issue, but the clarity of the explanation was enjoyable. Plus I learned a couple of little things too.

  • maxinstuff@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    10 months ago

    Here I am on a laptop with no ethernet ports (probably works over USB-C? No idea, haven’t tried), and a single wifi adapter. Guess I’ll give it a try:

    ip link show

    What I expected

    wlan0

    What I got

    wlp242s0

    Neat 👍 😎 👍

  • Ananace@lemmy.ananace.dev
    link
    fedilink
    arrow-up
    0
    ·
    10 months ago

    The predictable interface naming has solved a few issues at work, mainly in regards to when we have to work with expensive piece-of-shit (enterprise) systems, since they sometimes explode if your server changes interface names.
    Normally wouldn’t be an issue, but a bunch of our hardware - multiple vendors and all - initialize the onboard NIC pretty late, which causes them to switch position almost every other boot.

    I’ve personally stopped caring about interface names nowadays though, I just use automation to shove NetworkManager onto the machine and use it to get a properly managed connection instead, so it can deal with all the stupid things that the hardware does.

    • MonkderDritte@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      10 months ago

      with expensive piece-of-shit (enterprise) systems, since they sometimes explode if your server changes interface names.

      Glass canons are brittle, huh?

    • corsicanguppy@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      10 months ago

      expensive piece-of-shit (enterprise) systems, since they sometimes explode if your server changes interface names.

      At no time in the past 25 years with Medium Iron have I seen something blow up on a reboot because an interface comes up late. We’d solved the issue of unreliable init order in 1998 - RH6? Zoot? Compaq, Supermicro, even embedded stuff on was-shit/still-shit gigabyte mobos. /etc/udev/rules.d handled this eliably, consistently and perfectly. Fight me.

  • Arthur Besse@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    10 months ago

    Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve

    I somehow first read “Redhat” as “Reddit” in this sentence, and so was briefly thinking that perhaps this bad idea originated there 😂

    • renzev@lemmy.worldOP
      link
      fedilink
      arrow-up
      0
      ·
      10 months ago

      Thanks! I love this format so much. I can’t find it now, but one of my favourite memes in this genre was something like this:

      STOP DOING

      • Tasks were never meant to be completed
      • Years of working, but there’s STILL MORE SHIT TO DO
      • Wanted to get some work done anyway, for a laugh? We had a tool for that: it was called SIMULATION GAMES
      • “Please let me sacrifice a third of my life to justify my existence. Please let me spend eight hours a day working just to be able to do it again the next day” - statements dreamt up by the utterly deranged

      Look at what people have been demanding our respect for all this time, with all the schedules and todo lists we have built for them:

      These are REAL things done by REAL people

      <Pictures of gmail, microsoft outlook, and some TODO list app>

      They have played us for absolute fools

  • onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    10 months ago

    To disable predictable interface naming and switch back to the old scheme, add net.ifnames=0 and biosdevname=0 to your boot paramets.

    What is the old scheme? This?

    The solution to this issue is to assign custom names based on MAC address. The MAC address is hardcoded into the network adaptor, and will not change. (There are other ways to do this as well, such as setting udev rules).

    Does that mean that until you name something it’s unusable?

    Anti Commercial-AI license

    • renzev@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      10 months ago

      No, the “old scheme” is the one that assigns wlan0, wlan1, eth0, eth1, and so on by default. I would say these names are pretty usable.

      The part you quoted is what you need to do if you specifically need to be sure that a specific card gets a specifc name 100% of the time. You don’t have to bother with it unless you have a reason to.

  • orwellianlocksmith@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    10 months ago

    I have no idea at all of what this is about but I feel strongly that OP is right and we must urgently fix this disgusting problem we are facing with the interfaces. Get em, OP, get the bastards. Solidarity