1 |
On 15/05/14 02:59, 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 |
>>> I added it like this and rebooted: |
34 |
>>> |
35 |
>>> depend() |
36 |
>>> { |
37 |
>>> after udev |
38 |
>>> |
39 |
>>> but the result was the same. I also have udev and udev-mount in the |
40 |
>>> sysinit runlevel. |
41 |
>>> |
42 |
>>> |
43 |
>>>> It was more of an educated guess than 100% accurate knowledge. I can't |
44 |
>>>> think of an another |
45 |
>>>> way to force netifrc to behave, since it's not coded in C, and it can't |
46 |
>>>> link to libudev, so... |
47 |
>>>> |
48 |
>>>> However since you say *both*, even the one with dhcpcd fail to start, |
49 |
>>>> before filing that bug, |
50 |
>>>> see if disabling netifrc hotplugging works: |
51 |
>>>> |
52 |
>>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules |
53 |
>>> Will that disable interface renaming or hotplugging? The system with |
54 |
>>> the issue is remote and if the interfaces aren't renamed or if |
55 |
>>> hotplugging doesn't happen then I won't be able to access the system |
56 |
>>> for up to 24 hours. That's fine and I'm happy to test stuff like this |
57 |
>>> anyway but I don't think this particular test will be informative |
58 |
>>> because: |
59 |
>> It will disable the hotplugging, it means you *must* have the net.* |
60 |
>> stuff added |
61 |
>> to the default to runlevel yourself, like eg. |
62 |
>> |
63 |
>> # rc-update add net.foooooobar default |
64 |
> |
65 |
> They're in the default runlevel: |
66 |
> |
67 |
> # rc-update|grep net.enp |
68 |
> net.enp0s20u2u1 | default |
69 |
> net.enp0s20u2u2 | default |
70 |
> |
71 |
> I can disable hotplugging with rc_hotplug in rc.conf. Hotplugging is |
72 |
> actually disabled by default there and my network interfaces won't |
73 |
> start automatically that way. |
74 |
> |
75 |
> |
76 |
|
77 |
I'm not 100% sure the rc_hotplug will also disable the 90-network.rules |
78 |
triggered |
79 |
interface hotplugging |
80 |
Don't count on that |
81 |
|
82 |
- Samuli |