Re: [gentoo-user] udev or Gentoo issue?

[Mick]

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@×××××××××××××××××.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