On 15/05/14 02:59, Grant wrote: >>>>>>> I'm having a problem starting the USB network interfaces properly on >>>>>>> one of my systems. I brought the problem to the udev list and they're >>>>>>> indicating that it's a Gentoo problem: >>>>>>> >>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html >>>>>>> >>>>>>> Should I file a bug? >>>>>>> >>>>>>> - Grant >>>>>>> >>>>>> Like pointed out in the upstream thread, it's either wrongly built >>>>>> net-misc/dhcpcd (should be with USE="udev") >>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's >>>>>> /etc/init.d/net.lo depend() { } section -- >>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start >>>>>> first, specially if OpenRC is using parallel >>>>>> startup >>>>>> >>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags >>>>>> OR bug in dependencies of netifrc's net.lo script >>>>> I'm starting two interfaces, one that uses dhcpcd and one that does >>>>> not. Both fail to start in the default runlevel until they are >>>>> hotplugged later. I do have dhcpcd built with USE=udev. The string >>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the >>>>> problem? Please confirm that I should file a Gentoo bug for this. >>>>> >>>>> - Grant >>>>> >>>> Try adding 'after udev' to net.lo's depend() { } section and see if that >>>> helps, if it does, file a bug >>>> saying so. >>> I added it like this and rebooted: >>> >>> depend() >>> { >>> after udev >>> >>> but the result was the same. I also have udev and udev-mount in the >>> sysinit runlevel. >>> >>> >>>> It was more of an educated guess than 100% accurate knowledge. I can't >>>> think of an another >>>> way to force netifrc to behave, since it's not coded in C, and it can't >>>> link to libudev, so... >>>> >>>> However since you say *both*, even the one with dhcpcd fail to start, >>>> before filing that bug, >>>> see if disabling netifrc hotplugging works: >>>> >>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules >>> Will that disable interface renaming or hotplugging? The system with >>> the issue is remote and if the interfaces aren't renamed or if >>> hotplugging doesn't happen then I won't be able to access the system >>> for up to 24 hours. That's fine and I'm happy to test stuff like this >>> anyway but I don't think this particular test will be informative >>> because: >> It will disable the hotplugging, it means you *must* have the net.* >> stuff added >> to the default to runlevel yourself, like eg. >> >> # rc-update add net.foooooobar default > > They're in the default runlevel: > > # rc-update|grep net.enp > net.enp0s20u2u1 | default > net.enp0s20u2u2 | default > > I can disable hotplugging with rc_hotplug in rc.conf. Hotplugging is > actually disabled by default there and my network interfaces won't > start automatically that way. > >
I'm not 100% sure the rc_hotplug will also disable the 90-network.rules triggered interface hotplugging Don't count on that - Samuli
