1 |
>>>> I'm having a problem starting the USB network interfaces properly on |
2 |
>>>> one of my systems. I brought the problem to the udev list and they're |
3 |
>>>> indicating that it's a Gentoo problem: |
4 |
>>>> |
5 |
>>>> https://www.mail-archive.com/systemd-devel@×××××××××××××××××.org/msg18840.html |
6 |
>>>> |
7 |
>>>> Should I file a bug? |
8 |
>>>> |
9 |
>>>> - Grant |
10 |
>>>> |
11 |
>>> Like pointed out in the upstream thread, it's either wrongly built |
12 |
>>> net-misc/dhcpcd (should be with USE="udev") |
13 |
>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's |
14 |
>>> /etc/init.d/net.lo depend() { } section -- |
15 |
>>> it's possible it's missing dependency that forces /etc/init.d/udev start |
16 |
>>> first, specially if OpenRC is using parallel |
17 |
>>> startup |
18 |
>>> |
19 |
>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags |
20 |
>>> OR bug in dependencies of netifrc's net.lo script |
21 |
>> |
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 |
> |
31 |
> Try adding 'after udev' to net.lo's depend() { } section and see if that |
32 |
> helps, if it does, file a bug |
33 |
> saying so. |
34 |
|
35 |
|
36 |
I added it like this and rebooted: |
37 |
|
38 |
depend() |
39 |
{ |
40 |
after udev |
41 |
|
42 |
but the result was the same. I also have udev and udev-mount in the |
43 |
sysinit runlevel. |
44 |
|
45 |
|
46 |
> It was more of an educated guess than 100% accurate knowledge. I can't |
47 |
> think of an another |
48 |
> way to force netifrc to behave, since it's not coded in C, and it can't |
49 |
> link to libudev, so... |
50 |
> |
51 |
> However since you say *both*, even the one with dhcpcd fail to start, |
52 |
> before filing that bug, |
53 |
> see if disabling netifrc hotplugging works: |
54 |
> |
55 |
> # ln -s /dev/null /etc/udev/rules.d/90-network.rules |
56 |
|
57 |
|
58 |
Will that disable interface renaming or hotplugging? The system with |
59 |
the issue is remote and if the interfaces aren't renamed or if |
60 |
hotplugging doesn't happen then I won't be able to access the system |
61 |
for up to 24 hours. That's fine and I'm happy to test stuff like this |
62 |
anyway but I don't think this particular test will be informative |
63 |
because: |
64 |
|
65 |
1. I'm 99% sure everything would work fine with the interfaces at eth0 |
66 |
and eth1 since the issue seems to be that udev is renaming the |
67 |
interfaces too late in the boot process, but I like having |
68 |
location-based names. |
69 |
|
70 |
2. I can enable and disable hotplug in rc.conf and the interfaces |
71 |
don't come up with it disabled. |
72 |
|
73 |
- Grant |