| 1 |
On 14/05/14 15:42, Grant 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 |
Archives