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”.

  • AnanaceA
    46·
    5 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.

    • corsicanguppy@lemmy.caEnglish
      6·
      5 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 reliably, consistently and perfectly. Fight me.

      • AnanaceA
        2·
        5 months ago

        You’re lucky to not have to deal with some of this hardware then, because it really feels like there are manufacturers who are determined to rediscover as many solved problems as they possibly can.

        Got to spend way too much time last year with a certain piece of HPC hardware that can sometimes finish booting, and then sit idle at the login prompt for almost half a minute before the onboard NIC finally decides to appear on the PCI bus.
        The most ‘amusing’ part is that it does have the onboard NIC functional during boot, since it’s a netbooted system. It just seems to go into some kind of hard reset when handing over to the OS.

        Of course, that’s really nothing compared to a couple of multi-socket storage servers we have, which sometime drop half the PCI bus on the floor when under certain kinds of load, requiring them to be unplugged from power entirely before the bus can be used again.

    • MonkderDritte@feddit.de
      3·
      5 months ago

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

      Glass canons are brittle, huh?