>>>>>> 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. - Grant