Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
29.05.2016 19:55, Michael Biebl пишет: > 2016-05-29 18:28 GMT+02:00 Lennart Poettering : >> On Sat, 28.05.16 21:38, Martin Pitt (martin.p...@ubuntu.com) wrote: >> >>> Chris Friesen [2016-05-27 9:14 -0600]: The reason why I'm poking at this is that the old scheme worked "good enough" for us for several years. Now of course the new scheme is better, but it breaks backwards compatibility. This makes it difficult to automatically upgrade an existing system to an OS using the new scheme since all the names would change. (And we've got the old interfaces stored in databases and such in our management software.) >>> >>> FTR, Debian/Ubuntu do not use the new schema on upgrades for existing >>> interfaces, just for new installs, for precisely this reason. >>> Specifically, if you already have an existing >>> /etc/udev/rules.d/70-persistent-net.rules, this will still be present >>> (and trump ifnames). But we also disable it for VM upgrades where the >>> previous persistent-net-generator was blacklisted. >> >> I am pretty sure most other distros won't remove the persistend rules >> file either on upgrade. > > This might be true. Still, since upstream udev removed the workaround > to retry getting the renamed name (see the commit I mentioned > earlier), it is much more likely to fail now. Fwiw, we reverted that > commit in Debian/Ubuntu for that reason [1]. > > Not sure if other distros do the same. > openSUSE still carries variant of old rename code. > Regards, > Michael > > [1] > https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
2016-05-29 18:28 GMT+02:00 Lennart Poettering : > On Sat, 28.05.16 21:38, Martin Pitt (martin.p...@ubuntu.com) wrote: > >> Chris Friesen [2016-05-27 9:14 -0600]: >> > The reason why I'm poking at this is that the old scheme worked "good >> > enough" for us for several years. Now of course the new scheme is better, >> > but it breaks backwards compatibility. This makes it difficult to >> > automatically upgrade an existing system to an OS using the new scheme >> > since >> > all the names would change. (And we've got the old interfaces stored in >> > databases and such in our management software.) >> >> FTR, Debian/Ubuntu do not use the new schema on upgrades for existing >> interfaces, just for new installs, for precisely this reason. >> Specifically, if you already have an existing >> /etc/udev/rules.d/70-persistent-net.rules, this will still be present >> (and trump ifnames). But we also disable it for VM upgrades where the >> previous persistent-net-generator was blacklisted. > > I am pretty sure most other distros won't remove the persistend rules > file either on upgrade. This might be true. Still, since upstream udev removed the workaround to retry getting the renamed name (see the commit I mentioned earlier), it is much more likely to fail now. Fwiw, we reverted that commit in Debian/Ubuntu for that reason [1]. Not sure if other distros do the same. Regards, Michael [1] https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Sat, 28.05.16 21:38, Martin Pitt (martin.p...@ubuntu.com) wrote: > Chris Friesen [2016-05-27 9:14 -0600]: > > The reason why I'm poking at this is that the old scheme worked "good > > enough" for us for several years. Now of course the new scheme is better, > > but it breaks backwards compatibility. This makes it difficult to > > automatically upgrade an existing system to an OS using the new scheme since > > all the names would change. (And we've got the old interfaces stored in > > databases and such in our management software.) > > FTR, Debian/Ubuntu do not use the new schema on upgrades for existing > interfaces, just for new installs, for precisely this reason. > Specifically, if you already have an existing > /etc/udev/rules.d/70-persistent-net.rules, this will still be present > (and trump ifnames). But we also disable it for VM upgrades where the > previous persistent-net-generator was blacklisted. I am pretty sure most other distros won't remove the persistend rules file either on upgrade. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Chris Friesen [2016-05-27 9:14 -0600]: > The reason why I'm poking at this is that the old scheme worked "good > enough" for us for several years. Now of course the new scheme is better, > but it breaks backwards compatibility. This makes it difficult to > automatically upgrade an existing system to an OS using the new scheme since > all the names would change. (And we've got the old interfaces stored in > databases and such in our management software.) FTR, Debian/Ubuntu do not use the new schema on upgrades for existing interfaces, just for new installs, for precisely this reason. Specifically, if you already have an existing /etc/udev/rules.d/70-persistent-net.rules, this will still be present (and trump ifnames). But we also disable it for VM upgrades where the previous persistent-net-generator was blacklisted. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Fri, 27.05.16 09:14, Chris Friesen (cbf...@mail.usask.ca) wrote: > >Well, udev just modprobes the driver. The driver then probes all > >devices and that happens in any order it likes. > > Looking at the kernel code, the probing order for pci NICs for a given > driver is pretty well deterministic. From what I can tell, the problems > happen when we modprobe another driver before the previous one is finished > walking the bus. When this happens you can get sequential device numbers > being assigned to one driver, then the other, then back to the > first. Yeah, for some specific setups the ethXY names might possibly be stable (for example, if you only have one device, or if you have very basic setups with only PCI, no USB, and all on the same bus, and so on...). If that used to be stable and isn't now this is probably more caused by kernel changes in the probing logic, not so much userspace changes afaics. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Fri, May 27, 2016 at 09:14:51AM -0600, Chris Friesen wrote: > On 05/27/2016 08:36 AM, Lennart Poettering wrote: > > On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote: > > > > > So I've been playing with this a bit, but I've run into another snag. It > > > seems that on initial boot even with "net.ifnames=0" the ethernet > > > interface > > > ordering isn't consistent. > > > > > > This means that two systems with identical hardware can end up mapping > > > "eth1000" to different physical slots. This makes it very difficult to > > > set > > > up multiple machines. > > > > Yupp, thta's what we have been saying all along: enumerating and > > probing devices is not stable, that's why the predictable interface > > names have been introduced after all, so that the same name refers to > > the same device all the time. > > > > > I assume this is due to parallel network device initialization from > > > udev? > > > > Well, udev just modprobes the driver. The driver then probes all > > devices and that happens in any order it likes. > > Looking at the kernel code, the probing order for pci NICs for a given > driver is pretty well deterministic. That is, if your BIOS doesn't decide to renumber the devices between boots. And yes, this can, and will, happen at times. Usually if you add/remove a device, or update the BIOS, but we have reports of machines that the BIOS reorders things when it feels like, and I had one that would do it every 2nd _or_ 3rd boot. So again, you are playing with fire here, and will get burned when you least expect it, good luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
2016-05-27 17:51 GMT+02:00 Chris Friesen : > The issue is not that the renaming fails (I actually modified the kernel to > start at eth1000 so there is no possibility of collision). > > The problem is that the kernel-assigned "ethX" names are not deterministic. > If I take two identical systems and boot the same OS on both, I can get > different "ethX" ordering due to the fact that multiple drivers are > modprobed in parallel and they race against each other to obtain the next > eth device number. Ok, then you don't actually use the old 75-persistent-net-generator.rules based mechanism that udev provided but you simply use the names the kernel gives you. When I read your topic "support for assigning ethX names", that sounded like you meant the ethX renaming that was (previously) done in udev. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/27/2016 09:43 AM, Michael Biebl wrote: 2016-05-27 17:14 GMT+02:00 Chris Friesen : And the annoying thing is that if I turn off the new naming scheme there seems to be less determinism than there used to be. I assume this is due to the effort to extract more parallelism at boot, but it's causing me grief. The old network interface naming scheme (which was bound to MAC addresses) used the same name space as the kernel. This was/is inherently racy. To make it more likely to succeed, udev tried the renaming several times. This hack was removed in upstream udev [1]. So this mean if you now use the old scheme it's much more likely that it fails. The issue is not that the renaming fails (I actually modified the kernel to start at eth1000 so there is no possibility of collision). The problem is that the kernel-assigned "ethX" names are not deterministic. If I take two identical systems and boot the same OS on both, I can get different "ethX" ordering due to the fact that multiple drivers are modprobed in parallel and they race against each other to obtain the next eth device number. All I'm looking for is a way to remove this raciness. I don't care if it takes longer to boot. I *think* that if I can serialize the modprobe then I should get deterministic numbering. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
2016-05-27 17:14 GMT+02:00 Chris Friesen : > And the annoying thing is that if I turn off the new naming scheme there > seems to be less determinism than there used to be. I assume this is due to > the effort to extract more parallelism at boot, but it's causing me grief. The old network interface naming scheme (which was bound to MAC addresses) used the same name space as the kernel. This was/is inherently racy. To make it more likely to succeed, udev tried the renaming several times. This hack was removed in upstream udev [1]. So this mean if you now use the old scheme it's much more likely that it fails. Michael [1] https://github.com/systemd/systemd/commit/97595710b77aa162ca5e20da57d0a1ed7355eaad -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/27/2016 08:36 AM, Lennart Poettering wrote: On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote: So I've been playing with this a bit, but I've run into another snag. It seems that on initial boot even with "net.ifnames=0" the ethernet interface ordering isn't consistent. This means that two systems with identical hardware can end up mapping "eth1000" to different physical slots. This makes it very difficult to set up multiple machines. Yupp, thta's what we have been saying all along: enumerating and probing devices is not stable, that's why the predictable interface names have been introduced after all, so that the same name refers to the same device all the time. I assume this is due to parallel network device initialization from udev? Well, udev just modprobes the driver. The driver then probes all devices and that happens in any order it likes. Looking at the kernel code, the probing order for pci NICs for a given driver is pretty well deterministic. From what I can tell, the problems happen when we modprobe another driver before the previous one is finished walking the bus. When this happens you can get sequential device numbers being assigned to one driver, then the other, then back to the first. Is there a way to serialize this at the cost of slower system initialization? I don't really care what the ordering is, as long as it is consistent on identical hardware. (Yes, I realize that the ideal would be to use the newer position-based naming, but that would mean a whole lot more work at this point.) Well, the old scheme is borked, that's why we fixed it. You don't like the fix, but want it fixed anyway. Not sure what else we can suggest... The reason why I'm poking at this is that the old scheme worked "good enough" for us for several years. Now of course the new scheme is better, but it breaks backwards compatibility. This makes it difficult to automatically upgrade an existing system to an OS using the new scheme since all the names would change. (And we've got the old interfaces stored in databases and such in our management software.) And the annoying thing is that if I turn off the new naming scheme there seems to be less determinism than there used to be. I assume this is due to the effort to extract more parallelism at boot, but it's causing me grief. Anyways, I think I understand enough about what's going on to try and figure out a workaround until we can move to the new naming scheme. Thanks for the help, Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote: > So I've been playing with this a bit, but I've run into another snag. It > seems that on initial boot even with "net.ifnames=0" the ethernet interface > ordering isn't consistent. > > This means that two systems with identical hardware can end up mapping > "eth1000" to different physical slots. This makes it very difficult to set > up multiple machines. Yupp, thta's what we have been saying all along: enumerating and probing devices is not stable, that's why the predictable interface names have been introduced after all, so that the same name refers to the same device all the time. > I assume this is due to parallel network device initialization from > udev? Well, udev just modprobes the driver. The driver then probes all devices and that happens in any order it likes. > Is there a way to serialize this at the cost of slower system > initialization? I don't really care what the ordering is, as long as it is > consistent on identical hardware. > > (Yes, I realize that the ideal would be to use the newer position-based > naming, but that would mean a whole lot more work at this point.) Well, the old scheme is borked, that's why we fixed it. You don't like the fix, but want it fixed anyway. Not sure what else we can suggest... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Am 26.05.2016 um 20:28 schrieb Chris Friesen: So I've been playing with this a bit, but I've run into another snag. It seems that on initial boot even with "net.ifnames=0" the ethernet interface ordering isn't consistent. This means that two systems with identical hardware can end up mapping "eth1000" to different physical slots. This makes it very difficult to set up multiple machines what else did you expect when you disable what should prevent exactly that? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/26/2016 01:59 PM, Greg KH wrote: On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote: The thing that makes this all confusing/annoying is that when I was using a homebrew distro with a 3.10 kernel and sysV init the interface ordering was completely repeatable on identical hardware, but when I went to CentOS 7 with a 3.10 kernel and systemd the interface ordering became variable. Try making your own kernel with the needed drivers built-in and the ordering should start to get semi-predictable, but then it might not be because the kernel, and userspace, and your hardware, do not make any guarantees of this AT ALL. So you really are on your own here, good luck! Yeah, I get the picture. I traced the kernel code and like even with drivers as builtin we have the possibility of ordering issues when pci_call_probe calls local_pci_probe via a workqueue. We may have just gotten lucky previously. I want to move to position-based naming eventually, it was just not really a good time. Thanks for the comments, everyone. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote: > On 05/26/2016 12:41 PM, Martin Pitt wrote: > > Chris Friesen [2016-05-26 12:28 -0600]: > > > So I've been playing with this a bit, but I've run into another snag. It > > > seems that on initial boot even with "net.ifnames=0" the ethernet > > > interface > > > ordering isn't consistent. > > > > "even with" → "because of" :-) > > > > However, the ordering isn't really influenced by udev/systemd/ifnames, > > that's entirely dependent on the hardware and kernel drivers. > > > > > I assume this is due to parallel network device initialization from udev? > > > > udev (or userspace in general) has no business in detecting physical > > network devices, that's exclusively the kernel. > > I'm looking at the kernel code now. It appears that the ordering of the > network device discovery is influenced by the order in which the kernel > modules are loaded as well as the physical layout of the system. I saw some > online notes that said that udev had a hand in loading the modules, and that > it might load multiple modules in parallel--is that correct? > > The thing that makes this all confusing/annoying is that when I was using a > homebrew distro with a 3.10 kernel and sysV init the interface ordering was > completely repeatable on identical hardware, but when I went to CentOS 7 > with a 3.10 kernel and systemd the interface ordering became variable. Try making your own kernel with the needed drivers built-in and the ordering should start to get semi-predictable, but then it might not be because the kernel, and userspace, and your hardware, do not make any guarantees of this AT ALL. So you really are on your own here, good luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/26/2016 12:41 PM, Martin Pitt wrote: Chris Friesen [2016-05-26 12:28 -0600]: So I've been playing with this a bit, but I've run into another snag. It seems that on initial boot even with "net.ifnames=0" the ethernet interface ordering isn't consistent. "even with" → "because of" :-) However, the ordering isn't really influenced by udev/systemd/ifnames, that's entirely dependent on the hardware and kernel drivers. I assume this is due to parallel network device initialization from udev? udev (or userspace in general) has no business in detecting physical network devices, that's exclusively the kernel. I'm looking at the kernel code now. It appears that the ordering of the network device discovery is influenced by the order in which the kernel modules are loaded as well as the physical layout of the system. I saw some online notes that said that udev had a hand in loading the modules, and that it might load multiple modules in parallel--is that correct? The thing that makes this all confusing/annoying is that when I was using a homebrew distro with a 3.10 kernel and sysV init the interface ordering was completely repeatable on identical hardware, but when I went to CentOS 7 with a 3.10 kernel and systemd the interface ordering became variable. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Chris Friesen [2016-05-26 12:28 -0600]: > So I've been playing with this a bit, but I've run into another snag. It > seems that on initial boot even with "net.ifnames=0" the ethernet interface > ordering isn't consistent. "even with" → "because of" :-) However, the ordering isn't really influenced by udev/systemd/ifnames, that's entirely dependent on the hardware and kernel drivers. > I assume this is due to parallel network device initialization from udev? udev (or userspace in general) has no business in detecting physical network devices, that's exclusively the kernel. > Is there a way to serialize this at the cost of slower system > initialization? I don't really care what the ordering is, as long as it is > consistent on identical hardware. I'm not aware of such a method. You can of course hack the kernel to do anything.. This is why we have needed to come up with ways to rename interfaces in userspace. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/13/2016 08:54 AM, Chris Friesen wrote: On 05/13/2016 01:23 AM, Lennart Poettering wrote: On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote: I booted the kernel with "net.ifnames=0", which worked to turn off the location-based naming. I then created a set of files, one per eth device that match based on MAC: [root@compute-0 root]# cat /etc/systemd/network/10-eth 10-eth0.link 10-eth1.link 10-eth2.link 10-eth3.link Here's an example of one of the files: [root@compute-0 wrsroot]# cat /etc/systemd/network/10-eth0.link [Match] MACAddress=08:00:27:f1:36:11 [Link] Name=eth0 "eth*" is the kernel's namespace for ethernet devices. Stepping into that namespace, and racing against the kernel's name assignment logic is something you can only lose at. Pick any other name, but assigning names in the kernel's own namespace, that's not really supported. Okay, fair enough. Since I still need to do this for now, I changed the kernel to start naming at eth1000 so I could then rename it back down to the desired range. (resending now that I'm on the list again, sorry for the dupe Lennart) So I've been playing with this a bit, but I've run into another snag. It seems that on initial boot even with "net.ifnames=0" the ethernet interface ordering isn't consistent. This means that two systems with identical hardware can end up mapping "eth1000" to different physical slots. This makes it very difficult to set up multiple machines. I assume this is due to parallel network device initialization from udev? Is there a way to serialize this at the cost of slower system initialization? I don't really care what the ordering is, as long as it is consistent on identical hardware. (Yes, I realize that the ideal would be to use the newer position-based naming, but that would mean a whole lot more work at this point.) Thanks, Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/13/2016 01:23 AM, Lennart Poettering wrote: On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote: I booted the kernel with "net.ifnames=0", which worked to turn off the location-based naming. I then created a set of files, one per eth device that match based on MAC: [root@compute-0 root]# cat /etc/systemd/network/10-eth 10-eth0.link 10-eth1.link 10-eth2.link 10-eth3.link Here's an example of one of the files: [root@compute-0 wrsroot]# cat /etc/systemd/network/10-eth0.link [Match] MACAddress=08:00:27:f1:36:11 [Link] Name=eth0 "eth*" is the kernel's namespace for ethernet devices. Stepping into that namespace, and racing against the kernel's name assignment logic is something you can only lose at. Pick any other name, but assigning names in the kernel's own namespace, that's not really supported. Okay, fair enough. Since I still need to do this for now, I changed the kernel to start naming at eth1000 so I could then rename it back down to the desired range. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote: > I booted the kernel with "net.ifnames=0", which worked to turn off the > location-based naming. > > I then created a set of files, one per eth device that match based on MAC: > > [root@compute-0 root]# cat /etc/systemd/network/10-eth > 10-eth0.link 10-eth1.link 10-eth2.link 10-eth3.link > > > Here's an example of one of the files: > > [root@compute-0 wrsroot]# cat /etc/systemd/network/10-eth0.link > [Match] > MACAddress=08:00:27:f1:36:11 > > [Link] > Name=eth0 "eth*" is the kernel's namespace for ethernet devices. Stepping into that namespace, and racing against the kernel's name assignment logic is something you can only lose at. Pick any other name, but assigning names in the kernel's own namespace, that's not really supported. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
12.05.2016 21:34, Chris Friesen пишет: > > So I guess the question is, how do I rename a device to a name that > already exists? (Like supposing I want to swap the names of eth0 and > eth1.) > You cannot (using current udev). This is exactly the code that was removed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Am 12.05.2016 um 21:46 schrieb Chris Friesen: So...anyone have any ideas why this isn't working? Is it because I'm trying to use the "eth" namespace which could possibly collide with the kernel naming? likely yes the config below has a reason while using network.service and classical ifcfg-files [root@srv-rhsoft:~]$ ifconfig | grep flags br-guest: flags=67 mtu 1500 br-lan: flags=4675 mtu 1500 br-wan: flags=67 mtu 1500 lan-guest: flags=4099 mtu 1500 lan-phone: flags=67 mtu 1500 lan-spare: flags=4099 mtu 1500 lan-tv: flags=4163 mtu 1500 lo: flags=73 mtu 65536 vmnet1: flags=67 mtu 1500 vmnet8: flags=4163 mtu 1500 vpn-client: flags=4163 mtu 1472 vpn-server: flags=4305 mtu 1500 wan: flags=67 mtu 1500 wlan0: flags=4163 mtu 1500 wlan1: flags=67 mtu 1500 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/12/2016 01:27 PM, Chris Friesen wrote: On 05/12/2016 12:50 PM, James Hogarth wrote: > > On 12 May 2016 18:28, "Chris Friesen" mailto:cbf...@mail.usask.ca>> wrote: > > > > Hi, > > > > Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? > > > > Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) > > > > The back story is that we've got a lot of scripts/tools that currently assume the "ethX" naming, and while we will eventually sort it out we really don't want to do it right now. The previous method of assigning "ethX" names was working well for our use-case (though I realize it had issues more generally). > > For future reference when dealing with EL systems it's best to check the Red Hat documentation in the first instance: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html Thanks, that shows some promise. I had actually read some portions of that document, but I should probably have read all of section 8 first. Looks like I spoke too soon. I tried adding HWADDR= entries to our /etc/sysconfig/network-scripts/ifcfg-ethX files, and while it mostly works I just got this on rebooting: [root@compute-0 wrsroot]# ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth2: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 08:00:27:9f:b9:47 brd ff:ff:ff:ff:ff:ff 3: eth3: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 08:00:27:9d:14:c4 brd ff:ff:ff:ff:ff:ff 4: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 08:00:27:f1:36:11 brd ff:ff:ff:ff:ff:ff 5: enp0s8: mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 08:00:27:dd:42:ae brd ff:ff:ff:ff:ff:ff Note the position-based naming for device 5. And here's the relevent file: [root@compute-0 wrsroot]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 NAME=eth1 HWADDR=08:00:27:dd:42:ae BOOTPROTO=dhcp ONBOOT=yes So...anyone have any ideas why this isn't working? Is it because I'm trying to use the "eth" namespace which could possibly collide with the kernel naming? Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/12/2016 12:50 PM, James Hogarth wrote: > > On 12 May 2016 18:28, "Chris Friesen" mailto:cbf...@mail.usask.ca>> wrote: > > > > Hi, > > > > Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? > > > > Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) > > > > The back story is that we've got a lot of scripts/tools that currently assume the "ethX" naming, and while we will eventually sort it out we really don't want to do it right now. The previous method of assigning "ethX" names was working well for our use-case (though I realize it had issues more generally). > > For future reference when dealing with EL systems it's best to check the Red Hat documentation in the first instance: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html Thanks, that shows some promise. I had actually read some portions of that document, but I should probably have read all of section 8 first. Thanks for the help. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
> > On 12 May 2016 18:28, "Chris Friesen" wrote: > > > > Hi, > > > > Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? > > > > Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) > > > > The back story is that we've got a lot of scripts/tools that currently assume the "ethX" naming, and while we will eventually sort it out we really don't want to do it right now. The previous method of assigning "ethX" names was working well for our use-case (though I realize it had issues more generally). > > For future reference when dealing with EL systems it's best to check the Red Hat documentation in the first instance: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Am 12.05.2016 um 20:34 schrieb Chris Friesen: So I guess the question is, how do I rename a device to a name that already exists? (Like supposing I want to swap the names of eth0 and eth1.) you don't - if it works - be lucky - i am on some machines but you can't do that relieable on many machines hence name the stuff to ethernet0, ethernet1.. to avoid collisions / races with kernel naming signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Am 12.05.2016 um 19:52 schrieb Chris Friesen: On 05/12/2016 11:35 AM, Reindl Harald wrote: Am 12.05.2016 um 19:20 schrieb Chris Friesen: Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) it was not removed - boot with "net.ifnames=0 biosdevname=0" just use network.service on RHEL7 as all the time before and enter the MAC in the ifcfg-file as all the time before On https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ it says: "For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems.As a result support for this has been removed from systemd/udev a while back." If that is not accurate then maybe it should be updated since when do you need udev for that? you don't and you did not that said from somebody which switched the way below eth0 and eth1 on a CentOS7 mini-PC acting as router months ago [root@mail-gw:~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:50:56:bd:35:50 ONBOOT=yes ARPCHECK=no BOOTPROTO=static TYPE=Ethernet MODE=Managed IPADDR=**.**.**.** NM_CONTROLLED=no IPV6INIT=no NETMASK=255.255.255.0 GATEWAY=**.**.**.** signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/12/2016 11:36 AM, Lennart Poettering wrote: On Thu, 12.05.16 11:20, Chris Friesen (cbf...@mail.usask.ca) wrote: Hi, Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) The back story is that we've got a lot of scripts/tools that currently assume the "ethX" naming, and while we will eventually sort it out we really don't want to do it right now. The previous method of assigning "ethX" names was working well for our use-case (though I realize it had issues more generally). https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ See the end of that page. I booted the kernel with "net.ifnames=0", which worked to turn off the location-based naming. I then created a set of files, one per eth device that match based on MAC: [root@compute-0 root]# cat /etc/systemd/network/10-eth 10-eth0.link 10-eth1.link 10-eth2.link 10-eth3.link Here's an example of one of the files: [root@compute-0 wrsroot]# cat /etc/systemd/network/10-eth0.link [Match] MACAddress=08:00:27:f1:36:11 [Link] Name=eth0 When I booted up, however, the custom naming was not applied. Eth0 was a different device: [root@compute-0 wrsroot]# ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 08:00:27:9f:b9:47 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 08:00:27:9d:14:c4 brd ff:ff:ff:ff:ff:ff 4: eth2: mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 08:00:27:f1:36:11 brd ff:ff:ff:ff:ff:ff 5: eth3: mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 08:00:27:dd:42:ae brd ff:ff:ff:ff:ff:ff If I use some other set of names (vethX, for example) then the renaming works fine. I tried removing "net.ifnames=0" from the kernel boot args, and got devices named like "enp0s3" even though I had /etc/systemd/network/10-ethX.link files for each device. This seems to contradict the information in https://www.freedesktop.org/software/systemd/man/systemd.link.html which says that the "Name=" should take effect if NamePolicy= is missing. So I guess the question is, how do I rename a device to a name that already exists? (Like supposing I want to swap the names of eth0 and eth1.) Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Thu, 12.05.16 11:52, Chris Friesen (cbf...@mail.usask.ca) wrote: > On 05/12/2016 11:35 AM, Reindl Harald wrote: > > > > > >Am 12.05.2016 um 19:20 schrieb Chris Friesen: > >>Could someone point me to the commit that removed support for assigning > >>"ethX" names based on MAC addresses? > >> > >>Alternately, can someone suggest a way to get equivalent behaviour (the > >>ability to set "ethX" names based on MAC address) using the current > >>infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of > >>patches.) > > > >it was not removed - boot with "net.ifnames=0 biosdevname=0" > > > >just use network.service on RHEL7 as all the time before and enter the MAC in > >the ifcfg-file as all the time before > > On > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > it says: > > "For a longer time udev shipped support for assigning permanent "ethX" names > to certain interfaces based on their MAC addresses. This turned out to have > a multitude of problems.As a result support for this has been removed > from systemd/udev a while back." > > If that is not accurate then maybe it should be updated. It is accurate. What has been removed is the support for assigning *permanent* names in the eth* namespace. If you don't care about that then just use net.ifnames=0 or so, and you'll get your eth* names back, but they will be assigned in a non-predictable way, and might change at every boot (unless of course you only have a single ethernet device in your systems). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On 05/12/2016 11:35 AM, Reindl Harald wrote: Am 12.05.2016 um 19:20 schrieb Chris Friesen: Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) it was not removed - boot with "net.ifnames=0 biosdevname=0" just use network.service on RHEL7 as all the time before and enter the MAC in the ifcfg-file as all the time before On https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ it says: "For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems.As a result support for this has been removed from systemd/udev a while back." If that is not accurate then maybe it should be updated. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
On Thu, 12.05.16 11:20, Chris Friesen (cbf...@mail.usask.ca) wrote: > Hi, > > Could someone point me to the commit that removed support for assigning > "ethX" names based on MAC addresses? > > Alternately, can someone suggest a way to get equivalent behaviour (the > ability to set "ethX" names based on MAC address) using the current > infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of > patches.) > > The back story is that we've got a lot of scripts/tools that currently > assume the "ethX" naming, and while we will eventually sort it out we really > don't want to do it right now. The previous method of assigning "ethX" > names was working well for our use-case (though I realize it had issues more > generally). https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ See the end of that page. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
Am 12.05.2016 um 19:20 schrieb Chris Friesen: Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) it was not removed - boot with "net.ifnames=0 biosdevname=0" just use network.service on RHEL7 as all the time before and enter the MAC in the ifcfg-file as all the time before signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] when/where was support for assigning "ethX" names removed?
Hi, Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) The back story is that we've got a lot of scripts/tools that currently assume the "ethX" naming, and while we will eventually sort it out we really don't want to do it right now. The previous method of assigning "ethX" names was working well for our use-case (though I realize it had issues more generally). Thanks, Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
