>>>>>>>> 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. >> > > Does your kernel have timing info enabled? If so, it would be > interesting to look at your dmesg output. > > My guess is that your kernel is taking a really long time (several > seconds) to initialize your network cards.
I have this: # dmesg | grep enp [ 4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1 [ 4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2 [ 6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1 [ 7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1 # That doesn't tell us when the network initscripts tried and failed to start but this from /var/log/messages/everything/current shows the first time in the boot sequence that a dependent service failed to start because of the networking failure so it should be before this: [kernel] [ 0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12 [/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1 would not start [kernel] [ 0.792081] rtc_cmos 00:04: alarms up to one month, y3k, 242 bytes nvram, hpet irqs - Grant
