>>>> 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:
1. I'm 99% sure everything would work fine with the interfaces at eth0
and eth1 since the issue seems to be that udev is renaming the
interfaces too late in the boot process, but I like having
location-based names.
2. I can enable and disable hotplug in rc.conf and the interfaces
don't come up with it disabled.
- Grant
