That happens on my HEDT. After a clean install, I sometimes need to swap the names of eth0 and eth1.
Ed

I thought the idea between the new network names was to make them "predictable". The basic concept is that the linux system would inherit whatever chip ID was set in firmware. So for multi-NIC systems this would mean that the vendor could physically label ports 1,2,3 and 4 and be confident that the linux OS would obey that layout.

The problem that they refused to acknowledge is that naming conventions change from one vendor to the next and that not all vendors bother to provide those ids in the firmware. So now instead of seeing eth0,1,2,3 on EVERY motherboard you see enp4s0 for one board, enxxxxxxx on another, and so on. There's a waterfall system in place to so if it doesn't find a spec it defaults to something basic. As an absolute last resort it can be configured to use "legacy" ethX names.


They tried to make the network names predictable but in the end it only made the problem worse... Install a systemd distro on a new piece of hardware and you literally don't know what to expect until it boots up.

I saw a debian user on a local LUG mailing list go on an epic rant about that earlier this year. He has 2 different workstations and the NIC naming conventions are completely different. 15 years of scripts he wrote that used to work are suddenly worthless because someone thought they could fix a "problem".

5 members found this post helpful.

That's a sharp obvservation which can be expanded to apply to the hot mess that is the systemd project, IMNSHO.
Realistically, he probably should've used a variable NIC name if the scripts are that complicated.

But back on point, you're right. There is elegance in simplicity.

I'm not against complication where it brings true sophistication wherever required... but geez I'm glad this mess is not something I have to deal with.

That's very very right. I find myself in a situation to also appreciate it for empowering users to do things in a simpler way.

But, the question actually is also about the larger part of the market, servers. I wonder if it is a good thing for servers to have systemd or if it would be better to have something more simpe. I dunno, if I was running servers, if I would want something so complex at all, or rather avoid as much complexity as possible in the base system. All the talk is about services, but would it not be possible to just write a service manager instead and pass necessary info between any init and any service manager?

My servers run 24/7, only going offline when I take them down for updates & upgrades. They're all on Slackware. It doesn't miss a beat. Hasn't once failed me... even without service supervision. I'm only a small shop, but it's nice to have the confidence that Slackware provides.

I set up an OpenVPN server 17 months ago. It's only been offline once, when I moved the box to a different location in the office. Came back up immediately upon starting it. Aside from that, I also use Samba extensively, NFS, SSH and I've got a small (internal) web server. All have proven to be bullet proof thanks to Slackware.

I'd guess service supervision might be important in a larger business, where they can't lose seconds or the few minutes it might take while someone looks at it. But even then, using it as a crutch would seem to point to bigger, underlying problems.

6 members found this post helpful.

It would behoove everyone to read this thread in its entirety:

https://www.mail-archive.com/gentoo-.../msg93253.html

I would greatly prefer to see Slackware remain free of systemd. Where I work, systemd (under CentOS) has been a constant source of technical difficulties for our sysadmins.

However, that thread makes it clear that maintaining eudev is a huge time-suck. I hope someone steps up and helps maintain it. It can't be me; my life situation barely leaves me with time enough to maintain the ##slackware-help chatbot, lately.

rworkman's solution makes more sense, at least in the short term. The danger there is that systemd might make that harder to do, and we'd have to revert to eudev anyway (and the longer a project like that is left unmaintained, the harder it gets to start maintaining it -- many small deltas are easier than one big one).

1 members found this post helpful.

I note that you write Interface, singular. If Slackware finds the "least paddling your canoe upstream" approach to be to take the udev code from systemd's tree (can we agree not to be alarmest about that meaning that we're getting systemd -- that's not what would be happening in that eventuality) it's I think going to have to make a decision about names. I'm trying hard to forget all of it but in a dream I found that there are gotchas with renaming back to eth0 if you have two or more interfaces. It's foggy but the dream went something like this...

Boot #1
1. kernel selected eth0 for NIC with MAC of AAAA11111FFFF.
2. and eth1 for NIC with MAC of BBBB0000BBBB.
3. systemd-udev renamed eth0 to eth0s5
4. and eth1 to eth0s4
5. I made a udev rule (blech) to name NIC AAAA11111FFFF. eth0
6. and to name NIC BBBB0000BBBB. eth1.
7. my udev rule would prevent the standard udev rule that comes up with names like eth0s4, eth0s5, or howdy doody, since that one checked a property that's set on the first udev rule to do a rename.

Boot #2
1. kernel selected eth1 for NIC with MAC of AAAA11111FFFF.
2. kernel sniffed at daisies for a little bit
3. a udev rule ran and tried to name NIC with MAC of BBBB0000BBBB as eth1 but eth1 is taken so some debian code named it rename0

or something like that. There's a race in other words. This is what I found most frustrating about the new scheme (along with the fact that if I plugged my phone / internet connection into different usb slots I'd get different device names). If there was a simple switch you could flip to say, "we don't want that," it would be all okay. Well, Debian had the switch for awhile but maybe with this race condition and with threats they couldn't keep it cause it's not how the new scheme really is supposed to work. Correct me if I'm wrong but the current udev reality is that you can make whatever udev rules you want to name your nics however you want as long as you don't want to name them eth0 and eth1.

Yep! At least on a systemd driven Linux distribution, like Ubuntu.

But in fact is all about the native/default rules.

There used to be one. You could put "net.ifnames=0" on the kernel command line. Does that not work any more?

1 members found this post helpful.

What is GUIX doing? They created elogind in a similar situation and I wonder if they will take over eudev?

I think they are pretty committed to the non-systemd route, considering they use GNU Shepherd. This should be a good thing in the end, as it hopefully has the full backing of GNU.

It's a little bit difficult to interpret GNU politics and software activism though, as Gnome is also supposedly partly a GNU project and have become dependent on SystemD. But I do doubt that GNU would really want to support a corporate project like SystemD and not rather put their weight behind a counterpart (Shepherd + generic inits etc).

I don't use debian, but in order to stop device renaming under systemd I disable systemd-networkd.service and systemd-resolvd.service. For me, that keeps the standard eth0, wlan0 ... network interface names and allows NetworkManager to do its thing. Does that not work for you?

As an experiment, when booting slackware using the standard slackware init scripts (including /etc/rc.d/re.inet1) I tried using the version of the udev daemon provided by systemd-249 rather than the one provided by eudev[1]. As reported elsewhere in this thread (R. Workman) that appears to boot up fine, and for me it does not carry out any network interface renaming, so your problem seems to be either (a) some udev rules that debian is unhelpfully applying to your installation not connected with systemd which you need to disable, or (b) the systemd-networkd service, which you also need to disable [edit or (c) set kernel parameters to net.ifnames=0]

[1] With recent versions of systemd there is no separate udevd binary: /lib/systemd/systemd-udevd is a symbolic link to /bin/udevadm. The relevant systemd unit file starts udevadm indirectly via that /lib/systemd/systemd-udevd symbolic link: presumably udevadm when so started knows to launch the udev daemon by reading argv[0]. So there does not appear to be any immediate problem for slackware arising from eudev becoming unmaintained. Instead a problem would arise if the systemd codebase were to require the systemd daemon to be running whenever the udev daemon is running - at present it doesn't. Were that to happen, then there would be some hard choices for the slackware maintainers to make.

This always becomes a question of what you are and aren't willing to consider a corner case that requires more work. Most destop and rack server Linux installations would be absolutely fine with a plain old static /dev tree like we used to have (frankly the servers would probably be better off). Soooooo much of this is solutions in search of a problem.

To the scripts issue, find me anyone who claims to have never written any software that relied on a seemingly valid but bad assumptions about 'they way things are' and I point out a liar. We should not assume the guy did something like hard code "eth0", I know I have scripts that assume things like network adapters will at least match the regex [a-z]{3,4}\.?[0-9]{1,3} for example that I naively assumed was true 20 years ago! Shared with lots people who never reported any issues back then!


The real issue is the new convention does solve the predictability problem for the people signing the checks. The lights out data center guys doing automated deployment of 1000s of the same system and 100,000s of VMs with basically the same virtual hardware get the predictable results they want/need. The big corps support desks deploying hundreds of identical PCs are fine to, they know the first NIC in all the Thinkpad T$$$ units is enp6s3 or whatever. Its the rest of us dealing with a handful of disparate hardware systems and trying to give / write instructions for software where we don't know what the hardware will be, and reconfiguring hardware fequently who it does not work for. but we are not sending RedHat checks.

1 members found this post helpful.

I find the copious comments along these lines on this thread rather puzzling. systemd might have some unhelpful defaults (I reserve judgement on that) but when set up to my liking it hasn't stopped me adopting "normal" network interface names. Am I right that you have come across distributions (possibly Redhat which I don't use?) which try to stop that, or is it a matter of a lack of knowledge on the part of the user?