Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Network interfaces suddently renamed after reboot.
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Fri Mar 08, 2019 4:05 am    Post subject: Network interfaces suddently renamed after reboot. Reply with quote

After a reboot, my network interface names got messed up. I would appreciate any advice on fixing this.

I have 3 physical interface devices:
Code:
# lspci | grep Ether
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
04:00.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
04:00.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)


The two Intel devices are on a single card.

I have attempted to keep the interfaces called "ethX", despite the change to "predictable" names. I have 3 files in the /etc/systemd/network directory:

Code:
# ls /etc/systemd/network/
90eth0.link  90eth1.link  90eth2.link


These map the MAC address to the names.

Note that my system uses OpenRC, but I believe that these files should still be used.

I also have a udev file: /etc/udev/rules.d/71-persistent-net.rules, with the same mapping between MAC addresses and device name as is used in the systemd files above.

What is really strange is that my active network devices are now called "eth1", "eth2" and "eth3". What happened to "eth0":

Code:
# grep eth0 boot.log
[   14.946490] eth0: renamed from ip_vti0

(My boot scripts include "dmesg >> /var/log/boot.log" to capture this information.)

So, what happened to eth0? Why do my network device names not correspond to what I have specified?

I could use the new "predictable" network names, but how do I distinguish between the two interfaces on the Intel card and ensure that the names remain predictable?

Frankly, the whole situation is frustrating, because my network names were predicable until the new "predictable" names were introduced.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6033

PostPosted: Fri Mar 08, 2019 6:54 am    Post subject: Reply with quote

Where does ip_vti0 come from?
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Fri Mar 08, 2019 7:02 am    Post subject: Reply with quote

Ant P. wrote:
Where does ip_vti0 come from?


That was what I was wondering. I have no idea what this is.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6033

PostPosted: Fri Mar 08, 2019 6:41 pm    Post subject: Reply with quote

/sys/class/net/ should have a symlink telling which driver owns it.
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Fri Mar 08, 2019 7:30 pm    Post subject: Reply with quote

Ant P. wrote:
/sys/class/net/ should have a symlink telling which driver owns it.




Code:
$ ls -l /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 Mar  7 18:57 eth0 -> ../../devices/virtual/net/eth0
lrwxrwxrwx 1 root root 0 Mar  7 18:57 eth1 -> ../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/eth1
lrwxrwxrwx 1 root root 0 Mar  7 18:58 eth2 -> ../../devices/pci0000:00/0000:00:1e.0/0000:04:00.0/net/eth2
lrwxrwxrwx 1 root root 0 Mar  7 19:00 eth3 -> ../../devices/pci0000:00/0000:00:1e.0/0000:04:00.1/net/eth3
lrwxrwxrwx 1 root root 0 Mar  7 18:57 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Mar  7 18:57 sit0 -> ../../devices/virtual/net/sit0
lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun0 -> ../../devices/virtual/net/tun0
lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun1 -> ../../devices/virtual/net/tun1
lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun2 -> ../../devices/virtual/net/tun2
lrwxrwxrwx 1 root root 0 Mar  7 19:40 tun3 -> ../../devices/virtual/net/tun3
lrwxrwxrwx 1 root root 0 Mar  7 18:57 tunl0 -> ../../devices/virtual/net/tunl0


I assume that it is related to this:
Code:
$ zgrep VTI /proc/config.gz
CONFIG_NET_IPVTI=y
# CONFIG_IPV6_VTI is not set

But this was true for the prior kernel version.

I should have mentioned earlier that I booted into a newer version of the kernel which I had not used before. I assume this issue is related. This still doesn't explain why my network device name assignments were not respected.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6033

PostPosted: Fri Mar 08, 2019 11:50 pm    Post subject: Reply with quote

Something on your system is renaming that virtual interface to eth0, causing your ethernet cards to become misnumbered. That's not default or expected behaviour on any distro I've used, but I don't use systemd so I can't say if it's trying to be “helpful” here.
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Sat Mar 09, 2019 12:38 am    Post subject: Reply with quote

Ant P. wrote:
Something on your system is renaming that virtual interface to eth0, causing your ethernet cards to become misnumbered. That's not default or expected behaviour on any distro I've used, but I don't use systemd so I can't say if it's trying to be “helpful” here.


I am not using systemd. My system uses OpenRC.

I am wondering what might happen if I try to force the names to "internet0", "lan0", etc, instead of "ethX".
Back to top
View user's profile Send private message
UberLord
Retired Dev
Retired Dev


Joined: 18 Sep 2003
Posts: 6759
Location: Blighty

PostPosted: Sat Mar 09, 2019 4:13 am    Post subject: Reply with quote

mgnut57 wrote:
I am not using systemd


mgnut57 wrote:
I have 3 files in the /etc/systemd/network directory


Are you sure you're not using systemd? :?:
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Sat Mar 09, 2019 5:09 am    Post subject: Reply with quote

UberLord wrote:
mgnut57 wrote:
I am not using systemd


mgnut57 wrote:
I have 3 files in the /etc/systemd/network directory


Are you sure you're not using systemd? :?:


Yes.

I have another system which also does not use systemd and the network interfaces are successfully (re)named by these files.

udev has been infected by systemd and it is udev that reads these files.
Code:

 # ps -Af | grep systemd
root      2553     1  0 Mar07 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
root     11189 21671  0 21:07 pts/1    00:00:00 grep --colour=auto systemd
 # equery belongs /lib/systemd/systemd-udevd
 * Searching for /lib/systemd/systemd-udevd ...
sys-fs/udev-239 (/lib/systemd/systemd-udevd)
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3311
Location: Illinois, USA

PostPosted: Sat Mar 09, 2019 4:47 pm    Post subject: Reply with quote

Are you using eudev? You should be. I can't tell from the files because they have the same names.
The later versions of udev only work with systemd

On my server with eudev
Code:
 # ps -Af | grep systemd
root       993   981  0 10:47 pts/0    00:00:00 grep --colour=auto systemd


Run "rc-update show" and see if it anything looks odd.


Last edited by Tony0945 on Sat Mar 09, 2019 4:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Sat Mar 09, 2019 4:51 pm    Post subject: Reply with quote

Tony0945 wrote:
Are you using eudev? You should be. I can't tell from the files because they have the same names.
The later versions of udev only work with systemd

On my server with eudev
Code:
 # ps -Af | grep systemd
root       993   981  0 10:47 pts/0    00:00:00 grep --colour=auto systemd


No, I am not using eudev.

I need to convert? Is there a guide?

This post says that conversion isn't really required, unless one is an anti-systemd purist:
https://forums.gentoo.org/viewtopic-t-1055086-start-0.html

Simon
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3311
Location: Illinois, USA

PostPosted: Sat Mar 09, 2019 4:56 pm    Post subject: Reply with quote

See "Migrating from udev to eudev" on the wiki https://wiki.gentoo.org/wiki/Eudev

You may have to uninstall udev. Try the wiki instuctions and see what happens. Report any blockers back here.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6296

PostPosted: Sat Mar 09, 2019 5:58 pm    Post subject: Re: Network interfaces suddently renamed after reboot. Reply with quote

Quote:
I have attempted to keep the interfaces called "ethX". [...] These map the MAC address to the names.

If I understand correctly, you have some rules there like
Code:
ATTR... NAME="eth0"

This is broken: The kernel might just have initialized a new eth0 device while {e,}udev tries to rename some other device to eth0 -> this race can lead to all sort of problems.
This race problem is not related with udev vs. eudev.

Solution: Use a different namespace, e.g. lan0 ... lan3 (everything except eth* and other kernel-reserved stuff is fine).
Back to top
View user's profile Send private message
Leio
Developer
Developer


Joined: 27 Feb 2003
Posts: 487
Location: Estonia

PostPosted: Sat Mar 09, 2019 8:29 pm    Post subject: Reply with quote

sys-fs/udev is meant to be used when NOT having systemd, just like eudev. So it is your choice if you use udev or eudev.
udev is compiled from systemd tarball and is the main tested thing (by the majority of other popular distros), and eudev is a fork that sometimes gets updates pulled from udev.
There may be some out of the box default differences in terms of network naming and such, but if that's the case, udev can presumably be configured to behave like eudev does by default, should you so choose.

Just clarifying that NO, you don't HAVE to convert, only if you want to choose that.
_________________
GNOME team lead; GStreamer; MIPS/ARM64
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Sat Mar 09, 2019 8:48 pm    Post subject: Reply with quote

Leio wrote:
sys-fs/udev is meant to be used when NOT having systemd, just like eudev. So it is your choice if you use udev or eudev.
udev is compiled from systemd tarball and is the main tested thing (by the majority of other popular distros), and eudev is a fork that sometimes gets updates pulled from udev.
There may be some out of the box default differences in terms of network naming and such, but if that's the case, udev can presumably be configured to behave like eudev does by default, should you so choose.

Just clarifying that NO, you don't HAVE to convert, only if you want to choose that.


Thanks for clarifying.

I think my next move is to stop trying to force the names to be ethX style names and make them something completely different.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44198
Location: 56N 3W

PostPosted: Sat Mar 09, 2019 9:26 pm    Post subject: Reply with quote

mgnut57,

Its a bad thing to rename anything to names allocated on a first come first served basis by the kernel.
Add
Code:
net.ifnames=0
to your kernel command line to prevent interface renaming.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Leio
Developer
Developer


Joined: 27 Feb 2003
Posts: 487
Location: Estonia

PostPosted: Sat Mar 09, 2019 11:15 pm    Post subject: Reply with quote

net.ifnames=0 disables the predictable network naming feature, so I don't see how the suggestion matches the intent.

eth0 and eth1 ARE the unpredictable names, depending on a first come first serve basis and may swap around on different boots, as I understand it.

The predictable network names feature solves that. Though I don't know what that ip_vti0 is about - searching suggests a swan VPN thing. I would expect something like "enp2s0", "ens1", "eno1" or such, depending what the network device is attached to.
But yes, net.ifnames=0 is one way to disable the predictable network names feature, thus have eth0, eth1, etc as far as udev is concerned (if udev is doing the renaming). sys-fs/udev prints out a rather long information at the end of its (re)install/upgrade on how to achieve that as well, including other methods how to disable the feature.
_________________
GNOME team lead; GStreamer; MIPS/ARM64
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44198
Location: 56N 3W

PostPosted: Sun Mar 10, 2019 12:14 am    Post subject: Reply with quote

Leio,

My main point was that eth0 is a rename of another interface. net.ifnames=0 is more a diagnostic than a fix.
It will let us see the real names of the interfaces.

I don't know what ip_vti0 is either but I'm fairly sure its not a kernel name.

Being old and cynical, I'll just say that the predictable network naming feature just swaps one set of corner cases for a different set of corner cases and only served to upset a lot of users with a single interface.

I seen kernel interface names swap from kernel to kernel, where several different drivers are in use but never from boot to boot.
Its true that there is a race condition in enumerating several different interfaces that use different drivers.
MAC based interface naming solved that a long time ago and to me, had the advantage that rearranging the cards in PCI slots did not change interface names.

I'm not a fan of predictable network device names.
Its totally broken for USB dongles as they are named after the USB port they happen to gen plugged into. usb0 was much better.
Sorry for the rant ... its drifting off topic too.

I don't use either udev or eudev, so I don't have predictable network naming to turn off.
That's not a path I recommend though.

Hmm ... vti Virtual Tunnel Interface maybe.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14390

PostPosted: Sun Mar 10, 2019 12:36 am    Post subject: Reply with quote

Leio wrote:
net.ifnames=0 disables the predictable network naming feature, so I don't see how the suggestion matches the intent.
It makes the names be what the kernel initially assigned. For a surprisingly large percentage of the population, kernel-assigned names work perfectly and the "predictable" names generated by systemd-udevd are worse, not better.
Leio wrote:
eth0 and eth1 ARE the unpredictable names, depending on a first come first serve basis and may swap around on different boots, as I understand it.
This is a common justification given for the misfeature, but speaking as someone who has had multiple motherboards with more than one NIC per board, I have never had kernel-assigned names cause any problems. The kernel consistently assigns the same name to the same physical device, on boot after boot, both warm and cold. This has been the case for a variety of kernel versions, and applies both when the two NICs are the same model and when they are different models. I assume someone somewhere had a system where the names swapped out in an unpredictable manner, but I would expect that if this were a big problem in practice, the kernel developers would have been personally impacted and would have done something like "predictable interface names" right in the kernel, so that the interface has the right name from the moment that userspace can see it at all. To me, that is the other bizarre aspect of this misfeature. Why rename in usermode, which we know is racy, when you could do a kernel patch to let userspace set a policy (and have a default policy compiled into the kernel) that picks among the major naming modes: classic (ethN), PCI address based, MAC based, etc.? That would ensure proper naming from the moment the device is created, independent of the speed with which userspace can react to the device creation messages.

Incidentally, the proponents of this misfeature made the political blowback much worse for themselves by insisting on naming it "predictable" when their names are actually more trouble to predict than the classic names. Prior to this, we could tell users "put an IP on eth0, set a default route, and you're ready to go." Now, we have to walk people through finding what name their NIC has before they can even begin configuring it. That's not a nice step to add at the beginning when you're trying to help a struggling new user who just wants the system to work at all.
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 218

PostPosted: Sun Mar 10, 2019 6:11 am    Post subject: Reply with quote

I agree that the new "predicable" names are anything but.

In my opinion, when you have two identical interface cards (or two interfaces on the same card), the order of the names is not predicable.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3311
Location: Illinois, USA

PostPosted: Sun Mar 10, 2019 6:21 am    Post subject: Reply with quote

Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork. I was unaware that the situation has changed, as I see no reason to go back.

Hu, I once had a Tyan server board that behaved unpredictably. It had two identical controllers on the motherboard. That was a feature of the board. I had to keep swapping the cable after reboot until I installed eudev and assigned names based on MAC address. I did use eth0 which I recognize was bad. Perhaps I had no trouble because I didn't use the second interface. More recently (last year) I added an Intel board to one of my systems with an existing onboard Realtek. I did this for experimental purposes to see if there was a significant advantage to the Intel. I forced the order by delaying loading the driver module for the Intel board until after eth0 was up and running, ensuring that it would be eth1. I'm still running an older version of OpenRC so all modules are not automatically loaded, only those listed in /etc/conf.d/modules. I loaded the second module in /etc/local.d That might work for the OP but I assumed that he was running a later init system. Besides, I think he has two devices with the same driver.

My 32-bit system also has ethernet devices, different devices and one built-in. When I was using it as a router, I named the faster card lan0 and the slower one wan0 via eudev MAC address rules. I chose those names because they made the firewall rules easier to understand ("Is eth0 the lan or is it eth1, hmmm!"). The "predictable names" I see usable for big servers with multiple identical cards. Even then, as you say, instead of the unpronounceable names, names indicating their network based on MAC (net0, net1... or netadmin, netmanuf, netexec, netadvert, netwww), would seem better and the whole system wouldn't change if one card died.
Back to top
View user's profile Send private message
Leio
Developer
Developer


Joined: 27 Feb 2003
Posts: 487
Location: Estonia

PostPosted: Sun Mar 10, 2019 9:09 am    Post subject: Reply with quote

Tony0945 wrote:
Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork.


This has been NEVER the case as of yet. When eudev was made, the only thing that happened was that the udev code was moved to the same code repository and release tarballs than systemd. It was buildable separate of systemd and no part of it depends on any other parts of systemd (besides pci/usb.ids maybe, but for that we have a separate package also, to have it shared across the udev options). I believe BSDs have a similar approach to code, but no-one is busy forking all that.

There are pros and cons to predictable names (yes, they are predictable across the same physical setup, unlike the alternative - the concerns raised are about not knowing what the name will be for a random different system). The majority of the Linux community has decided that the pros far outweigh the cons, but most of them don't deal with configuring stuff in text files. So lets leave it at that.

To me the on-topic question is, why some apparent virtual tunnel interface gets renamed, but the rest not. It seems eth1 through eth3 are real physical ones attached to PCI or PCI-E interface. I would expect these to be named enp4s0 or similar, maybe some old persistent-net.rules somehow got to keep them as eth*
_________________
GNOME team lead; GStreamer; MIPS/ARM64
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44198
Location: 56N 3W

PostPosted: Sun Mar 10, 2019 11:31 am    Post subject: Reply with quote

Leio,

Something somewhere is renaming interfaces to the names that the kernel allocates, so there is certainly some renaming going on.
Its odd that the rename is to eth0
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Goverp
l33t
l33t


Joined: 07 Mar 2007
Posts: 729

PostPosted: Sun Mar 10, 2019 12:21 pm    Post subject: Reply with quote

As an aside, the "predictable" names aren't stable, as I found when I added a USB3 card to my machine. My ethernet card got renamed (which was a surprise, as I think it was a PCI device). At which point I reverted to the old static names. Which does expose me to a dangerous confusion - but only if I ever install a second ethernet card, and I doubt I will!
_________________
Greybeard
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6296

PostPosted: Sun Mar 10, 2019 1:31 pm    Post subject: Reply with quote

Hu wrote:
I have never had kernel-assigned names cause any problems.

I had. It is simply a question of luck and other kernel options.
Quote:
and would have done something like "predictable interface names" right in the kernel

If this would have been possible, they would have done it. But there were long discussions, and the conclusion was that problems of this complexity should be solved in userspace.
Quote:
Why rename in usermode, which we know is racy

No, it is not racy. It becomes only racy if the userspace tool should have been misconfigured by attempting to use names (e.g. "eth[0-9]*") which the kernel is supposed to use.
Quote:
when you could do a kernel patch to let userspace set a policy

There is no reason to have complicated policies in kernel, especially if many natural policies (e.g. based on MAC or other data which makes the device unique enough on your system) should be easily changeable on boot. That's exactly what tools like udev were originally developed for (long before udev became part of systemd).
The original way of automatically storing the address also had its problems (e.g. when you exchanged the hardware of some interface) as well as the randomness of the eth* order. So compared to both, the default choice of "predictable" network interfaces certainly has some advantages, but each of the defaults has major drawbacks. For reliability you need to write your own rules. This is easy enough with {e,}udev and can be made absolutely robust if you can make certain assumption a-priori, e.g. if you can rely that you will ever have at most one ethernet device of a certain type. But exactly because of such assumptions, it would be questionable to make such rules a default.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum