# [SOLVED] udev network device name

## gtwrek

The instructions here:

https://wiki.gentoo.org/wiki/Eudev/Network_device_names

That allows us to keep the traditional "eth0", "eth1",etc. network names has suddenly stopped working for me with a recent world update.

I think the machine in question was doing the eudev-> systemd-udevd migration at the time.

But after this world update, and a reboot, my network was gone..   :Mad: 

This is especially frustrating as many of my gentoo machines are headless servers with just a sshd connection enabled - so network gone, means a difficult to debug problem.

I checked for the existance of the /etc/udev/rules.d/80-net-name-slot.rules file - it's still there.

But, no "eth0" device - I get the new fangled /dev/enp0s3 instead.

How does one re-enable this "stop messing with my network names" part of udev?Last edited by gtwrek on Thu Dec 02, 2021 5:42 pm; edited 1 time in total

----------

## NeddySeagoon

dtwrek,

Add 

```
net.ifnames=0
```

as a kernel parameter to the kernel command line.

Exactly how you do that is boot loader depended.

----------

## sam_

I've also updated the page you linked to refer to the newer instructions here (see bug 827937 too).

----------

## gtwrek

Well, I think I've figured out *some* of what's going on.

To keep the normal network names, there's three methods:

1. touch /etc/udev/rules.d/80-net-name-slot.rules

  2. touch /etc/udev/rules.d/80-net-setup-link.rules

  3. add net.ifnames=0 to your kernel command line

Method 1 works with eudev and certain older versions of udev. (As I understand things eudev was forked from an early version of udev, so this make sense)

Method 2 works with current udev.

Method 3 (currently recommended?) should work past some xxx.xxx kernel version.

I'm still puzzled as to why udev is now being pulled in for me.  I've been using eudev forever, and I thought we had until Jan 1, 2022 until it was formally deprecated. 

But in any event I think some more text to the enews might be called for, for those of use migrating from eudev to udev.  Dropping off the network after a reboot from a world update is a very frustrating experience.

----------

## sam_

 *gtwrek wrote:*   

> Well, I think I've figured out *some* of what's going on.
> 
> To keep the normal network names, there's three methods:
> 
> 1. touch /etc/udev/rules.d/80-net-name-slot.rules
> ...

 

Noted, thanks for the feedback.

Some improvements:

1. I've just updated the news item to explicitly reference this and link to the wiki.

2. As I mentioned, I updated the page OP linked to earlier.

3. Earlier, floppym updated the udev wiki page to be more clear.

4. Earlier, we also added an automatic carry over for the rules eudev would recognise into sys-fs/udev (as a result of bug 827937).

There has been a message in sys-fs/udev about the interface naming since August: that message appears when installing udev for the first time after switching from eudev.

EDIT: The ebuild now also explicitly links to the wiki too.

As for why it's masked now: the news item said it'd be masked on 1st October, so it was actually done a far bit later than that. It can still be unmasked locally if you wish.

----------

## Hu

2022-01-01 is the date on which the news said eudev would be retired and removed.  I interpret that as meaning that on or about that date, emerge --pretend --verbose sys-fs/eudev will begin reporting "No such package".  This gives users a window during which they could copy the last version of eudev into an overlay, if they are determined to continue using it instead of switching to udev.

----------

## gtwrek

Thanks Sam, and Hu.  Sam - your edits to the enews message and the udev message are great.  I think that should cover things.

Hu, yes rereading the original enews, it mentioned 2022-01-01 as the removal but 2021-10-01 as the mask.  I'd really not consider the difference between the two.  And it appears the 2021-10-01 mask was delayed to sometime in the last few weeks.  This is what triggered my conversion from eudev->udev and the resulting network naming problems note in this thread.

I think I'm ok with moving forward with updating the rest of my machines, now that I understand what's happening. 

Thanks all for the help.

----------

## sam_

 *gtwrek wrote:*   

> Thanks Sam, and Hu.  Sam - your edits to the enews message and the udev message are great.  I think that should cover things.
> 
> Hu, yes rereading the original enews, it mentioned 2022-01-01 as the removal but 2021-10-01 as the mask.  I'd really not consider the difference between the two.  And it appears the 2021-10-01 mask was delayed to sometime in the last few weeks.  This is what triggered my conversion from eudev->udev and the resulting network naming problems note in this thread.
> 
> I think I'm ok with moving forward with updating the rest of my machines, now that I understand what's happening. 
> ...

 

Thanks a lot for the feedback! Really appreciated. Glad everything is OK now. Please let us know if any trouble.

----------

## figueroa

Just to cover all of the bases:

1. I created a symlink "80-net-name-slot.rules -> /dev/null" on April 2, 2013

2. I created a symlink "80-net-setup-link.rules -> /dev/null" on May 10, 2014.

3. I also have the line GRUB_CMDLINE_LINUX="net.ifnames=0" in /etc/default/grub

ADDED: On my newer main desktop machine, I use my own unique network names with a udev rule that was originally done because of a failing built-in NIC.

```
$ cat /etc/udev/rules.d/90-local-net-name.rules

# NOTES:

# wan0  Ralink corp. RT5390 Wireless 802.11n on-board rt2800pci module

#   wlan0 by default

# lan0  Realtek RTL8111/8168/8411 on-board (bad) r8168 or r8169 module

#   Disabled in kernel

# lan1  TP-Link USB UE300 10/100/1000 LAN Realtek RTL8153 r8152 module

# lan2  Intel Corporation 82572EI (used) Gigabit Ethernet e1000e module

#   eth0 by default becomes lan2 via udev, below

#Model alternative:

#SUBSYSTEM=="net", ACTION!="remove", ATTR{address}=="9c:b7:0d:6a:ec:80", NAME="wan0"

#

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="9c:b7:0d:6a:ec:80", NAME="wan0"

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="e8:40:f2:0c:86:eb", NAME="lan0"

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="d0:37:45:ca:52:5d", NAME="lan1"

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:15:17:d3:3f:74", NAME="lan2"
```

This worked so well, I didn't revert back to using eth0. If feels funky, but I got used to it.

----------

## gtwrek

 *figueroa wrote:*   

> Just to cover all of the bases:
> 
> 1. I created a symlink "80-net-name-slot.rules -> /dev/null" on April 2, 2013
> 
> 2. I created a symlink "80-net-setup-link.rules -> /dev/null" on May 10, 2014.
> ...

 

I'm now doing the same on all my servers.  What's worth doing one way, might as well do it all 3 ways...

----------

## Jaglover

I do it just one way, I have "net.ifnames=0" in kernel builtin command line.

```
CONFIG_CMDLINE="root=/dev/sda2 net.ifnames=0"
```

----------

