| 1 |
On Wed, May 14, 2014 at 7:59 PM, Grant <emailgrant@×××××.com> wrote: |
| 2 |
>>>>>>> I'm having a problem starting the USB network interfaces properly on |
| 3 |
>>>>>>> one of my systems. I brought the problem to the udev list and they're |
| 4 |
>>>>>>> indicating that it's a Gentoo problem: |
| 5 |
>>>>>>> |
| 6 |
>>>>>>> https://www.mail-archive.com/systemd-devel@×××××××××××××××××.org/msg18840.html |
| 7 |
>>>>>>> |
| 8 |
>>>>>>> Should I file a bug? |
| 9 |
>>>>>>> |
| 10 |
>>>>>>> - Grant |
| 11 |
>>>>>>> |
| 12 |
>>>>>> Like pointed out in the upstream thread, it's either wrongly built |
| 13 |
>>>>>> net-misc/dhcpcd (should be with USE="udev") |
| 14 |
>>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's |
| 15 |
>>>>>> /etc/init.d/net.lo depend() { } section -- |
| 16 |
>>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start |
| 17 |
>>>>>> first, specially if OpenRC is using parallel |
| 18 |
>>>>>> startup |
| 19 |
>>>>>> |
| 20 |
>>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags |
| 21 |
>>>>>> OR bug in dependencies of netifrc's net.lo script |
| 22 |
>>>>> I'm starting two interfaces, one that uses dhcpcd and one that does |
| 23 |
>>>>> not. Both fail to start in the default runlevel until they are |
| 24 |
>>>>> hotplugged later. I do have dhcpcd built with USE=udev. The string |
| 25 |
>>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the |
| 26 |
>>>>> problem? Please confirm that I should file a Gentoo bug for this. |
| 27 |
>>>>> |
| 28 |
>>>>> - Grant |
| 29 |
>>>>> |
| 30 |
>>>> Try adding 'after udev' to net.lo's depend() { } section and see if that |
| 31 |
>>>> helps, if it does, file a bug |
| 32 |
>>>> saying so. |
| 33 |
>>> |
| 34 |
>>> I added it like this and rebooted: |
| 35 |
>>> |
| 36 |
>>> depend() |
| 37 |
>>> { |
| 38 |
>>> after udev |
| 39 |
>>> |
| 40 |
>>> but the result was the same. I also have udev and udev-mount in the |
| 41 |
>>> sysinit runlevel. |
| 42 |
>>> |
| 43 |
>>> |
| 44 |
>>>> It was more of an educated guess than 100% accurate knowledge. I can't |
| 45 |
>>>> think of an another |
| 46 |
>>>> way to force netifrc to behave, since it's not coded in C, and it can't |
| 47 |
>>>> link to libudev, so... |
| 48 |
>>>> |
| 49 |
>>>> However since you say *both*, even the one with dhcpcd fail to start, |
| 50 |
>>>> before filing that bug, |
| 51 |
>>>> see if disabling netifrc hotplugging works: |
| 52 |
>>>> |
| 53 |
>>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules |
| 54 |
>>> |
| 55 |
>>> Will that disable interface renaming or hotplugging? The system with |
| 56 |
>>> the issue is remote and if the interfaces aren't renamed or if |
| 57 |
>>> hotplugging doesn't happen then I won't be able to access the system |
| 58 |
>>> for up to 24 hours. That's fine and I'm happy to test stuff like this |
| 59 |
>>> anyway but I don't think this particular test will be informative |
| 60 |
>>> because: |
| 61 |
>> |
| 62 |
>> It will disable the hotplugging, it means you *must* have the net.* |
| 63 |
>> stuff added |
| 64 |
>> to the default to runlevel yourself, like eg. |
| 65 |
>> |
| 66 |
>> # rc-update add net.foooooobar default |
| 67 |
> |
| 68 |
> |
| 69 |
> They're in the default runlevel: |
| 70 |
> |
| 71 |
> # rc-update|grep net.enp |
| 72 |
> net.enp0s20u2u1 | default |
| 73 |
> net.enp0s20u2u2 | default |
| 74 |
> |
| 75 |
> I can disable hotplugging with rc_hotplug in rc.conf. Hotplugging is |
| 76 |
> actually disabled by default there and my network interfaces won't |
| 77 |
> start automatically that way. |
| 78 |
> |
| 79 |
|
| 80 |
Does your kernel have timing info enabled? If so, it would be |
| 81 |
interesting to look at your dmesg output. |
| 82 |
|
| 83 |
My guess is that your kernel is taking a really long time (several |
| 84 |
seconds) to initialize your network cards. |
Archives