this post was submitted on 27 Jun 2024
929 points (96.7% liked)

linuxmemes

20880 readers
6 users here now

I use Arch btw


Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 30 points 5 months ago (4 children)

"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?

[–] [email protected] 24 points 5 months ago (1 children)

Cries in nvme1n1p6, which is my current OS partition.

[–] [email protected] 6 points 5 months ago (1 children)

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 🙃

[–] [email protected] 1 points 5 months ago

That's because you're using LVM though. In most distros you could also use something like:

/dev/vg/root

[–] [email protected] 8 points 5 months ago (2 children)

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

[–] [email protected] 10 points 5 months ago* (last edited 5 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

[–] [email protected] 7 points 5 months ago* (last edited 5 months ago)

Yeah, the point is "you can use either one", instead of "we made the choice for you"

[–] thisisnotgoingwell 7 points 5 months ago* (last edited 5 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.

[–] [email protected] 3 points 5 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.