I have to install Matlab on a Fedora 20 machine and I need to rename the network device to eth0, or else Matlab won't install. This is a known issue:
http://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-m...
So, to revert to eth0, I follow these instructions:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...
It says I have 4 options. I did ALL of them and still
[root@phoenix ~]# /sbin/ifconfig em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.40 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::20c:f1ff:febc:29fe prefixlen 64 scopeid 0x20<link> ether 00:0c:f1:bc:29:fe txqueuelen 1000 (Ethernet) RX packets 713 bytes 306565 (299.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 979 bytes 131054 (127.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
etc.
Specifically, I have masked /usr/lib/udev/rules.d/80-net-name-slot.rules by creating a link /etc/udev/rules.d/80-net-name-slot.rules -> /dev/null.
[root@phoenix ~]# ls -l /etc/udev/rules.d/ total 8 -rw-r--r--. 1 root root 151 Jul 6 20:31 70-persistent-net.rules lrwxrwxrwx. 1 root root 9 Jul 20 10:36 80-net-name-slot.rules -> /dev/null -rw-r--r--. 1 root root 352 Apr 3 04:36 98-kexec.rules
I also have an /etc/udev/rules.d/70-persistent-net.rules:
[root@phoenix ~]# cat /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:f1:bc:29:fe", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I also passed net.ifnames=0 to the kernel upon boot:
[root@phoenix ~]# dmesg | grep ifnames [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.15.6-200.fc20.i686+PAE root=UUID=aa696c85-f1d4-4bf3-9a93-b011ec8e9a6a ro vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 LANG=en_US.UTF-8
Someone must have figured this out. Can anybody please help me solve this?
Also, NetworkManager might have something to do with this, because if I right-click the NW applet -> Edit Connections, I do have a connection named eth0, but if I try to edit that, the device MAC address is
00:0c:f1:bc:29:fe (em1)
So NW somehow likes em1, despite all my efforts. If I stop and disable NW, then the network does not even start upon boot, as it should. How do I tell NW to leave my network alone and still have the network start upon boot?
Thanks!
On Sun, 20 Jul 2014 15:54:41 +0000 (UTC) "Amadeus W.M." amadeus84@verizon.net wrote:
I have to install Matlab on a Fedora 20 machine and I need to rename the network device to eth0, or else Matlab won't install. This is a known issue:
http://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-m...
So, to revert to eth0, I follow these instructions:
...snip...
So NW somehow likes em1, despite all my efforts. If I stop and disable NW, then the network does not even start upon boot, as it should. How do I tell NW to leave my network alone and still have the network start upon boot?
Two things leap to mind:
1. Do you have the 'biosdevname' package installed? It's yet another older way of renaming things. You can simply remove it if you do, or pass biosdevname=0 on the boot line to disable it.
2. Check /etc/sysconfig/network-scripts/ifcfg* files... move them to the names with the mac addresses that you want.
kevin
On Sun, 20 Jul 2014 09:59:15 -0600, Kevin Fenzi wrote:
On Sun, 20 Jul 2014 15:54:41 +0000 (UTC) "Amadeus W.M." amadeus84@verizon.net wrote:
I have to install Matlab on a Fedora 20 machine and I need to rename the network device to eth0, or else Matlab won't install. This is a known issue:
http://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-m...
So, to revert to eth0, I follow these instructions:
...snip...
So NW somehow likes em1, despite all my efforts. If I stop and disable NW, then the network does not even start upon boot, as it should. How do I tell NW to leave my network alone and still have the network start upon boot?
Two things leap to mind:
- Do you have the 'biosdevname' package installed? It's yet another
older way of renaming things. You can simply remove it if you do, or pass biosdevname=0 on the boot line to disable it.
I tried that (biosdevname=0) first, before I saw the new ways. No go.
- Check /etc/sysconfig/network-scripts/ifcfg* files... move them to
the names with the mac addresses that you want.
kevin
[root@phoenix ~]# ls /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-lo
[root@phoenix ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet BOOTPROTO=none DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT=yes IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" NAME="eth0" UUID="8b3948d3-4447-4016-8d24-1e26f65a3008" ONBOOT=yes IPADDR0=192.168.1.40 PREFIX0=24 GATEWAY0=192.168.1.1 DNS1=192.168.1.1 USERCTL=no HWADDR=00:0C:F1:BC:29:FE IPV6_PEERDNS=yes IPV6_PEERROUTES=yes
That's why I'm so baffled. Neither the old nor the new methods work.
If I boot interactively, what should I be looking for?
On Sun, 20 Jul 2014 16:13:23 +0000 (UTC) "Amadeus W.M." amadeus84@verizon.net wrote:
I tried that (biosdevname=0) first, before I saw the new ways. No go.
Well, it's possible, and even likely that you have both. ;)
ie, you are disabling the systemd one, but the biosdevname one kicks in then. In any case, if you have it installed, yum remove biosdevname that will rule it out.
- Check /etc/sysconfig/network-scripts/ifcfg* files... move them to
the names with the mac addresses that you want.
[root@phoenix ~]# ls /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-lo
[root@phoenix ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet BOOTPROTO=none DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT=yes IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" NAME="eth0" UUID="8b3948d3-4447-4016-8d24-1e26f65a3008" ONBOOT=yes IPADDR0=192.168.1.40 PREFIX0=24 GATEWAY0=192.168.1.1 DNS1=192.168.1.1 USERCTL=no HWADDR=00:0C:F1:BC:29:FE IPV6_PEERDNS=yes IPV6_PEERROUTES=yes
That's why I'm so baffled. Neither the old nor the new methods work.
And that HWADDR is correct for the interface you want to be eth0?
If I boot interactively, what should I be looking for?
I'd look in dmesg first... it should say it's renaming eth0 to em1 or whatever there...
kevin
On Sun, 20 Jul 2014, Amadeus W.M. wrote:
On Sun, 20 Jul 2014 09:59:15 -0600, Kevin Fenzi wrote:
That's why I'm so baffled. Neither the old nor the new methods work.
If I boot interactively, what should I be looking for?
Has anybody referred you to this?
http://www.cyberciti.biz/faq/howto-linux-rename-ethernet-devices-named-using...
I have no idea if it works, but it seems straightforward...
billo
Has anybody referred you to this?
http://www.cyberciti.biz/faq/howto-linux-rename-ethernet-devices-named-
using-udev/
I have no idea if it works, but it seems straightforward...
billo
Not that particular link, but that's covered here:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...
which seems official and is up-to-date.
On Sun, 20 Jul 2014 15:54:41 +0000, Amadeus W.M. wrote:
I have to install Matlab on a Fedora 20 machine and I need to rename the network device to eth0, or else Matlab won't install. This is a known issue:
http://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-m...
So, to revert to eth0, I follow these instructions:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...
It says I have 4 options. I did ALL of them and still
[root@phoenix ~]# /sbin/ifconfig em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.40 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::20c:f1ff:febc:29fe prefixlen 64 scopeid 0x20<link> ether 00:0c:f1:bc:29:fe txqueuelen 1000 (Ethernet) RX packets 713 bytes 306565 (299.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 979 bytes 131054 (127.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
etc.
Specifically, I have masked /usr/lib/udev/rules.d/80-net-name-slot.rules by creating a link /etc/udev/rules.d/80-net-name-slot.rules -> /dev/null.
[root@phoenix ~]# ls -l /etc/udev/rules.d/ total 8 -rw-r--r--. 1 root root 151 Jul 6 20:31 70-persistent-net.rules lrwxrwxrwx. 1 root root 9 Jul 20 10:36 80-net-name-slot.rules -> /dev/null -rw-r--r--. 1 root root 352 Apr 3 04:36 98-kexec.rules
I also have an /etc/udev/rules.d/70-persistent-net.rules:
[root@phoenix ~]# cat /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:f1:bc:29:fe", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I also passed net.ifnames=0 to the kernel upon boot:
[root@phoenix ~]# dmesg | grep ifnames [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.15.6-200.fc20.i686+PAE root=UUID=aa696c85-f1d4-4bf3-9a93-b011ec8e9a6a ro vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 LANG=en_US.UTF-8
Someone must have figured this out. Can anybody please help me solve this?
Also, NetworkManager might have something to do with this, because if I right-click the NW applet -> Edit Connections, I do have a connection named eth0, but if I try to edit that, the device MAC address is
00:0c:f1:bc:29:fe (em1)
So NW somehow likes em1, despite all my efforts. If I stop and disable NW, then the network does not even start upon boot, as it should. How do I tell NW to leave my network alone and still have the network start upon boot?
Thanks!
More on this. Network Manager seems to do the right thing. In /var/log/messages:
Jul 20 12:44:33 phoenix NetworkManager[1684]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... Jul 20 12:44:33 phoenix NetworkManager[1684]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... Jul 20 12:44:33 phoenix NetworkManager[1684]: ifcfg-rh: read connection 'eth0'
So it reads /etc/sysconfig/network-scripts/ifcfg-eth0. Then
[root@phoenix ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE="Ethernet" BOOTPROTO=none DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" NAME="eth0" UUID="8b3948d3-4447-4016-8d24-1e26f65a3008" ONBOOT="yes" HWADDR=00:0C:F1:BC:29:FE IPADDR0=192.168.1.40 PREFIX0=24 GATEWAY0=192.168.1.1 DNS1=192.168.1.1 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes
Could avahi be doing something funny?
Jul 20 12:38:15 phoenix avahi-daemon[478]: Network interface enumeration completed.
On 07/20/2014 10:54 AM, Amadeus W.M. wrote:
Also, NetworkManager might have something to do with this, because if I right-click the NW applet -> Edit Connections, I do have a connection named eth0, but if I try to edit that, the device MAC address is
00:0c:f1:bc:29:fe (em1)
So NW somehow likes em1, despite all my efforts. If I stop and disable NW, then the network does not even start upon boot, as it should. How do I tell NW to leave my network alone and still have the network start upon boot?
If you disable NM, you need to enable network. From a local console (in other words, don't do this over a network session like ssh):
systemctl disable NetworkManager.service systemctl stop NetworkManager.service systemctl enable network systemctl start network
Thomas
On Sun, Jul 20, 2014 at 1:49 PM, Thomas Cameron < thomas.cameron@camerontech.com> wrote:
If you disable NM, you need to enable network. From a local console (in other words, don't do this over a network session like ssh):
systemctl disable NetworkManager.service systemctl stop NetworkManager.service systemctl enable network systemctl start network
Thomas
D oesn't this prevent you from connecting to open hotspots? The nm-applet will not be able to communicate with NM and thus will not be able to list detected ssid's.
On 07/20/2014 01:30 PM, JD wrote:
D oesn't this prevent you from connecting to open hotspots? The nm-applet will not be able to communicate with NM and thus will not be able to list detected ssid's.
Not everybody is using a laptop. Right now, I'm working on a desktop that's connected to my router by Cat 5. Why would I care if I can't connect to open hotspots, especially when you consider that this computer doesn't even have a wireless card.
On Sun, Jul 20, 2014 at 2:41 PM, Joe Zeff joe@zeff.us wrote:
On 07/20/2014 01:30 PM, JD wrote:
D oesn't this prevent you from connecting to open hotspots?
The nm-applet will not be able to communicate with NM and thus will not be able to list detected ssid's.
Not everybody is using a laptop. Right now, I'm working on a desktop
that's connected to my router by Cat 5. Why would I care if I can't connect to open hotspots, especially when you consider that this computer doesn't even have a wireless card.
Well, desktop fans will soon fall into the minority :)
On 07/20/2014 03:16 PM, JD wrote:
Well, desktop fans will soon fall into the minority :)
Don't bet on it. A desktop not only gives you more bang for the buck than a laptop, it's much easier to upgrade or expand. In fact, I've never yet needed to buy a pre-built desktop because I have a good friend who's a hardware geek. The two of us figure out what I'm going to need, I buy it and he puts it together. (Part of his pay is what's left of my old computer, giving him spare parts for people who need repairs but can't afford to buy new hardware.)
On Sun, 20 Jul 2014 16:16:15 -0600 JD jd1008@gmail.com wrote:
Well, desktop fans will soon fall into the minority :)
Comparing the number of smartphones, tablets and laptops to desktops, they already are a minority. However...
If anything, the paradigm of a "workstation" is certainly not going away. Programming, web design, business&office, CAD, animation and video production, gaming --- those are only some of typical real world usecases that need a large enough (or even high-end) display, a serious keyboard, and serious processing power with an extendable amount of RAM.
None of this can be done (not seriously, anyway) on a laptop, let alone the tablet or a phone. So there will always be a market for desktops.
HTH, :-) Marko
Amadeus W.M. wrote:
This is degenerating in an off-topic discussion. The question is how to rename the network device back to eth0. Let's focus.
As a matter of interest, what happens if in /etc/sysconfig/network-scripts you write ifcfg-enp2s0, say, as DEVICE=eth1 TYPE=Ethernet ... ? I did this by mistake and the interface seemed to be called eth1, in some places at least. I changed it when I saw my mistake, so I don't know how it would have worked. (I'm running the network service on my server, not NM.)
On Sun, 20 Jul 2014 23:51:27 +0000 (UTC) Amadeus W.M. wrote:
This is degenerating in an off-topic discussion. The question is how to rename the network device back to eth0. Let's focus.
At this point, "use the source, Luke" appears to be the only option :-(
I see on my system in dmesg output this string:
[ 4.173161] systemd-udevd[420]: renamed network interface eth0 to em1
If I run "strings" on /usr/lib/systemd/systemd-udevd, I find this:
renamed network interface %s to %s
So, if you really want to be fanatical, you could download the source rpm for systemd, "rpmbuild -bp" it to expand the source tree, then search the source for the string "renamed network interface" and work backward from there to see if there is a path the code can be induced to go through that won't do the rename :-).
Or maybe it would be simpler to use a binary editor on the "Matlab" code and change all "eth0" strings to "em1" :-).
On Sun, 20 Jul 2014 20:55:46 -0400, Tom Horsley wrote:
On Sun, 20 Jul 2014 23:51:27 +0000 (UTC) Amadeus W.M. wrote:
This is degenerating in an off-topic discussion. The question is how to rename the network device back to eth0. Let's focus.
At this point, "use the source, Luke" appears to be the only option :-(
I see on my system in dmesg output this string:
[ 4.173161] systemd-udevd[420]: renamed network interface eth0 to em1
Oh, crap, I have that too:
[root@phoenix ~]# dmesg | grep -i udev [ 1.400371] systemd-udevd[196]: starting version 208 [ 2.059372] systemd-udevd[203]: renamed network interface eth0 to em1 [ 10.486478] systemd-udevd[385]: starting version 208
It's doing exactly the opposite of what I want.
On 07/20/2014 08:08 PM, Amadeus W.M. wrote:
On Sun, 20 Jul 2014 20:55:46 -0400, Tom Horsley wrote:
On Sun, 20 Jul 2014 23:51:27 +0000 (UTC) Amadeus W.M. wrote:
This is degenerating in an off-topic discussion. The question is how to rename the network device back to eth0. Let's focus.
At this point, "use the source, Luke" appears to be the only option :-(
I see on my system in dmesg output this string:
[ 4.173161] systemd-udevd[420]: renamed network interface eth0 to em1
Oh, crap, I have that too:
[root@phoenix ~]# dmesg | grep -i udev [ 1.400371] systemd-udevd[196]: starting version 208 [ 2.059372] systemd-udevd[203]: renamed network interface eth0 to em1 [ 10.486478] systemd-udevd[385]: starting version 208
It's doing exactly the opposite of what I want.
Have you tried this?
http://www.cyberciti.biz/faq/howto-linux-rename-ethernet-devices-named-using...
On 07/20/2014 09:39 PM, Thomas Cameron wrote:
It's doing exactly the opposite of what I want.
Have you tried this?
http://www.cyberciti.biz/faq/howto-linux-rename-ethernet-devices-named-using...
I have the same issue, and I don't have this file they say to modify.. no |70-persistent-net.rules| To rename eth0 as wan0, edit a file called 70-persistent-net.rules in/etc/udev/rules.d/ directory, enter: |# vi /etc/udev/rules.d/70-persistent-net.rules|file not there..
On Mon, 21 Jul 2014, Paul Cartwright wrote:
On 07/20/2014 09:39 PM, Thomas Cameron wrote:
It's doing exactly the opposite of what I want.
Have you tried this?
http://www.cyberciti.biz/faq/howto-linux-rename-ethernet-devices-named-using...
I have the same issue, and I don't have this file they say to modify.. no |70-persistent-net.rules| To rename eth0 as wan0, edit a file called 70-persistent-net.rules in/etc/udev/rules.d/ directory, enter: |# vi /etc/udev/rules.d/70-persistent-net.rules|file not there..
I don't think you modify it. I think you create it.
billo
On 07/20/2014 08:08 PM, Amadeus W.M. wrote:
On Sun, 20 Jul 2014 20:55:46 -0400, Tom Horsley wrote:
On Sun, 20 Jul 2014 23:51:27 +0000 (UTC) Amadeus W.M. wrote:
This is degenerating in an off-topic discussion. The question is how to rename the network device back to eth0. Let's focus.
At this point, "use the source, Luke" appears to be the only option :-(
I see on my system in dmesg output this string:
[ 4.173161] systemd-udevd[420]: renamed network interface eth0 to em1
Oh, crap, I have that too:
[root@phoenix ~]# dmesg | grep -i udev [ 1.400371] systemd-udevd[196]: starting version 208 [ 2.059372] systemd-udevd[203]: renamed network interface eth0 to em1 [ 10.486478] systemd-udevd[385]: starting version 208
It's doing exactly the opposite of what I want.
One more link, then I'm out of ideas:
http://reactivated.net/writing_udev_rules.html#example-netif
On Sun, 20 Jul 2014 20:42:57 -0500, Thomas Cameron wrote:
On 07/20/2014 08:08 PM, Amadeus W.M. wrote:
On Sun, 20 Jul 2014 20:55:46 -0400, Tom Horsley wrote:
On Sun, 20 Jul 2014 23:51:27 +0000 (UTC) Amadeus W.M. wrote:
This is degenerating in an off-topic discussion. The question is how to rename the network device back to eth0. Let's focus.
At this point, "use the source, Luke" appears to be the only option :-(
I see on my system in dmesg output this string:
[ 4.173161] systemd-udevd[420]: renamed network interface eth0 to em1
Oh, crap, I have that too:
[root@phoenix ~]# dmesg | grep -i udev [ 1.400371] systemd-udevd[196]: starting version 208 [ 2.059372] systemd-udevd[203]: renamed network interface eth0 to em1 [ 10.486478] systemd-udevd[385]: starting version 208
It's doing exactly the opposite of what I want.
One more link, then I'm out of ideas:
http://reactivated.net/writing_udev_rules.html#example-netif
That may be useful. Looks like udevinfo is superseeded by udevadm. Other than that, udevadm shows no sign of eth0:
[root@phoenix ~]# udevadm info --query=all --path /sys/class/net/em1 P: /devices/pci0000:00/0000:00:1e.0/0000:02:0c.0/net/em1 E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:02:0c.0/net/em1 E: ID_BUS=pci E: ID_MM_CANDIDATE=1 E: ID_MODEL_FROM_DATABASE=82540EM Gigabit Ethernet Controller E: ID_MODEL_ID=0x100e E: ID_NET_NAME_MAC=enx000cf1bc29fe E: ID_NET_NAME_PATH=enp2s12 E: ID_OUI_FROM_DATABASE=Intel Corporation E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: ID_VENDOR_ID=0x8086 E: IFINDEX=2 E: INTERFACE=em1 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/em1 E: TAGS=:systemd: E: USEC_INITIALIZED=555769
This a useful tool I didn't know about, but it will take some time to sort everything out.
Thanks!
On 07/20/2014 09:08 PM, Amadeus W.M. wrote:
That may be useful. Looks like udevinfo is superseeded by udevadm. Other than that, udevadm shows no sign of eth0:
[root@phoenix ~]# udevadm info --query=all --path /sys/class/net/em1 P: /devices/pci0000:00/0000:00:1e.0/0000:02:0c.0/net/em1 E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:02:0c.0/net/em1 E: ID_BUS=pci E: ID_MM_CANDIDATE=1 E: ID_MODEL_FROM_DATABASE=82540EM Gigabit Ethernet Controller E: ID_MODEL_ID=0x100e E: ID_NET_NAME_MAC=enx000cf1bc29fe E: ID_NET_NAME_PATH=enp2s12 E: ID_OUI_FROM_DATABASE=Intel Corporation E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: ID_VENDOR_ID=0x8086 E: IFINDEX=2 E: INTERFACE=em1 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/em1 E: TAGS=:systemd: E: USEC_INITIALIZED=555769
This a useful tool I didn't know about, but it will take some time to sort everything out.
Thanks!
I just tested on my machine... All I did was add net.ifnames=0 to the linux16 line of /boot/grub2/grub.conf:
[tcameron@case ~]$ grep vmlinuz /boot/grub2/grub.cfg linux16 /vmlinuz-3.10.0-123.4.2.el7.x86_64 root=UUID=e69ef7fa-d3c3-4d88-972b-31c7cb65777c ro vconsole.keymap=us vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8 net.ifnames=0
I made my network config files look like this:
[tcameron@case Desktop]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=90:2B:34:A8:63:06 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no
[tcameron@case Desktop]$ cat /etc/sysconfig/network-scripts/ifcfg-br0 DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0
After a reboot, I get this:
[tcameron@case ~]$ ifconfig br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.31.100.4 netmask 255.255.255.0 broadcast 172.31.100.255 inet6 fe80::922b:34ff:fea8:6306 prefixlen 64 scopeid 0x20<link> ether 90:2b:34:a8:63:06 txqueuelen 0 (Ethernet) RX packets 156389 bytes 713077279 (680.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 84468 bytes 49169937 (46.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::922b:34ff:fea8:6306 prefixlen 64 scopeid 0x20<link> ether 90:2b:34:a8:63:06 txqueuelen 1000 (Ethernet) RX packets 513040 bytes 738615315 (704.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 84478 bytes 49223871 (46.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I made exactly no other changes that the files mentioned above. No udev rules, nothing.
Now, this is a Fedora 19-based system (RHEL7), but this should work on F20 as well.
Thomas
I just tested on my machine... All I did was add net.ifnames=0 to the linux16 line of /boot/grub2/grub.conf:
[tcameron@case ~]$ grep vmlinuz /boot/grub2/grub.cfg linux16 /vmlinuz-3.10.0-123.4.2.el7.x86_64 root=UUID=e69ef7fa-d3c3-4d88-972b-31c7cb65777c ro vconsole.keymap=us vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8 net.ifnames=0
I made my network config files look like this:
[tcameron@case Desktop]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=90:2B:34:A8:63:06 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no
That did it! The
DEVICE=eth0
in ifcfg-eth0 did it. I didn't have that in my (automatically generated) ifcfg-eth0. Once I added that it worked. Matlab is now up and running! Thank you very much!
On a final note, net.ifnames=0 works in conjunction with /usr/lib/udev/rules.d/80-net-name-slot.rules:
cat /usr/lib/udev/rules.d/80-net-name-slot.rules # do not edit this file, it will be overwritten on update
ACTION!="add", GOTO="net_name_slot_end" SUBSYSTEM!="net", GOTO="net_name_slot_end" NAME!="", GOTO="net_name_slot_end"
IMPORT{cmdline}="net.ifnames" ENV{net.ifnames}=="0", GOTO="net_name_slot_end"
NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}" NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}" NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
LABEL="net_name_slot_end"
If this rule is shadowed by a custom rule in /etc/udev/rules.d, then obviously net.ifnames=0 has no effect. But the custom rules should take care of it. You didn't have any custom rules, so net.ifnames worked as expected. I removed all my custom rules in /etc/udev/rules.d. DEVICE=eth0 was what I was missing though.
On 07/20/2014 03:30 PM, JD wrote:
On Sun, Jul 20, 2014 at 1:49 PM, Thomas Cameron <thomas.cameron@camerontech.com mailto:thomas.cameron@camerontech.com> wrote:
If you disable NM, you need to enable network. From a local console (in other words, don't do this over a network session like ssh): systemctl disable NetworkManager.service systemctl stop NetworkManager.service systemctl enable network systemctl start network ThomasD oesn't this prevent you from connecting to open hotspots? The nm-applet will not be able to communicate with NM and thus will not be able to list detected ssid's.
Fair point.
So disable NM for the eth0 interface only and turn on the network service.
Change NM_CONTROLLED=yes to NM_CONTROLLED=no in the ifcfg-eth0 file. Then NM will stop managing that interface, but still manage the wifi interface.
Thomas
On Sun, 20 Jul 2014 19:50:44 -0500, Thomas Cameron wrote:
On 07/20/2014 03:30 PM, JD wrote:
On Sun, Jul 20, 2014 at 1:49 PM, Thomas Cameron <thomas.cameron@camerontech.com mailto:thomas.cameron@camerontech.com> wrote:
If you disable NM, you need to enable network. From a local console (in other words, don't do this over a network session like ssh): systemctl disable NetworkManager.service systemctl stop NetworkManager.service systemctl enable network systemctl start network ThomasD oesn't this prevent you from connecting to open hotspots? The nm-applet will not be able to communicate with NM and thus will not be able to list detected ssid's.
Fair point.
So disable NM for the eth0 interface only and turn on the network service.
Change NM_CONTROLLED=yes to NM_CONTROLLED=no in the ifcfg-eth0 file. Then NM will stop managing that interface, but still manage the wifi interface.
Thomas
Yes, I remember now, that's how you tell NM to leave your network card alone. Regardless, though, I disabled NM alltogether and enabled and started network.service so now the card is no longer under NM and I have network. However, the device is still named em1.
If you disable NM, you need to enable network. From a local console (in other words, don't do this over a network session like ssh):
systemctl disable NetworkManager.service systemctl stop NetworkManager.service systemctl enable network systemctl start network
Thomas
Unfortunately the device is sill named em1, not eth0. So it's not NM. I don't understand why the udev rules files are ignored. Bug maybe? I'll report it and see what happens.
On Sun, 20 Jul 2014 23:53:33 +0000 (UTC) "Amadeus W.M." amadeus84@verizon.net wrote:
Unfortunately the device is sill named em1, not eth0. So it's not NM. I don't understand why the udev rules files are ignored. Bug maybe? I'll report it and see what happens.
AFAIK udev rules allow you to rename your network device to any name *except* to eth. The eth namespace is reserved for the kernel, and udev will refuse to rename anything to that. But it should work for any other name you choose, like lan0, net0, etc. I remember reading about this somewhere, but atm cannot find the right link. But the essential explanation is given here:
http://lists.us.dell.com/pipermail/linux-desktops/2011-February/003762.html
The only thing I can think of is to pass
biosdevname=0 net.ifnames=0
to the kernel, and hope.
But the real solution is to talk to Matlab developers and ask them to fix their software (if you paid for it, you should have some leverage in that). The eth namespace is not coming back, and the sooner they fix their software, the better for their customers.
HTH, :-) Marko
On Mon, 21 Jul 2014 04:40:16 +0100, Marko Vojinovic wrote:
On Sun, 20 Jul 2014 23:53:33 +0000 (UTC) "Amadeus W.M." amadeus84@verizon.net wrote:
Unfortunately the device is sill named em1, not eth0. So it's not NM. I don't understand why the udev rules files are ignored. Bug maybe? I'll report it and see what happens.
AFAIK udev rules allow you to rename your network device to any name *except* to eth. The eth namespace is reserved for the kernel, and udev will refuse to rename anything to that. But it should work for any other name you choose, like lan0, net0, etc. I remember reading about this somewhere, but atm cannot find the right link. But the essential explanation is given here:
http://lists.us.dell.com/pipermail/linux-desktops/2011-February/003762.html
Interesting, although I got it to work. Now I'm thinking that what I did shouldn't have worked.
But the real solution is to talk to Matlab developers and ask them to fix their software (if you paid for it, you should have some leverage in that). The eth namespace is not coming back, and the sooner they fix their software, the better for their customers.
HTH, :-) Marko
Of course, that's the right course of action, but there must be a critical mass of requests for them to bother, I think. So far it's just me and another guy. Don't know if they've fixed it in recent versions (2014) but this install is on a 32-bit pc and the last 32-bit linux version they have is 2012a, which I doubt they'll fix. I'm stuck with it for the life of this pc.
On 20.07.2014 17:54, Amadeus W.M. wrote:
I have to install Matlab on a Fedora 20 machine and I need to rename the network device to eth0, or else Matlab won't install. This is a known issue:
http://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-m...
So, to revert to eth0, I follow these instructions:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...
It says I have 4 options. I did ALL of them and still
[root@phoenix ~]# /sbin/ifconfig em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.40 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::20c:f1ff:febc:29fe prefixlen 64 scopeid 0x20<link> ether 00:0c:f1:bc:29:fe txqueuelen 1000 (Ethernet) RX packets 713 bytes 306565 (299.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 979 bytes 131054 (127.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
etc.
Specifically, I have masked /usr/lib/udev/rules.d/80-net-name-slot.rules by creating a link /etc/udev/rules.d/80-net-name-slot.rules -> /dev/null.
[root@phoenix ~]# ls -l /etc/udev/rules.d/ total 8 -rw-r--r--. 1 root root 151 Jul 6 20:31 70-persistent-net.rules lrwxrwxrwx. 1 root root 9 Jul 20 10:36 80-net-name-slot.rules -> /dev/null -rw-r--r--. 1 root root 352 Apr 3 04:36 98-kexec.rules
I also have an /etc/udev/rules.d/70-persistent-net.rules:
[root@phoenix ~]# cat /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:f1:bc:29:fe", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I also passed net.ifnames=0 to the kernel upon boot:
[root@phoenix ~]# dmesg | grep ifnames [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.15.6-200.fc20.i686+PAE root=UUID=aa696c85-f1d4-4bf3-9a93-b011ec8e9a6a ro vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 LANG=en_US.UTF-8
Someone must have figured this out. Can anybody please help me solve this?
Also, NetworkManager might have something to do with this, because if I right-click the NW applet -> Edit Connections, I do have a connection named eth0, but if I try to edit that, the device MAC address is
00:0c:f1:bc:29:fe (em1)
So NW somehow likes em1, despite all my efforts. If I stop and disable NW, then the network does not even start upon boot, as it should. How do I tell NW to leave my network alone and still have the network start upon boot?
Thanks!
[systemd-devel] 70-persistent-net.rules http://lists.freedesktop.org/archives/systemd-devel/2013-April/010343.html
README.Fedora-18 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/README.Fedora-18?h=f18#n...
0005-F18-Revert-udev-network-device-renaming-immediately-.patch http://pkgs.fedoraproject.org/cgit/systemd.git/plain/0005-F18-Revert-udev-ne...
udev: network device renaming - immediately give up if the target name isn't available http://cgit.freedesktop.org/systemd/systemd/commit/src/udev/udev-event.c?id=...
poma
[systemd-devel] 70-persistent-net.rules http://lists.freedesktop.org/archives/systemd-devel/2013-April/010343.html
README.Fedora-18 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/README.Fedora-18?h=f18#n...
0005-F18-Revert-udev-network-device-renaming-immediately-.patch http://pkgs.fedoraproject.org/cgit/systemd.git/plain/0005-F18-Revert-udev-ne...
udev: network device renaming - immediately give up if the target name isn't available http://cgit.freedesktop.org/systemd/systemd/commit/src/udev/udev-event.c?id=...
poma
That's very relevant! Thanks! So it might have not been the DEVICE=eth0 afterall and in fact it can fail again?
On 21.07.2014 07:35, Amadeus W.M. wrote:
[systemd-devel] 70-persistent-net.rules http://lists.freedesktop.org/archives/systemd-devel/2013-April/010343.html
README.Fedora-18 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/README.Fedora-18?h=f18#n...
0005-F18-Revert-udev-network-device-renaming-immediately-.patch http://pkgs.fedoraproject.org/cgit/systemd.git/plain/0005-F18-Revert-udev-ne...
udev: network device renaming - immediately give up if the target name isn't available http://cgit.freedesktop.org/systemd/systemd/commit/src/udev/udev-event.c?id=...
poma
That's very relevant! Thanks! So it might have not been the DEVICE=eth0 afterall and in fact it can fail again?
Kernel
On 21.07.2014 11:30, poma wrote:
On 21.07.2014 07:35, Amadeus W.M. wrote:
[systemd-devel] 70-persistent-net.rules http://lists.freedesktop.org/archives/systemd-devel/2013-April/010343.html
README.Fedora-18 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/README.Fedora-18?h=f18#n...
0005-F18-Revert-udev-network-device-renaming-immediately-.patch http://pkgs.fedoraproject.org/cgit/systemd.git/plain/0005-F18-Revert-udev-ne...
udev: network device renaming - immediately give up if the target name isn't available http://cgit.freedesktop.org/systemd/systemd/commit/src/udev/udev-event.c?id=...
poma
That's very relevant! Thanks! So it might have not been the DEVICE=eth0 afterall and in fact it can fail again?
Kernel
... naming mechanism you switch to 'll give you pleasure explicitly with only one real network interface. All the rest is legend.
poma
-
Amadeus W.M. -
JD -
Joe Zeff -
Kevin Fenzi -
Marko Vojinovic -
Paul Cartwright -
poma -
thomas cameron -
Timothy Murphy -
Tom Horsley -
William Oliver