On Friday 16 May 2014 11:43:41 Samuli Suominen wrote: > 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/ms > >>>>>>> g18840.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's right. I was experimenting on a new install how to stop net.eth0 from coming up (it was stalling forever because there was no ethernet cable present). No matter what I tried with /etc/rc.conf, or eselect rc, I couldn't stop the darn thing starting up. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
