Edit your
/etc/default/grub change GRUB_CMDLINE_LINUX="" to :
GRUB_CMDLINE_LINUX="net.ifnames=0"
If the biosdevname is installed you need to add :
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
$ 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.
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
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.
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 ?? :)
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.
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?
FWIW, we try to avoid network manager as a personal choice..
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.