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