Re: [gentoo-user] Re: udev upgrade renames eth-interfaces
On Saturday 16 March 2013 12.08:23 Canek Peláez Valdés wrote: On Sat, Mar 16, 2013 at 11:03 AM, Dan Johansson dan.johans...@dmj.nu wrote: On Saturday 16 March 2013 09.39:17 Jonathan Callen wrote: Hello, Today I upgraded udev on one of my boxes (after hesitating a long time). Even if I have /etc/udev/rules.d/80-net-name-slot.rules and my old 70-persistent-net.rules in place, my interfaces gets renamed (eth0 gets swapped with eth1) which then messes up my whole configuration (routing tables and firewall rules). Any suggestion how to keep my old names and order? Udev, as of version 187, will now refuse to rename a network interface to the name of a network interface that already exists -- which, due to race conditions, can be the case if you are attempting to rename a network device to a name the kernel will later use to name the next enumerated device. The fix for this issue is to *not* use names that match eth[0-9]*, wlan[0-9]*, etc. and instead use a name that the kernel would *not* automatically assign. Unfortunately, that means that you *cannot* keep your old names and order (upstream claims that the means used to ensure those names were used was unreliable and prone to race conditions anyway, which, looking at the code, I can believe). This is great... (I hope you can hear the irony) OK, so I removed the two udev rules (70-persistent-net and 80-net-name-slot) files, thinking if this is the way the upstream devs are going then I have to check it out. That's the smart thing to do. After removing the udev-rules and rebooting I got my two new network interfaces called enp0s4 and enp0s5 (no idea what that is supposed to mean). http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c Basically, en is for ethernet, p is for PCI bus, and 0s4 and 0s5 is for the topology of the cards in your machine: the cards are in the PCI bus number 0, slot number 4 and 5. In other words, if you do find /sys -name enp0s4, I'm betting you will get something like: /sys/devices/pci:00/:00:1c.1/:00:004.0/net/enp0s4 The :00:004.0 is the part that determines the naming of yout device. This naming is deterministic: as long as you don't move the cards from PCI slot, they will be named like that always. My next step was to replace eth0 with enp0s5 and eth1 with enp0s4 in /etc/conf.d(net and create two new links (net.lo - net.enp0s[45]) in /etc/init.d Now I could start the two network interfaces (/etc/init.d/net.enp0s[45] start). BUT, as soon as I try to start some service (sshd, ntpd, ...) that is using the network I get a lot of complains that eth0 and eth1 is not started (and can not be started) and the service wont start. What have I missed??? Do you have net.eth0 or net.eth1 in /etc/rc.conf? No, but I still had the links in /etc/init.d/. Removing those and adding lins for enp0s[45] did the trick. Thanks, -- Dan Johansson, http://www.dmj.nu *** This message is printed on 100% recycled electrons! ***
[gentoo-user] Re: udev upgrade renames eth-interfaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/16/2013 09:14 AM, Dan Johansson wrote: Hello, Today I upgraded udev on one of my boxes (after hesitating a long time). Even if I have /etc/udev/rules.d/80-net-name-slot.rules and my old 70-persistent-net.rules in place, my interfaces gets renamed (eth0 gets swapped with eth1) which then messes up my whole configuration (routing tables and firewall rules). Any suggestion how to keep my old names and order? Regards, Udev, as of version 187, will now refuse to rename a network interface to the name of a network interface that already exists -- which, due to race conditions, can be the case if you are attempting to rename a network device to a name the kernel will later use to name the next enumerated device. The fix for this issue is to *not* use names that match eth[0-9]*, wlan[0-9]*, etc. and instead use a name that the kernel would *not* automatically assign. Unfortunately, that means that you *cannot* keep your old names and order (upstream claims that the means used to ensure those names were used was unreliable and prone to race conditions anyway, which, looking at the code, I can believe). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRRHYFAAoJELHSF2kinlg4d0MQAJhJs73Nlja+TGoq77TaYMOz vrJmZmPDewp+1imFjfnddhC6c5ePn5+XCQ7vWmcB3LVVh8JAOqRq1pEV/u4F3HYO 8VE5VI/s0K2MO/+8aLOOSnB91tmEmZ9ziKnIjvZPKqDKH5JB2iCShnvvgfdWIlQB HwaZknzlvl1bNCBmDfaXFoGzPmEIiyIysuzI9xFxv1/m+VOMeDkN5a7qJmC7mXld gu9Shx15Y2LBJZvQaUH8aM6Qv4BsMc9IJ0XWp/aHpbefMuj+Vb5038caRRfHqyUN aNmYmiEvvkb2IqrMSJ8x4faC3iVj/YimovEQhiDZmwaHcl2IqmlngJ1qAPk30/Lh fwUVDCTwtJ/zoOoTxGpd4zZ/wUVVPaupsOc2D7ZMXlw2o5RzsuSwRE5FrHv/0MXO Ne3I3QVHvPJvYfwi0AyOv5wHEKkCdF9MjgWqCErjEPaFUrrPuiWp4ESQp/HE5rVQ YG77ZSugSnFddZgwYenlSgDhHkkMaHV8zeNautVOPRMsvqbKbnVjEtT7YXHJBN0B OnnCQhZR7lBKCkxc5Xq/TWXe9imT/1Of8tLn80SuICthUGLgFg1tlv0AIjKmWU9q FIoQ+xD6rTav2zdPkTF86HsODqwe38br64NLPhUSfd+s7e5iiqh++XTtwTnXSKXW QbQb+npPnCZ0DgqW9aCM =/24C -END PGP SIGNATURE-
Re: [gentoo-user] Re: udev upgrade renames eth-interfaces
On Saturday 16 March 2013 09.39:17 Jonathan Callen wrote: Hello, Today I upgraded udev on one of my boxes (after hesitating a long time). Even if I have /etc/udev/rules.d/80-net-name-slot.rules and my old 70-persistent-net.rules in place, my interfaces gets renamed (eth0 gets swapped with eth1) which then messes up my whole configuration (routing tables and firewall rules). Any suggestion how to keep my old names and order? Udev, as of version 187, will now refuse to rename a network interface to the name of a network interface that already exists -- which, due to race conditions, can be the case if you are attempting to rename a network device to a name the kernel will later use to name the next enumerated device. The fix for this issue is to *not* use names that match eth[0-9]*, wlan[0-9]*, etc. and instead use a name that the kernel would *not* automatically assign. Unfortunately, that means that you *cannot* keep your old names and order (upstream claims that the means used to ensure those names were used was unreliable and prone to race conditions anyway, which, looking at the code, I can believe). This is great... (I hope you can hear the irony) OK, so I removed the two udev rules (70-persistent-net and 80-net-name-slot) files, thinking if this is the way the upstream devs are going then I have to check it out. After removing the udev-rules and rebooting I got my two new network interfaces called enp0s4 and enp0s5 (no idea what that is supposed to mean). My next step was to replace eth0 with enp0s5 and eth1 with enp0s4 in /etc/conf.d(net and create two new links (net.lo - net.enp0s[45]) in /etc/init.d Now I could start the two network interfaces (/etc/init.d/net.enp0s[45] start). BUT, as soon as I try to start some service (sshd, ntpd, ...) that is using the network I get a lot of complains that eth0 and eth1 is not started (and can not be started) and the service wont start. What have I missed??? Regards, -- Dan Johansson, http://www.dmj.nu *** This message is printed on 100% recycled electrons! ***
Re: [gentoo-user] Re: udev upgrade renames eth-interfaces
On Sat, Mar 16, 2013 at 11:03 AM, Dan Johansson dan.johans...@dmj.nu wrote: On Saturday 16 March 2013 09.39:17 Jonathan Callen wrote: Hello, Today I upgraded udev on one of my boxes (after hesitating a long time). Even if I have /etc/udev/rules.d/80-net-name-slot.rules and my old 70-persistent-net.rules in place, my interfaces gets renamed (eth0 gets swapped with eth1) which then messes up my whole configuration (routing tables and firewall rules). Any suggestion how to keep my old names and order? Udev, as of version 187, will now refuse to rename a network interface to the name of a network interface that already exists -- which, due to race conditions, can be the case if you are attempting to rename a network device to a name the kernel will later use to name the next enumerated device. The fix for this issue is to *not* use names that match eth[0-9]*, wlan[0-9]*, etc. and instead use a name that the kernel would *not* automatically assign. Unfortunately, that means that you *cannot* keep your old names and order (upstream claims that the means used to ensure those names were used was unreliable and prone to race conditions anyway, which, looking at the code, I can believe). This is great... (I hope you can hear the irony) OK, so I removed the two udev rules (70-persistent-net and 80-net-name-slot) files, thinking if this is the way the upstream devs are going then I have to check it out. That's the smart thing to do. After removing the udev-rules and rebooting I got my two new network interfaces called enp0s4 and enp0s5 (no idea what that is supposed to mean). http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c Basically, en is for ethernet, p is for PCI bus, and 0s4 and 0s5 is for the topology of the cards in your machine: the cards are in the PCI bus number 0, slot number 4 and 5. In other words, if you do find /sys -name enp0s4, I'm betting you will get something like: /sys/devices/pci:00/:00:1c.1/:00:004.0/net/enp0s4 The :00:004.0 is the part that determines the naming of yout device. This naming is deterministic: as long as you don't move the cards from PCI slot, they will be named like that always. My next step was to replace eth0 with enp0s5 and eth1 with enp0s4 in /etc/conf.d(net and create two new links (net.lo - net.enp0s[45]) in /etc/init.d Now I could start the two network interfaces (/etc/init.d/net.enp0s[45] start). BUT, as soon as I try to start some service (sshd, ntpd, ...) that is using the network I get a lot of complains that eth0 and eth1 is not started (and can not be started) and the service wont start. What have I missed??? Do you have net.eth0 or net.eth1 in /etc/rc.conf? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
