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

[Grant]

>>>>>> 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/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