Gentoo Archives: gentoo-user

From: Grant <emailgrant@×××××.com>
To: Gentoo mailing list <gentoo-user@l.g.o>
Subject: Re: [gentoo-user] udev or Gentoo issue?
Date: Mon, 19 May 2014 20:47:21
Message-Id: CAN0CFw3PVp+wuPLvGqKZu3ingGcVESiUncfOs2qndk+QrtQuZA@mail.gmail.com
In Reply to: Re: [gentoo-user] udev or Gentoo issue? by Mike Gilbert
1 >>>> I have this:
2 >>>>
3 >>>> # dmesg | grep enp
4 >>>> [ 4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1
5 >>>> [ 4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2
6 >>>> [ 6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1
7 >>>> [ 7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1
8 >>>> #
9 >>>>
10 >>>> That doesn't tell us when the network initscripts tried and failed to
11 >>>> start but this from /var/log/messages/everything/current shows the
12 >>>> first time in the boot sequence that a dependent service failed to
13 >>>> start because of the networking failure so it should be before this:
14 >>>>
15 >>>> [kernel] [ 0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12
16 >>>> [/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1
17 >>>> would not start
18 >>>> [kernel] [ 0.792081] rtc_cmos 00:04: alarms up to one month, y3k,
19 >>>> 242 bytes nvram, hpet irqs
20 >>>>
21 >>>
22 >>> Yeah, so I think the kernel is detecting your network card after udev
23 >>> has already started.
24 >>>
25 >>> One interesting experiment would be to delay the boot process to allow
26 >>> the kernel additional time to detect devices. Adding rootdelay=10 to
27 >>> your kernel command line should do the trick, unless you are using
28 >>> some broken initramfs.
29 >>
30 >>
31 >> I tried that and it works great which I think confirms our suspicions
32 >> that the kernel is detecting my network cards after udev has already
33 >> started. If I remove rootdelay=10 and I do this:
34 >>
35 >> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
36 >>
37 >> the network interfaces fail to come up which is the same thing I've
38 >> experienced with rc_hotplug="net.*".
39 >>
40 >
41 > Yeah, so this is not solvable using service dependencies. You will
42 > either need to make that boot delay permanent, or rely on the hotplug
43 > functionality to start the net.en* services. In the latter case, you
44 > should remove them from the default runlevel.
45
46
47 Was the 10-second boot delay based on anything in particular or can I
48 try a lower delay like 5 seconds? It's tricky to get the machine back
49 when I lose it otherwise I would just test it myself.
50
51 Would it make sense for me to submit a feature request for network
52 interfaces to wait until all USB devices have been initialized before
53 starting (or something like that)?
54
55
56 > You may want to define rc_need="!net" to prevent init scripts that
57 > "need net" from automatically starting the net.* services. For most
58 > services this is fine, but it will obviously break things like ntpdate
59 > which actually need a usable network connection.
60
61
62 I don't follow this. Doesn't hotplug need to be able to start the
63 net.* services in order for that solution to work?
64
65 - Grant