Skip to main content ↑ ↓
Topic: If networkmanager gives you long network interface names return to eth0 & wlan0 (Read 2281 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

If networkmanager gives you long network interface names return to eth0 & wlan0

Edit your /etc/default/grub change GRUB_CMDLINE_LINUX="" to :

Code: [Select]
GRUB_CMDLINE_LINUX="net.ifnames=0"

If the biosdevname is installed you need to add :

Code: [Select]
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Code: [Select]
$ update-grub

This creates a new /boot/grub/grub.cfg and for each entry in the line that starts with Linux there is a net.ifnames=0 usually after rw and the uuid address, so you can even add it manually there and reboot to see if the longnames have vanished and eth0 and wlan0 have re-established themselves.

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #1 –
Nice tips man. I hate that unexpected changes .... 6 years of many configuration files working with wlan0 and eth0, I do not feel confortable with unexpected new longnames
Keep it Simple. Simple is Secure, Simple is Beautiful.

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #2 –
This is actually not something that is recommended. There is a valid reason behind the new names. They don't change after reboot or hardware changes.
For example in a server imagine that I install a second network card. With the new naming convention it will receive a unique name that won't conflict with the other.
However with the old naming system there are problems, you won't know which card is eth0 and which card is eth1. For example before I installed the new network card the original card was called "eth0" after installing the new network card it changed to "eth1". Which of course ruins all the network scripts I have. I have to go and fix and change all the network scripts to use the new names. Even worse, there have been cases that after a reboot of a machine the eth0 and eth1 switch automatically since they are not reserved by a specific card. Just imagine that you do a reboot remotely and then the machine switches the network name and you can't access it anymore, you lost all connections to the server because the name changed.

You may not like the new names being longer, but they serve an important purpose, to fix and unify the names so that these problems do not occur.

So anyone reading this, please think carefully before doing this.
Chris Cromer

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #3 –
This makes sense and it is a summary of what I have read.  Thank you Chris.
For most of us PC users the advantage is negligible if not a problem.  I made a live image of a system and try to boot and all networking had to be reconfigured from scratch because of it.

I think the same way that drives can be confused /sda /sdb .... between one and the other depending on what happens during boot, a system with a whole array stack and a bunch of network drives needs UUID instead of labels.  But few of us have this problem.
It is good to know that we have the option to use it but I am doubting the necessity of the default.  Eventually I may use an older pc for a router/fwall to serve the rest and may have to use it on the server.  Till then I see no advantage in having to look up the name of the device instead of just typing 4 characters.  I have 14 partitions right now and I have memorized what each one is, but I can't remember the first 4 digits of any uuids.  This I also consider a security flaw, as Universal Unique ids identify very well who is who, and I have little faith that such information will never pass past my box.  Some of those "improvements" and "features" seem to have spun out of systemd development, where I have great doubts on its role to improve anything to my advantage.

Isn't this how we all met ??  :)

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #4 –
Quote from: cromer – on
This is actually not something that is recommended. There is a valid reason behind the new names. They don't change after reboot or hardware changes.


There is always a reason

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #5 –
Quote from: cromer – on
So anyone reading this, please think carefully before doing this.

With all due respect, this is FUD.  We've used this system for decades without trouble.  I don't want to think deeply about my two Ethernet cards.  I expect one to be eth0 and the other to be eth1.
Quote
However with the old naming system there are problems, you won't know which card is eth0 and which card is eth1. For example before I installed the new network card the original card was called "eth0" after installing the new network card it changed to "eth1". Which of course ruins all the network scripts I have. I have to go and fix and change all the network scripts to use the new names. Even worse, there have been cases that after a reboot of a machine the eth0 and eth1 switch automatically since they are not reserved by a specific card. Just imagine that you do a reboot remotely and then the machine switches the network name and you can't access it anymore, you lost all connections to the server because the name changed.

www:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:C0:09:A6:08 
          inet addr:10.0.0.5  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::201:c0ff:fe09:a608/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:104758155 errors:0 dropped:0 overruns:0 frame:0
          TX packets:159626412 errors:0 dropped:47 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:26284111395 (25066.4 Mb)  TX bytes:215289850474 (205316.4 Mb)

eth1      Link encap:Ethernet  HWaddr 00:01:C0:09:A6:09 
          inet addr:96.57.23.82  Bcast:96.57.23.87  Mask:255.255.255.248
          inet6 addr: fe80::201:c0ff:fe09:a609/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:215594509 errors:0 dropped:0 overruns:0 frame:0
          TX packets:211084673 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:207744711749 (198120.7 Mb)  TX bytes:181633443872 (173219.1 Mb)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:6250503 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6250503 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:601530253 (573.6 Mb)  TX bytes:601530253 (573.6 Mb)



Seems pretty straight forward.

Now just because I don't have a problem doesn't mean you don't have a problem, but frankly the current solution seems to me to be far worst than the problem.  The devices are being assigned names at boot time by scripts that we write.  How is it possible to add a network device while not being physically at the machine?  And how can it possibly be changed with reboot?

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #6 –
FWIW, we try to avoid network manager as a personal choice..
 

Re: If networkmanager gives you long network interface names return to eth0 & wlan0

Reply #7 –
Quote
With all due respect, this is FUD.  We've used this system for decades without trouble.  I don't want to think deeply about my two Ethernet cards.  I expect one to be eth0 and the other to be eth1.
With all due respect, just because you have not experienced this problem does not mean that others have not. I have personally had this happen on a server I was working on remotely. I had to go there physically to fix things.
Chris Cromer