[arch-releng] [PATCH] [configs/releng] Only launch dhcpcd for ethernet interfaces
--- configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules index 970da69..eadc669 100644 --- a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules +++ b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules @@ -1 +1 @@ -ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service" +ACTION=="add", SUBSYSTEM=="net", NAME=="en*|eth*", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service" -- 1.8.5.2
Am 03.01.2014 19:33, schrieb Thomas Bächler:
--- configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules index 970da69..eadc669 100644 --- a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules +++ b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules @@ -1 +1 @@ -ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service" +ACTION=="add", SUBSYSTEM=="net", NAME=="en*|eth*", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
Are we sure this works as intended? I have seen wireless drivers naming the device eth0 and I guess the new udev naming also uses en* here. Or wasn#t your goal to exclude wireless here but virtual devices like tun/tap etc.? Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Am 03.01.2014 19:40, schrieb Pierre Schmitz:
Am 03.01.2014 19:33, schrieb Thomas Bächler:
--- configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules index 970da69..eadc669 100644 --- a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules +++ b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules @@ -1 +1 @@ -ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service" +ACTION=="add", SUBSYSTEM=="net", NAME=="en*|eth*", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
Are we sure this works as intended? I have seen wireless drivers naming the device eth0 and I guess the new udev naming also uses en* here.
This is legacy stuff in any case. All newer driver (i.e. mac80211 and newer hardmac drivers) don't use ethX anymore.
Or wasn#t your goal to exclude wireless here but virtual devices like tun/tap etc.?
Right now, dhcpcd is activated on wireless, tap, ppp and other stuff that usually doesn't make sense.
Am 03.01.2014 19:43, schrieb Thomas Bächler:
Am 03.01.2014 19:40, schrieb Pierre Schmitz:
Or wasn#t your goal to exclude wireless here but virtual devices like tun/tap etc.?
Right now, dhcpcd is activated on wireless, tap, ppp and other stuff that usually doesn't make sense.
In that case +1 from me; assuming this patch works as I did not test it. (but it looks good) -- Pierre Schmitz, https://pierre-schmitz.com
On Fri, Jan 3, 2014 at 7:33 PM, Thomas Bächler <thomas@archlinux.org> wrote:
--- configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules index 970da69..eadc669 100644 --- a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules +++ b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules @@ -1 +1 @@ -ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service" +ACTION=="add", SUBSYSTEM=="net", NAME=="en*|eth*", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
This seems like it is strictly an improvement, so +1 from me. I just added support to networkd for matching on ethernet devices [0], so if we switch to that in a few releases time we can replace this udev rule with a .network file: -->8------- [Match] Type=ethernet [Network] DHCP=yes -->8------- Note that this stuff is still subject to change, so feedback would be welcome. Cheers, Tom [0]: <http://lists.freedesktop.org/archives/systemd-devel/2014-January/015984.html>
On 01/03/2014 03:33 PM, Thomas Bächler wrote:
--- configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules index 970da69..eadc669 100644 --- a/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules +++ b/configs/releng/root-image/etc/udev/rules.d/81-dhcpcd.rules @@ -1 +1 @@ -ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service" +ACTION=="add", SUBSYSTEM=="net", NAME=="en*|eth*", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
Looks OK. Not tested, I will merge it and release a new archiso. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Hello. Don't know whether it's relevant, but the patch seems to stop dhcpcd from being launched automatically on paravirtualized virtio interfaces, at least on VirtualBox. Corresponding findings: installer media were booted as VirtualBox guest with any of the combinations version 12/2013 or 01/2014, i686 or x86_64, guest's network interface as virtualized hardware ("Intel PRO/1000 T Server") or paravirtualized ("virtio-net") and network mode either NAT or bridged. ISO 12/2013 always launched dhcpcd automatically on the virtual NIC. ISO 01/2014 launched dhcpcd automatically always if the interface was set to virtual hardware but never when it was set to virtio-net. Manually launching dhcpcd[@eth0].service on the virtio interface worked as expected and configured the interface as eth0. BTW so far dhcpcd was also started automatically whenever I booted the January ISO on hardware directly. Regards, Peter Mattern
Am 10.01.2014 20:20, schrieb Peter Mattern:
ISO 12/2013 always launched dhcpcd automatically on the virtual NIC. ISO 01/2014 launched dhcpcd automatically always if the interface was set to virtual hardware but never when it was set to virtio-net. Manually launching dhcpcd[@eth0].service on the virtio interface worked as expected and configured the interface as eth0.
I don't see why this would happen. since the udev rule matches on eth* as well as en*.
Am 11.01.2014 01:20, schrieb Thomas Bächler:
I don't see why this would happen. since the udev rule matches on eth* as well as en*. For exactly this reason I don't understand my findings either. That's why I posted on the list.
Nevertheless I meanwhile could reproduce the problem in a regular Arch Linux VM, too. Same thing. 81-dhcpcd.rules as included in ISO 12/2013 launches dhcpcd on both the paravirtualized virtio interface and the virtualized hardware while the one from ISO 01/2014 only does so on the latter. I also looked for evidence of an artifact in my system, but didn't find anything.
On Sat, Jan 11, 2014 at 11:11:41PM +0100, Peter Mattern wrote:
Am 11.01.2014 01:20, schrieb Thomas Bächler:
I don't see why this would happen. since the udev rule matches on eth* as well as en*. For exactly this reason I don't understand my findings either. That's why I posted on the list.
Nevertheless I meanwhile could reproduce the problem in a regular Arch Linux VM, too. Same thing. 81-dhcpcd.rules as included in ISO 12/2013 launches dhcpcd on both the paravirtualized virtio interface and the virtualized hardware while the one from ISO 01/2014 only does so on the latter.
I also looked for evidence of an artifact in my system, but didn't find anything.
NAME doesn't seem to work here. Using ENV{INTERFACE} does, though.
Am 11.01.2014 23:36, schrieb Dave Reisner:
On Sat, Jan 11, 2014 at 11:11:41PM +0100, Peter Mattern wrote:
Am 11.01.2014 01:20, schrieb Thomas Bächler:
I don't see why this would happen. since the udev rule matches on eth* as well as en*. For exactly this reason I don't understand my findings either. That's why I posted on the list.
Nevertheless I meanwhile could reproduce the problem in a regular Arch Linux VM, too. Same thing. 81-dhcpcd.rules as included in ISO 12/2013 launches dhcpcd on both the paravirtualized virtio interface and the virtualized hardware while the one from ISO 01/2014 only does so on the latter.
I also looked for evidence of an artifact in my system, but didn't find anything.
NAME doesn't seem to work here. Using ENV{INTERFACE} does, though.
Ugh, we don't have NAME set since we don't assign it. Stupid mistake.
participants (6)
-
Dave Reisner
-
Gerardo Exequiel Pozzi
-
Peter Mattern
-
Pierre Schmitz
-
Thomas Bächler
-
Tom Gundersen