Description of problem: I just updated and rebooted my F20 router. After rebooting I noticed that it was no longer routing. On further investigation, the root cause was that the network interface names had changed. The router is dual homed, and doesn't do anything clever with interface names: they are as they were automatically assigned on installation. The file /etc/sysconfig/network-scripts/ifcfg-eno16780032 still appears to be read, as the interface is still correctly assigned to the non-default firewalld zone specified in that file. However, the line NAME="eno16780032" in that file would appear to be ignored, as the interface is now called ens192. Version-Release number of selected component (if applicable): systemd-libs-208-16.fc20.x86_64 How reproducible: Always on this machine
Can you attach output of journal for current boot? Also please attach ifcfg file and output of command "udevadm info /sys/class/net/ens192". Did you update kernel or firmware as well?
Created attachment 897627 [details] journal from current boot
Created attachment 897628 [details] /etc/sysconfig/network-scripts/ifcfg-eno16780032
Created attachment 897630 [details] /etc/sysconfig/network-scripts/ifcfg-eno33559296
[root@router ~]# udevadm info /sys/class/net/ens192 P: /devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/ens192 E: DEVPATH=/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/ens192 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=VMXNET3 Ethernet Controller E: ID_MODEL_ID=0x07b0 E: ID_NET_NAME_MAC=enx005056affa7e E: ID_NET_NAME_PATH=enp11s0 E: ID_NET_NAME_SLOT=ens192 E: ID_OUI_FROM_DATABASE=VMware, Inc. E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=VMware E: ID_VENDOR_ID=0x15ad E: IFINDEX=2 E: INTERFACE=ens192 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ens192 E: TAGS=:systemd: E: USEC_INITIALIZED=67194 [root@router ~]# udevadm info /sys/class/net/ens224 P: /devices/pci0000:00/0000:00:17.0/0000:13:00.0/net/ens224 E: DEVPATH=/devices/pci0000:00/0000:00:17.0/0000:13:00.0/net/ens224 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=VMXNET3 Ethernet Controller E: ID_MODEL_ID=0x07b0 E: ID_NET_NAME_MAC=enx005056aff99c E: ID_NET_NAME_PATH=enp19s0 E: ID_NET_NAME_SLOT=ens224 E: ID_OUI_FROM_DATABASE=VMware, Inc. E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=VMware E: ID_VENDOR_ID=0x15ad E: IFINDEX=3 E: INTERFACE=ens224 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ens224 E: TAGS=:systemd: E: USEC_INITIALIZED=67514
Created attachment 897631 [details] yum.log from yum upgrade which resulted in failure
Everything looks pretty much correct at the first glance. I need to check udev changes which went into last update. As workaround so that you don't have to change your config files, can you add DEVICE= stanza to ifcfg files such that it has desired name for each interface and reboot the machine. So just copy NAME line and replace NAME with DEVICE. That should work and you should have interfaces correctly renamed. Let me know if that temporarily fixes the issue or not.
The workaround works, thanks.
It would be interesting to see what the name would look like if you use older systemd on top of the new kernel. If you could downgrade systemd, reboot and provide udevadm info for interface that would be perfect, if not, that is all fine. I get that you don't want to suffer more downtime since machine in question is a router.
Downgraded: May 20 16:30:56 Installed: systemd-libs-208-9.fc20.x86_64 May 20 16:30:57 Installed: systemd-208-9.fc20.x86_64 May 20 16:30:57 Installed: libgudev1-208-9.fc20.x86_64 Still not working after downgrade.
However, going back to the previous kernel fixes the problem.
Working: 3.13.7-200.fc20.x86_64 Not working: 3.14.4-200.fc20 No other changes.
udev naming scheme relies on the information provided by kernel. If there were no hardware or firmware changes then I'd say this is regression in kernel. Reassigning there for comments. Matthew thanks so far for cooperation!
(In reply to Michal Sekletar from comment #13) > udev naming scheme relies on the information provided by kernel. If there > were no hardware or firmware changes then I'd say this is regression in > kernel. Reassigning there for comments. (In reply to Matthew Booth from comment #0) > the line NAME="eno16780032" > in that file would appear to be ignored, as the interface is now called > ens192. ens192 sounds like the proper default kernel name. Doesn't the issue just sound like the custom config is no longer applied, but it was before? That bug very likely needs more information what exactly behaves differently now, before the kernel people can comment on what part of *our* magic does no longer work. :)
I'm running a bisect on this, btw, in case anybody else considered doing the same. It should be finished by tomorrow. Current log: git bisect start # bad: [06eb4cc2e7ad1b32a3b2580eff772c29b53a2cc6] Merge branch 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup git bisect bad 06eb4cc2e7ad1b32a3b2580eff772c29b53a2cc6 # good: [d8ec26d7f8287f5788a494f56e8814210f0e64be] Linux 3.13 git bisect good d8ec26d7f8287f5788a494f56e8814210f0e64be # bad: [98a48237f4e61afcc4c38950e2608539eced9040] drm: Remove the unused (and unusable) DRM_LOG_MODE() git bisect bad 98a48237f4e61afcc4c38950e2608539eced9040 # bad: [82c477669a4665eb4e52030792051e0559ee2a36] Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 82c477669a4665eb4e52030792051e0559ee2a36 # good: [d4371f94bc003e912d4825f5c4bdf57959857073] Merge tag 'sound-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good d4371f94bc003e912d4825f5c4bdf57959857073
The behaviour was changed by this commit: commit 1d0fcef732832432aee47cb75bf4a2cb3107be64 Author: Jiang Liu <jiang.liu.com> Date: Thu Dec 19 20:38:13 2013 +0800 ACPI / PCI: replace open-coded _DSM code with helper functions Use helper functions to simplify _DSM related code in pci-label driver. Also enforce more strict checks on objects returned by _DSM method. Signed-off-by: Jiang Liu <jiang.liu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki>
Created attachment 924861 [details] ifcfg Attaching ifcfg after reboot
This is a Fedora 20 box as a guest on a VMWare Workstation 10 installed on Linux Mint. Just checking to see if there is an update on this and if it can be confirmed this is the same problem. Let me know if you need anything else. [root@ipa fedadmin]# ls -lagrt /etc/sysconfig/network-scripts/ | grep ifcfg -rw-r--r--. 1 root 254 Jan 14 2014 ifcfg-lo -rw-r--r--. 1 root 326 Aug 7 10:55 ifcfg-eno16777736 [root@ipa fedadmin]# udevadm info /sys/class/net/ens33 P: /devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33 E: DEVPATH=/devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33 E: ID_BUS=pci E: ID_MM_CANDIDATE=1 E: ID_MODEL_FROM_DATABASE=82545EM Gigabit Ethernet Controller (Copper) (PRO/1000 MT Single Port Adapter) E: ID_MODEL_ID=0x100f E: ID_NET_NAME_MAC=enx000c2909904e E: ID_NET_NAME_PATH=enp2s1 E: ID_NET_NAME_SLOT=ens33 E: ID_OUI_FROM_DATABASE=VMware, Inc. 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=ens33 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ens33 E: TAGS=:systemd: E: USEC_INITIALIZED=66296 [fedadmin@ipa ~]$ ifconfig ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.96.129 netmask 255.255.255.0 broadcast 172.16.96.255 inet6 fe80::20c:29ff:fe09:904e prefixlen 64 scopeid 0x20<link> ether 00:0c:29:09:90:4e txqueuelen 1000 (Ethernet) RX packets 4007 bytes 2531863 (2.4 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3452 bytes 1090719 (1.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 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 8 bytes 800 (800.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8 bytes 800 (800.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@ipa fedadmin]# uname -a Linux ipa.broreg.loc 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.