I just got a new DELL Precision 7610 with two ethernet connections on the motherboard. Each have their own hardware address. I am running Fedora 20. When I reboot the system often I end up with no network connection. I am using static IP and really just need one connection. The configured connection by the system "em1" has the HW addresss of one of the ports. Only one line is connected to the net. I get different names when I connect like, enp0s25, enp70s. The enp0s25 seems to be the right one when it works, One highly irregular solution I found is to create em2 with the other HW address but with all the same IP information. When the system boots it would find one but the other conflicts so I take both down with ifdown and ifup the correct one. I need a stable solution to this since I would like to do remote reboots of the system and cannot risk loosing the connection.
Can you grab /var/log/messages for the system when the problem occurs? This may be related to udev renaming the devices and racing with NetworkManager, which in F20 does not yet handle interface renaming as well as we'd like. But logs will help narrow down the cause. Thanks!
Thanks. I am out of town until next week but will do so asap.
OK. Here is some more info: As far as I can tell the problem stems which port the system assigns to static ip setup, defined as "em1". The two ports are named enp7s0 and enp0s25 by, I guess, the kernel. So, at each reboot the static ip assigned to either one of these names and if the cable is plugged in to the right one it works. I attached two log files, one with both ports plugged in and other other only one (which did not work initially since the cable was not plugged into that port). One solution I found is to have both ports plugged in but I don't want to do this since I may need one of these for another interface. As an example the current ifconfig gives (mic0 is Xeon PHI co-processor card): enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::fab1:56ff:fed0:58e5 prefixlen 64 scopeid 0x20<link> ether f8:b1:56:d0:58:e5 txqueuelen 1000 (Ethernet) RX packets 32099 bytes 3964855 (3.7 MiB) RX errors 0 dropped 102 overruns 0 frame 0 TX packets 8 bytes 680 (680.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 20 memory 0xe7700000-e7720000 enp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 129.59.116.43 netmask 255.255.254.0 broadcast 129.59.117.255 inet6 fe80::fab1:56ff:fed0:5931 prefixlen 64 scopeid 0x20<link> ether f8:b1:56:d0:59:31 txqueuelen 1000 (Ethernet) RX packets 62238 bytes 11234921 (10.7 MiB) RX errors 0 dropped 93 overruns 0 frame 0 TX packets 44909 bytes 50331220 (47.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xe7100000-e7200000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 669 bytes 98199 (95.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 669 bytes 98199 (95.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 mic0: flags=67<UP,BROADCAST,RUNNING> mtu 64512 inet 172.31.1.254 netmask 255.255.255.0 broadcast 172.31.1.255 inet6 fe80::4e79:baff:fe3c:2d3 prefixlen 64 scopeid 0x20<link> ether 4c:79:ba:3c:02:d3 txqueuelen 1000 (Ethernet) RX packets 6 bytes 468 (468.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 12 bytes 816 (816.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Created attachment 886898 [details] Two cables plugged in
Created attachment 886899 [details] One cable plugged in
Kernel/drivers traditionally name Ethernet interfaces as eth0, eth1, ... But because the probing doesn't happen in the same order, the interface names can be assigned to different interfaces for each boot. To solve this issue udev now renames the interfaces to the funny names like enp0s25 and enp7s0. However these names are guaranteed to be assigned always to the same device. So in your case, e1000e 0000:00:19.0 ethX: (PCI Express:2.5GT/s:Width x1) f8:b1:56:d0:58:e5 will be given enp0s25 igb 0000:07:00.0: ethX: (PCIe:2.5Gb/s:Width x1) f8:b1:56:d0:59:31 will be given enp7s0 I can see in the logs that 'em1' connection was successfully activated on enp7s0. So the configuration depends on what you want. If you need just one of the devices to be used, plug the cable to the proper socket and change the ifcfg-em1 file to contain proper hardware address in HWADDR or interface name in DEVICE (HWADDR=f8:b1:56:d0:59:31, DEVICE=enp7s0). Also you might want to rename ifcfg-em1 to ifcfg-enp7s0. And you can create fcfg-enp0s25 for enp0s25 with corresponding HWADDR or DEVICE). If you want a generic profile that would apply to both devices and will be activated with the one which is plugged, create e.g. ifcfg-ethernet and remove both HWADDR and DEVICE from the file. As Dan said there might be an issue when udev renames interfaces *after* NetworkManager is started. But that's not the problem in your case, because logs suggest that udev renaming has been done before NetworkManager started. So NM sees the new names.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.