Clarity regarding eth0 device name

tlathm · 2017-11-28 00:41:46

First a quick intro...first time posting here. My company currently delivers our product (primarily LAMP based) on a CentOS 6 VM, and we need to move to a more recent OS for several reasons. There was no way we were going with CentOS 7 or anything else with systemd. Given that I knew Debian had always been a solid go-to server OS, I ended up here. I've been working with a new headless devuan 1.0 install on a VM for about a week. I can't say enough about how ecstatic I am with it so far, and how thankful I am to everyone involved. Real Linux lives and rocks.

Here's my question: For several reasons, we want to ensure that a clone of our VM will always end up with the network device eth0. It's been my experience that when cloning a VM like this, there's a tendency to end up with a new device name like etc1 etc caused by what it perceives as a different network device. This is usually the result of the file /etc/udev/rules.d/70-persistent-net.rules created automatically by udev. On CentOS we worked around this with a shutdown process that deletes that file. With that, the network device always gets picked up as eth0.

In the install I'm testing, I get no such udev file. I've yet to try anything as far as spinning up a clone in a different VM environment.

Will this VM just always pick up the device as eth0? I'm a little unclear as to what's happening there and how/if udev is even involved.

Thanks in advance!

Tom

ralph.ronnquist · 2017-11-28 03:33:34

There's a long and sad story about udev versions here. The more recent version has the name scrambling as a net_id "builtin", and basically, preservation of sanity requires the boot command line to include

net.ifnames=0

With that, your network interfaces supposedly are left as named by the kernel modules, i.e., the eth adapter that is quickest to register is named eth0, the next one eth1 and so on.

fungus · 2017-11-28 04:53:21

Here read this, because even though what Ralph says is correct when your grub will be refreshed to accomodate a kernle change, an addition to a kernel, or to pick up a new installation, the net.ifnames=0 subcommand from the linux line will be removed.

https://sysdfree.wordpress.com/117

If you do this small change from that point on network interface names will remain as eth0 wlan0 etc. It works on all linux installations I have tried.

cynwulf · 2017-11-28 12:59:51

More details of the mess here: https://www.freedesktop.org/wiki/Softwa … faceNames/

(read it and weep)

tlathm · 2017-11-28 20:26:16

Holy good lord...just started reading this. One thing I need to get straight before I even ask any further questions, as there are two separate potential issues here:

What I was referring to specifically, as we ran into on CentOS 6, is when udev records an identifier for for a specific NIC card in /etc/udev/rules.d/70-persistent-net.rules. If the same VM boots in a different VM environment, it will end up with eth1 rather than eth0 unless that file has been removed, so we remove it at shutdown. I actually did a similar thing with a Gentoo install of my MythTV frontend, because I occasionally swap the hard drive with an identical backup computer and I have it configured for eth0.

The other issue, which I recall from way back with my Gentoo machines, was that switch to the entirely different naming scheme that replaces the eth0 naming. Under Gentoo that was prevented by simply adding a dummy file at /etc/udev/rules.d/80-net-name-slot.rules. I'm assuming we didn't run into that in CentOS 6 as that uses udev 147.

After that I have a lot of questions...for example, what caused me to get eth0 in this install instead of the new naming scheme...given that that's using udev 215?

Is there anything the freedesktop.org folks haven't screwed up? Under Gentoo I'm using eudev. I'm not sure if the fix above regarding 80-net-name-slot.rules was specific to just eudev or not. As a matter of fact I've also replaced that grub 2 nightmare with syslinux...I wasn't not much happier with that than any of this udev stuff.

Thanks for the replies!!...(I think ).

Tom

tlathm · 2017-11-28 20:31:46

OH...I just noticed an important aspect of this. That is, that I'm not using network manager at all. Still trying to understand if that makes a difference here.

In our case we'll always have one single "wired" network interface, and ideally we'd like it to always come up as eth0 regardless of the VM environment.

Thanks again.
Tom

Last edited by tlathm (2017-11-28 20:33:16)

cynwulf · 2017-11-29 13:16:50

tlathm wrote:

What I was referring to specifically, as we ran into on CentOS 6, is when udev records an identifier for for a specific NIC card in /etc/udev/rules.d/70-persistent-net.rules. If the same VM boots in a different VM environment, it will end up with eth1 rather than eth0 unless that file has been removed, so we remove it at shutdown.

Yes as far as I know you will always have to remove that file at shutdown otherwise udev will try to enumerate interfaces with unique device nodes, lead to a build up of eth0, eth1, eth2, etc...

tlathm wrote:

The other issue, which I recall from way back with my Gentoo machines, was that switch to the entirely different naming scheme that replaces the eth0 naming. Under Gentoo that was prevented by simply adding a dummy file at /etc/udev/rules.d/80-net-name-slot.rules. I'm assuming we didn't run into that in CentOS 6 as that uses udev 147.

This is the problem covered by ralph.ronnquist's reply.

tlathm wrote:

As a matter of fact I've also replaced that grub 2 nightmare with syslinux...I wasn't not much happier with that than any of this udev stuff.

As a boot loader / boot manager, grub is doing far more than it should be. It's a really pity lilo and elilo development stopped.

tlathm · 2017-11-29 16:12:58

Thanks for the replies! I'm hoping to test exporting my VM to an OVF and deploying it on our VCenter today to see what happens with the interface.

What still confuses me a bit is understanding why I'm getting eth0 rather than the new complex names...unless that's because I'm not running network manager(?). I certainly haven't changed any boot parameters etc. I'm also a little thrown as to why I'm currently not getting that auto-generated udev file at all (70-persistent-net.rules) or any others, even though udev is clearly running.

I'm not complaining, and I'd love it if that continued...I'm just not clear why it's behaving that way. Currently I have "auto eth0" in /etc/network/interfaces and, again, no network manager installed. As far as I can see, the only thing that gets changed automatically is /etc/resolv.conf and only if I set eth0 up for dhcp rather than static. That's exactly what I want.

If anyone understands why it's behaving so nicely I'd like to understand.

On an unrelated note: This has been my first use of anything related to Debian and I'm pretty thrilled all in all. I can say for sure that apt puts yum into the trash heap it deserves for sure. One feature that blew me away is the fact that I was able to install Tcl expect without unwanted (suggested) dependencies of tk by using "apt-get install expect tk8.6-". Too cool. For a binary distribution that reminded me of the flexibility I have with Gentoo.

Thanks again!
Tom

fungus · 2017-11-29 19:18:39

cynwulf wrote:

This is the problem covered by ralph.ronnquist's reply.

Meaning: That if you have 2+ ethernet devices, the one day one is 0 the next day it is 1 and vice versa making your network configuration a mess, while long-named uids will be consistent??

cynwulf · 2017-11-29 21:34:47

If you pass 'net.ifnames=0' to the kernel command line it will disable the "predictable" network interface device node naming. i.e it will return to the old eth0, eth1... naming.

It will not solve the OP's problem of persistent naming. That used to be resolved by clearing /etc/udev/rules.d/70-persistent-net.rules (in this case it would need to be run on every shutdown).

Combining the two approaches should give the desired result ("eth0" as the sole network interface).

however this is actually systemd we're talking about, so it's a moving target. What works now, may no longer work in 6 months' time.

It's probably more advisable to switch away from systemd/udev and invest time in learning the alternatives...

Last edited by cynwulf (2017-11-29 21:35:47)

tlathm · 2017-11-29 21:52:33

I'm certainly not using systemd of course. Correct me if I'm wrong, but there's no alternative to udev available in devuan at the moment(?)..unless maybe someone were to create a static /dev of something. Under Gentoo I'm using eudev.

And again, while I haven't been able to test what device I get is I port this to another VM environment, I am getting the eth0 device without passing any kernel options, and I am not getting anything like the 70-persistent-net.rules at all even though udev is running. That's actually great, but I'm really bothered by the fact that nobody seems to know why that is.

Is this possible because I'm not using network manager?

Tom

cynwulf · 2017-11-29 22:05:00

udev is part of the systemd source tree - it's a systemd component. This wasn't always the case, but since around 2012 (?) it is now.

It has zero to do with "network manager".

Device nodes are generated dynamically at boot by udev. This is one of the much vaunted "features".

You can, or could, still just revert to a static /dev, make all your device nodes and just bin udev altogether. Though, it's a use case thing - horses for courses, etc. (Full blown desktops, won't like it...)

Alternatives to udev, you'd probably have to port over and build from source yourself.

golinux · 2017-11-29 22:14:35

eudev is being tested (quite successfully) in ascii.

fungus · 2017-11-30 00:41:55

I've been using eudev for the past 4-5 months and I have had no problems.
Has it been the last month that it moved from experimental to ascii?

golinux · 2017-11-30 01:33:44

fungus wrote:

Has it been the last month that it moved from experimental to ascii?

That hasn't happened quite yet but will soon.

fsmithred · 2017-11-30 04:53:08

I have a partial answer to the original dilemma. I made a live usb of devuan ascii (and udev), with persistence. There's no 70-persistent-net.rules in the live isos by design, and there's none in my ascii anyway. Normally (jessie and older) with persistence, the one that gets created at boot sticks around, and you have to either delete it or change your settings to eth1, 2... or wlan1, 2 (I think I've gone up to 8 in the past.)

This particular system has wicd on it, and there are settings for default wired and wireless interfaces. They're set to eth0 and wlan0. I added net.ifnames=0 so that the old names will be used.

Booted one laptop and was automatically connected with the wire. Wicd saw the nearby wireless signals.
Booted another laptop and was automatically connected. Wicd worked, too.
In both cases, the only interfaces were eth0 and wlan0. They did not increment.

Explanation: Hand-waving-argument, magic. I don't know. But I think you'll be ok when you move your system to different hardware.

Bug me in a couple of weeks to see if I tried it with eudev yet.

fungus · 2017-11-30 06:14:33

I tried it with eudev too and it is still the same.

tlathm · 2017-11-30 15:24:00

fsmithred wrote:

Explanation: Hand-waving-argument, magic. I don't know. But I think you'll be ok when you move your system to different hardware.

Haha...glad it's not just me. Yes, it appears I'll be OK but it would be nice to understand why. Both are still a mystery to me...that is, how I'm getting eth0 without net.ifnames=0, and why I'm getting no 70-persistent-net.rules (or any other rules) with udev enabled. Don't look a gift horse in the mouth I guess .

EDIT: Totally OT: Any idea why wiki.debian.org is apparently blocking the commercial VPN I use? I get 403s...very annoying. I read some things from way back where this was supposedly corrected(?).

Thanks!
Tom

Last edited by tlathm (2017-11-30 15:27:35)

fog · 2017-12-01 22:01:16

tlathm wrote:

fsmithred wrote:
Explanation: Hand-waving-argument, magic. I don't know. But I think you'll be ok when you move your system to different hardware.
Haha...glad it's not just me. Yes, it appears I'll be OK but it would be nice to understand why. Both are still a mystery to me...that is, how I'm getting eth0 without net.ifnames=0, and why I'm getting no 70-persistent-net.rules (or any other rules) with udev enabled. Don't look a gift horse in the mouth I guess .
EDIT: Totally OT: Any idea why wiki.debian.org is apparently blocking the commercial VPN I use? I get 403s...very annoying. I read some things from way back where this was supposedly corrected(?).
Thanks!
Tom

you can set
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
then update grub/initrd

then whatever will happen to init you should always get consistent eth0
remember though to etit interfaces.

regarding VPN and wiki.debian.org - I don't see this issue (using commercial VPN)

Last edited by fog (2017-12-01 23:26:39)

tlathm · 2017-12-02 01:53:05

fog wrote:

you can set
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
then update grub/initrd
then whatever will happen to init you should always get consistent eth0
remember though to etit interfaces.

Thanks! Just to clarify, being a bit new to this: I assume that the change there is in the /etc/default/grub file, and when you say update grub you mean update-grub, and as far as the initrd, is that "update-initramfs -u"?

I'm too used to Gentoo where I'm using syslinux and no initrd at all. Thanks!

EDIT: Thinking about this more: Why would this require any change to the initrd? Wouldn't simply changing /etc/default/grub and running update-grub be sufficient? Thanks.

Tom

Last edited by tlathm (2017-12-02 13:56:55)

fog · 2017-12-03 01:11:41

tlathm wrote:

EDIT: Thinking about this more: Why would this require any change to the initrd? Wouldn't simply changing /etc/default/grub and running update-grub be sufficient? Thanks.
Tom

of course, no need to update initrd. My mistake. I am sorry

tlathm · 2017-12-03 15:30:56

fog wrote:

of course, no need to update initrd. My mistake. I am sorry

No problem. Thanks! I'm not sure I we'd actually ever need that kernel command line, as I'm getting the eth0 name anyway, but I've added it to the grub config be safe.

Tom

The officially official Devuan Forum!

#1 2017-11-28 00:41:46

Clarity regarding eth0 device name

#2 2017-11-28 03:33:34

Re: Clarity regarding eth0 device name

#3 2017-11-28 04:53:21

Re: Clarity regarding eth0 device name

#4 2017-11-28 12:59:51

Re: Clarity regarding eth0 device name

#5 2017-11-28 20:26:16

Re: Clarity regarding eth0 device name

#6 2017-11-28 20:31:46

Re: Clarity regarding eth0 device name

#7 2017-11-29 13:16:50

Re: Clarity regarding eth0 device name

#8 2017-11-29 16:12:58

Re: Clarity regarding eth0 device name

#9 2017-11-29 19:18:39

Re: Clarity regarding eth0 device name

#10 2017-11-29 21:34:47

Re: Clarity regarding eth0 device name

#11 2017-11-29 21:52:33

Re: Clarity regarding eth0 device name

#12 2017-11-29 22:05:00

Re: Clarity regarding eth0 device name

#13 2017-11-29 22:14:35

Re: Clarity regarding eth0 device name

#14 2017-11-30 00:41:55

Re: Clarity regarding eth0 device name

#15 2017-11-30 01:33:44

Re: Clarity regarding eth0 device name

#16 2017-11-30 04:53:08

Re: Clarity regarding eth0 device name

#17 2017-11-30 06:14:33

Re: Clarity regarding eth0 device name

#18 2017-11-30 15:24:00

Re: Clarity regarding eth0 device name

#19 2017-12-01 22:01:16

Re: Clarity regarding eth0 device name

#20 2017-12-02 01:53:05

Re: Clarity regarding eth0 device name

#21 2017-12-03 01:11:41

Re: Clarity regarding eth0 device name

#22 2017-12-03 15:30:56

Re: Clarity regarding eth0 device name

Board footer