Created attachment 336160 [details] emerge --info I have configured custom naming of my two network interfaces in /etc/udev/rules.d/70-persistent-net.rules but the latest udev update ignores the configuration.
You mean renaming? It's not possible to directly rename interfaces without first renaming them to something temporary, like eth0tmp1 and then to eth1. This is only a workaround. This indeed changed in 197, because there is now: /etc/udev/rules.d/80-net-name-slot.rules /lib/udev/rules.d/80-net-name-slot.rules http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Please read /etc/udev/rules.d/80-net-name-slot.rules before even trying. This commit changed it: http://cgit.freedesktop.org/systemd/systemd/commit/?id=97595710b77aa162ca5e20da57d0a1ed7355eaad Because it really never was a reliable way; kernel doesn't expect it to work. Never really did.
And for 70- to get picked up, I'm pretty sure it has to have the NAME= set something, if I don't remember wrong. WilliamH, could you remind me... us?
> I have configured custom naming of my two network interfaces in > /etc/udev/rules.d/70-persistent-net.rules but the latest udev > update ignores the configuration. Same here. Until now I'd renamed real eth0 to eth1 and real eth1 to eth0 via 70-persistent-net.rules. This is because the onboard lan was setup as eth1 and ext. card was setup as eth0 by udev. But the SfA Asterisk plugin (Skype for Asterisk - prop. module) I have in use is bound the MAC, so I choosed the ext. card in case of swapping the card in future (then in turn changing it's MAC). > You mean renaming? It's not possible to directly rename interfaces > without first renaming them to something temporary, like eth0tmp1 > and then to eth1. This is only a workaround. Well, I could live with this but have a look at this dmesg output: -------------- SNIP-------------- r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded r8169 0000:02:00.0: irq 41 for MSI/MSI-X r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xffffc9000003a000, 00:e0:45:47:00:98, XID 18000000 IRQ 41 r8169 0000:02:00.0: eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded r8169 0000:03:00.0: irq 42 for MSI/MSI-X r8169 0000:03:00.0: eth1: RTL8168b/8111b at 0xffffc90000020000, 00:1b:fc:1b:c3:d2, XID 18000000 IRQ 42 r8169 0000:03:00.0: eth1: jumbo features [frames: 4080 bytes, tx checksumming: ko] -------------- SNIP-------------- (00:e0:45:47:00:98 ext. card -> router) 00:1b:fc:1b:c3:d2 onboard card -> subnet) ...and at 'ip addr show': -------------- SNIP-------------- 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000 link/ether 00:e0:45:47:00:98 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UP qlen 1000 link/ether 00:e0:45:47:00:98 brd ff:ff:ff:ff:ff:ff 7: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:e0:45:47:00:98 brd ff:ff:ff:ff:ff:ff inet 192.168.0.2/24 brd 192.168.0.255 scope global br0 10: br1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:e0:45:47:00:98 brd ff:ff:ff:ff:ff:ff -------------- SNIP-------------- eth0 and eth1 are displaying the same MAC. (Yeah, they're bridged to br0 and br1, respectively - but same result without bridging) I tried changing the MAC via 'macchanger', with and without 70-persistent-net.rules but no luck. Routing failed then because of this new setup done by udev. Interestingly enough I got the routing and everything (except SfA) to work by swapping the ethercable from eth0 to eth1 and vice versa, leaving 70-persistent-net.rules and 80-net-name-slot.rules alone and without any entrys. Gosh...totally wierd.
Said it before, but saying it here too. Reverting http://cgit.freedesktop.org/systemd/systemd/patch/?id=97595710b77aa162ca5e20da57d0a1ed7355eaad doesn't really work out of box since the code has slightly changed since, but if someone is willing to contribute by backporting+reverting the patch, I don't have objections in putting it _TEMPORARILY_ behind USE="restore-old-persistent-net-behavior"
*** This bug has been marked as a duplicate of bug 453494 ***
