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”.
Good lord, this is a top tier meme!
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
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
Love the explainer to the meme.
Keep up the good work!
It’s amazing how many linux problems stem from ‘Redhat, however, found this solution too simple and instead devised their own scheme’. Just about every over complex, bloated bit of nonsense we have to fight with has the same genesis.
What I really don’t understand is why distro maintainers feel the need to actually go along with these changes. Like, sure, if this predictable interface naming thing worked as intended, I can definitely see how it can be useful for server administrators. You could just hardcode the automatic interface names instead of assigning them manually in /etc/mactab. But why would the rest of us ever need this? Most personal machines have at most one wifi card and one ethernet device, so wlan0 and eth0 are perfectly predictable. And even if you have multiple wifi or ethernet adapters, your networking is probably handled by network-manager, so you never actually have to put interface names into config files. Why force enterprise-grade bloat on users who just want a simple desktop experience?
As to why distro maintainers go along, if you had to vet every time the network stack updated and make sure it doesn’t break your custom solution to predictable naming, you’d probably just go along with it and let anyone that needed it devise and maintain their own solution. 99% of users won’t worry about it.
Personally I’d do away with NetworkManager too and just configure the interfaces directly, but that might just be me being old and grumpy!
I think most distros go along because their upstream did. There are comparatively few ‘top level’ distributions, the main ones (by usage) being Redhat and Debian. Most everything else branches from those. Redhat’s got enough clout on the market that there’s a sort of pull towards complying with it just to not be left put.
I use Debian, but I think they’re crazy for swallowing everything Redhat pushes, they could easily stick to the cleaner options and have a better system for it. At least they let you opt out of systemd, so life is a little more tolerable.
I’d do away with network-manager on a stationary system too, but I’m on a laptop, and unless there’s some trick I don’t know about, configuring wifi by hand for every new network I come across sounds like a bit of a pain. Especially for corporate/institution network that use fancy things like PEAP
Personally I’d do away with NetworkManager too and just configure the interfaces directly
Connman and iwd have nice graphical interfaces btw. I got that route after nm disbehaved and i couldn’t figure out why (same for systemd and s6/dinit after systemd-dnsd threw a fit).
He’s definitely off my Christmas card list. He seems desperate to leave a legacy, but he keeps trying to turn Linux into windows instead.
You’re not wrong. But generally the idiocy is in response to beserkeness elsewhere, madness follows…
I’m with our binary friend; the systems they try to replace tend to be time tested, reliable and simple (if not necessarily immediately obvious) to manage. I can think of a single instance where a Redhat-ism is better, or even equivalent, to what we already have. In eavh case it’s been a pretty transparent attempt to move from Embrace to Extend, and that never ends well for the users.
I can think of a single instance where a Redhat-ism is better
I don’t know if it would be accurate to call it a redhat-ism, but btrfs is pretty amazing. Transparent compression? Copy-on-write? Yes please! I’ve been using it for so long now that it’s spoiled me lol. Whenever I’m on an ext4 system I have to keep reminding myself that copying a huge file or directory will… you know… actually copy it instead of just making reflinks
so does RPM.
Careful. Jeff’s format gives us really great advantages from an atomic package that we don’t have elsewhere. THAT, at least, was a great thing.
Lennart’s Cancer, though, can die in a fire.
Also, canonical decided to try and solve the same ‘problem’ in a different, equally convoluted way.
It’s amazing how many linux problems stem from ‘Redhat, however, found this solution too simple and instead devised their own scheme’. Just about every over complex, bloated bit of nonsense we have to fight with has the same genesis.
Ansible can be heard mumbling incoherently and so, so slowly, from the basement.
Remember who saw apt4rpm and said “too fast, too immune from python fuckage, so let’s do something slower and more frail”. twice.
I won’t hear any sass about Ansible. It doesn’t scale up to infinity but it’s the best there is at what it’s good at (modular, small scale declarative orchestration)
You can totally can scale Ansible and especially Ansible pull. It will work with thousands of VMs and can be used with other tools to completely automate deployments.
I do use Ansible, partly because it’s easier to tell people that’s how you do it rather than “I wrote a shell script, it took half the time to write, it’s 20% the size and runs several times faster”. To be fair to Ansible, if you’re configuring a number of servers at the same time, it’s not too bad speedwise as it’ll do batches of them in parallel. Configuring one server at a time is agony though.
To me it seems they followed the hdd UUID style, rather than sda0 or hda0 that can change at boot you now have a fixed UUID to work with. I can see this being important on larger server networks
But the SSD/HDD solution doesn’t replace /dev/[s|h]da# entirely, just adds a consistent way to set them in configs like fstab. You can still use the old device names so working with them at the command line is still easy for the most part.
Having consistent interface names on servers that have several is useful, but we already had that option. The interface names they generate are not only hard to remember, but not terribly useful as they’re based on things like which PCI slot they’re in, rather than what their purpose is. You want interface names like wan0 and DMZ, not enp0s2. Of course, you can set it up to use useful names, but it’s more complicated than it used to be, so while the systemd approach looks like a good idea on the surface, it’s actually a retrograde step.
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.
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.
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.
