[gentoo-user] udev or Gentoo issue?

[gentoo-user] udev or Gentoo issue?

[Grant]

I'm having a problem starting the USB network interfaces properly on
one of my systems.  I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html

Should I file a bug?

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Samuli Suominen]

On 13/05/14 16:50, Grant wrote:
> I'm having a problem starting the USB network interfaces properly on
> one of my systems.  I brought the problem to the udev list and they're
> indicating that it's a Gentoo problem:
>
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>
> Should I file a bug?
>
> - Grant
>

Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE="udev")
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup

So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script

- Samuli

Re: [gentoo-user] udev or Gentoo issue?

[Samuli Suominen]

On 13/05/14 16:58, Samuli Suominen wrote:
> On 13/05/14 16:50, Grant wrote:
>> I'm having a problem starting the USB network interfaces properly on
>> one of my systems.  I brought the problem to the udev list and they're
>> indicating that it's a Gentoo problem:
>>
>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>
>> Should I file a bug?
>>
>> - Grant
>>
> Like pointed out in the upstream thread, it's either wrongly built
> net-misc/dhcpcd (should be with USE="udev")
> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
> /etc/init.d/net.lo depend() { } section --
> it's possible it's missing dependency that forces /etc/init.d/udev start
> first, specially if OpenRC is using parallel
> startup
>
> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
> OR bug in dependencies of netifrc's net.lo script
>
> - Samuli
>

Or possibly you have the net.* stuff in wrong runlevels that makes them
start
too early?
There could also be a problem regarding netifrc's udev hotplugging, you can
disable it altogether by:

# ln -s /dev/null /etc/udev/rules.d/90-network.rules

The symlink to /dev/null in /etc/udev/rules.d/90-network.rules makes
/lib/udev/rules.d/90-network.rules
no-op. Notice this 90-network.rules is also part of net-misc/netifrc, so
don't make the mistake of
assuming this is a bug in any of udev, eudev or systemd

- Samuli

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>> I'm having a problem starting the USB network interfaces properly on
>> one of my systems.  I brought the problem to the udev list and they're
>> indicating that it's a Gentoo problem:
>>
>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>
>> Should I file a bug?
>>
>> - Grant
>>
>
> Like pointed out in the upstream thread, it's either wrongly built
> net-misc/dhcpcd (should be with USE="udev")
> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
> /etc/init.d/net.lo depend() { } section --
> it's possible it's missing dependency that forces /etc/init.d/udev start
> first, specially if OpenRC is using parallel
> startup
>
> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
> OR bug in dependencies of netifrc's net.lo script


I'm starting two interfaces, one that uses dhcpcd and one that does
not.  Both fail to start in the default runlevel until they are
hotplugged later.  I do have dhcpcd built with USE=udev.  The string
"udev" does not occur in /etc/init.d/net.lo so maybe that's the
problem?  Please confirm that I should file a Gentoo bug for this.

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Samuli Suominen]

On 14/05/14 03:18, Grant wrote:
>>> I'm having a problem starting the USB network interfaces properly on
>>> one of my systems.  I brought the problem to the udev list and they're
>>> indicating that it's a Gentoo problem:
>>>
>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>
>>> Should I file a bug?
>>>
>>> - Grant
>>>
>> Like pointed out in the upstream thread, it's either wrongly built
>> net-misc/dhcpcd (should be with USE="udev")
>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>> /etc/init.d/net.lo depend() { } section --
>> it's possible it's missing dependency that forces /etc/init.d/udev start
>> first, specially if OpenRC is using parallel
>> startup
>>
>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>> OR bug in dependencies of netifrc's net.lo script
>
> I'm starting two interfaces, one that uses dhcpcd and one that does
> not.  Both fail to start in the default runlevel until they are
> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
> problem?  Please confirm that I should file a Gentoo bug for this.
>
> - Grant
>

Try adding 'after udev' to net.lo's depend() { } section and see if that
helps, if it does, file a bug
saying so.
It was more of an educated guess than 100% accurate knowledge. I can't
think of an another
way to force netifrc to behave, since it's not coded in C, and it can't
link to libudev, so...

However since you say *both*, even the one with dhcpcd fail to start,
before filing that bug,
see if disabling netifrc hotplugging works:

# ln -s /dev/null /etc/udev/rules.d/90-network.rules

And if that helps, then file a bug saying so.

One or the another, bug is propably needed in anycase.

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>>>> I'm having a problem starting the USB network interfaces properly on
>>>> one of my systems.  I brought the problem to the udev list and they're
>>>> indicating that it's a Gentoo problem:
>>>>
>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>
>>>> Should I file a bug?
>>>>
>>>> - Grant
>>>>
>>> Like pointed out in the upstream thread, it's either wrongly built
>>> net-misc/dhcpcd (should be with USE="udev")
>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>> /etc/init.d/net.lo depend() { } section --
>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>> first, specially if OpenRC is using parallel
>>> startup
>>>
>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>> OR bug in dependencies of netifrc's net.lo script
>>
>> I'm starting two interfaces, one that uses dhcpcd and one that does
>> not.  Both fail to start in the default runlevel until they are
>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>> problem?  Please confirm that I should file a Gentoo bug for this.
>>
>> - Grant
>>
>
> Try adding 'after udev' to net.lo's depend() { } section and see if that
> helps, if it does, file a bug
> saying so.


I added it like this and rebooted:

depend()
{
        after udev

but the result was the same.  I also have udev and udev-mount in the
sysinit runlevel.


> It was more of an educated guess than 100% accurate knowledge. I can't
> think of an another
> way to force netifrc to behave, since it's not coded in C, and it can't
> link to libudev, so...
>
> However since you say *both*, even the one with dhcpcd fail to start,
> before filing that bug,
> see if disabling netifrc hotplugging works:
>
> # ln -s /dev/null /etc/udev/rules.d/90-network.rules


Will that disable interface renaming or hotplugging?  The system with
the issue is remote and if the interfaces aren't renamed or if
hotplugging doesn't happen then I won't be able to access the system
for up to 24 hours.  That's fine and I'm happy to test stuff like this
anyway but I don't think this particular test will be informative
because:

1. I'm 99% sure everything would work fine with the interfaces at eth0
and eth1 since the issue seems to be that udev is renaming the
interfaces too late in the boot process, but I like having
location-based names.

2. I can enable and disable hotplug in rc.conf and the interfaces
don't come up with it disabled.

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Samuli Suominen]

On 14/05/14 15:42, Grant wrote:
>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>> indicating that it's a Gentoo problem:
>>>>>
>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>
>>>>> Should I file a bug?
>>>>>
>>>>> - Grant
>>>>>
>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>> net-misc/dhcpcd (should be with USE="udev")
>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>> /etc/init.d/net.lo depend() { } section --
>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>> first, specially if OpenRC is using parallel
>>>> startup
>>>>
>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>> OR bug in dependencies of netifrc's net.lo script
>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>> not.  Both fail to start in the default runlevel until they are
>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>
>>> - Grant
>>>
>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>> helps, if it does, file a bug
>> saying so.
>
> I added it like this and rebooted:
>
> depend()
> {
>         after udev
>
> but the result was the same.  I also have udev and udev-mount in the
> sysinit runlevel.
>
>
>> It was more of an educated guess than 100% accurate knowledge. I can't
>> think of an another
>> way to force netifrc to behave, since it's not coded in C, and it can't
>> link to libudev, so...
>>
>> However since you say *both*, even the one with dhcpcd fail to start,
>> before filing that bug,
>> see if disabling netifrc hotplugging works:
>>
>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>
> Will that disable interface renaming or hotplugging?  The system with
> the issue is remote and if the interfaces aren't renamed or if
> hotplugging doesn't happen then I won't be able to access the system
> for up to 24 hours.  That's fine and I'm happy to test stuff like this
> anyway but I don't think this particular test will be informative
> because:

It will disable the hotplugging, it means you *must* have the net.*
stuff added
to the default to runlevel yourself, like eg.

# rc-update add net.foooooobar default

Re: [gentoo-user] udev or Gentoo issue?

[Samuli Suominen]

On 14/05/14 15:42, Grant wrote:
>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>> indicating that it's a Gentoo problem:
>>>>>
>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>
>>>>> Should I file a bug?
>>>>>
>>>>> - Grant
>>>>>
>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>> net-misc/dhcpcd (should be with USE="udev")
>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>> /etc/init.d/net.lo depend() { } section --
>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>> first, specially if OpenRC is using parallel
>>>> startup
>>>>
>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>> OR bug in dependencies of netifrc's net.lo script
>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>> not.  Both fail to start in the default runlevel until they are
>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>
>>> - Grant
>>>
>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>> helps, if it does, file a bug
>> saying so.
>
> I added it like this and rebooted:
>
> depend()
> {
>         after udev

hmm, try "need udev" instead of "after udev", I keep forgetting their
difference
within parallel startup

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>>> indicating that it's a Gentoo problem:
>>>>>>
>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>>
>>>>>> Should I file a bug?
>>>>>>
>>>>>> - Grant
>>>>>>
>>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>>> net-misc/dhcpcd (should be with USE="udev")
>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>>> /etc/init.d/net.lo depend() { } section --
>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>>> first, specially if OpenRC is using parallel
>>>>> startup
>>>>>
>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>>> OR bug in dependencies of netifrc's net.lo script
>>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>>> not.  Both fail to start in the default runlevel until they are
>>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>>
>>>> - Grant
>>>>
>>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>>> helps, if it does, file a bug
>>> saying so.
>>
>> I added it like this and rebooted:
>>
>> depend()
>> {
>>         after udev
>
> hmm, try "need udev" instead of "after udev", I keep forgetting their
> difference
> within parallel startup


I just tried that with the same result unfortunately.  I don't have
rc_parallel defined in rc.conf and the file's comments seems to
indicate that the default is rc_parallel="NO".

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>>> indicating that it's a Gentoo problem:
>>>>>>
>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>>
>>>>>> Should I file a bug?
>>>>>>
>>>>>> - Grant
>>>>>>
>>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>>> net-misc/dhcpcd (should be with USE="udev")
>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>>> /etc/init.d/net.lo depend() { } section --
>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>>> first, specially if OpenRC is using parallel
>>>>> startup
>>>>>
>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>>> OR bug in dependencies of netifrc's net.lo script
>>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>>> not.  Both fail to start in the default runlevel until they are
>>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>>
>>>> - Grant
>>>>
>>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>>> helps, if it does, file a bug
>>> saying so.
>>
>> I added it like this and rebooted:
>>
>> depend()
>> {
>>         after udev
>>
>> but the result was the same.  I also have udev and udev-mount in the
>> sysinit runlevel.
>>
>>
>>> It was more of an educated guess than 100% accurate knowledge. I can't
>>> think of an another
>>> way to force netifrc to behave, since it's not coded in C, and it can't
>>> link to libudev, so...
>>>
>>> However since you say *both*, even the one with dhcpcd fail to start,
>>> before filing that bug,
>>> see if disabling netifrc hotplugging works:
>>>
>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>>
>> Will that disable interface renaming or hotplugging?  The system with
>> the issue is remote and if the interfaces aren't renamed or if
>> hotplugging doesn't happen then I won't be able to access the system
>> for up to 24 hours.  That's fine and I'm happy to test stuff like this
>> anyway but I don't think this particular test will be informative
>> because:
>
> It will disable the hotplugging, it means you *must* have the net.*
> stuff added
> to the default to runlevel yourself, like eg.
>
> # rc-update add net.foooooobar default


They're in the default runlevel:

# rc-update|grep net.enp
      net.enp0s20u2u1 |      default
      net.enp0s20u2u2 |      default

I can disable hotplugging with rc_hotplug in rc.conf.  Hotplugging is
actually disabled by default there and my network interfaces won't
start automatically that way.

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Mike Gilbert]

On Wed, May 14, 2014 at 7:59 PM, Grant <emailgrant@gmail.com> wrote:
>>>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>>>> indicating that it's a Gentoo problem:
>>>>>>>
>>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>>>
>>>>>>> Should I file a bug?
>>>>>>>
>>>>>>> - Grant
>>>>>>>
>>>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>>>> net-misc/dhcpcd (should be with USE="udev")
>>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>>>> /etc/init.d/net.lo depend() { } section --
>>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>>>> first, specially if OpenRC is using parallel
>>>>>> startup
>>>>>>
>>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>>>> OR bug in dependencies of netifrc's net.lo script
>>>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>>>> not.  Both fail to start in the default runlevel until they are
>>>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>>>
>>>>> - Grant
>>>>>
>>>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>>>> helps, if it does, file a bug
>>>> saying so.
>>>
>>> I added it like this and rebooted:
>>>
>>> depend()
>>> {
>>>         after udev
>>>
>>> but the result was the same.  I also have udev and udev-mount in the
>>> sysinit runlevel.
>>>
>>>
>>>> It was more of an educated guess than 100% accurate knowledge. I can't
>>>> think of an another
>>>> way to force netifrc to behave, since it's not coded in C, and it can't
>>>> link to libudev, so...
>>>>
>>>> However since you say *both*, even the one with dhcpcd fail to start,
>>>> before filing that bug,
>>>> see if disabling netifrc hotplugging works:
>>>>
>>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>>>
>>> Will that disable interface renaming or hotplugging?  The system with
>>> the issue is remote and if the interfaces aren't renamed or if
>>> hotplugging doesn't happen then I won't be able to access the system
>>> for up to 24 hours.  That's fine and I'm happy to test stuff like this
>>> anyway but I don't think this particular test will be informative
>>> because:
>>
>> It will disable the hotplugging, it means you *must* have the net.*
>> stuff added
>> to the default to runlevel yourself, like eg.
>>
>> # rc-update add net.foooooobar default
>
>
> They're in the default runlevel:
>
> # rc-update|grep net.enp
>       net.enp0s20u2u1 |      default
>       net.enp0s20u2u2 |      default
>
> I can disable hotplugging with rc_hotplug in rc.conf.  Hotplugging is
> actually disabled by default there and my network interfaces won't
> start automatically that way.
>

Does your kernel have timing info enabled? If so, it would be
interesting to look at your dmesg output.

My guess is that your kernel is taking a really long time (several
seconds) to initialize your network cards.

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>>>>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>>>>> indicating that it's a Gentoo problem:
>>>>>>>>
>>>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>>>>
>>>>>>>> Should I file a bug?
>>>>>>>>
>>>>>>>> - Grant
>>>>>>>>
>>>>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>>>>> net-misc/dhcpcd (should be with USE="udev")
>>>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>>>>> /etc/init.d/net.lo depend() { } section --
>>>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>>>>> first, specially if OpenRC is using parallel
>>>>>>> startup
>>>>>>>
>>>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>>>>> OR bug in dependencies of netifrc's net.lo script
>>>>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>>>>> not.  Both fail to start in the default runlevel until they are
>>>>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>>>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>>>>
>>>>>> - Grant
>>>>>>
>>>>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>>>>> helps, if it does, file a bug
>>>>> saying so.
>>>>
>>>> I added it like this and rebooted:
>>>>
>>>> depend()
>>>> {
>>>>         after udev
>>>>
>>>> but the result was the same.  I also have udev and udev-mount in the
>>>> sysinit runlevel.
>>>>
>>>>
>>>>> It was more of an educated guess than 100% accurate knowledge. I can't
>>>>> think of an another
>>>>> way to force netifrc to behave, since it's not coded in C, and it can't
>>>>> link to libudev, so...
>>>>>
>>>>> However since you say *both*, even the one with dhcpcd fail to start,
>>>>> before filing that bug,
>>>>> see if disabling netifrc hotplugging works:
>>>>>
>>>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>>>>
>>>> Will that disable interface renaming or hotplugging?  The system with
>>>> the issue is remote and if the interfaces aren't renamed or if
>>>> hotplugging doesn't happen then I won't be able to access the system
>>>> for up to 24 hours.  That's fine and I'm happy to test stuff like this
>>>> anyway but I don't think this particular test will be informative
>>>> because:
>>>
>>> It will disable the hotplugging, it means you *must* have the net.*
>>> stuff added
>>> to the default to runlevel yourself, like eg.
>>>
>>> # rc-update add net.foooooobar default
>>
>>
>> They're in the default runlevel:
>>
>> # rc-update|grep net.enp
>>       net.enp0s20u2u1 |      default
>>       net.enp0s20u2u2 |      default
>>
>> I can disable hotplugging with rc_hotplug in rc.conf.  Hotplugging is
>> actually disabled by default there and my network interfaces won't
>> start automatically that way.
>>
>
> Does your kernel have timing info enabled? If so, it would be
> interesting to look at your dmesg output.
>
> My guess is that your kernel is taking a really long time (several
> seconds) to initialize your network cards.


I have this:

# dmesg | grep enp
[    4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1
[    4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2
[    6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1
[    7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1
#

That doesn't tell us when the network initscripts tried and failed to
start but this from /var/log/messages/everything/current shows the
first time in the boot sequence that a dependent service failed to
start because of the networking failure so it should be before this:

[kernel] [    0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12
[/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1
would not start
[kernel] [    0.792081] rtc_cmos 00:04: alarms up to one month, y3k,
242 bytes nvram, hpet irqs

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Mike Gilbert]

On Thu, May 15, 2014 at 8:18 AM, Grant <emailgrant@gmail.com> wrote:
> I have this:
>
> # dmesg | grep enp
> [    4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1
> [    4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2
> [    6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1
> [    7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1
> #
>
> That doesn't tell us when the network initscripts tried and failed to
> start but this from /var/log/messages/everything/current shows the
> first time in the boot sequence that a dependent service failed to
> start because of the networking failure so it should be before this:
>
> [kernel] [    0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12
> [/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1
> would not start
> [kernel] [    0.792081] rtc_cmos 00:04: alarms up to one month, y3k,
> 242 bytes nvram, hpet irqs
>

Yeah, so I think the kernel is detecting your network card after udev
has already started.

One interesting experiment would be to delay the boot process to allow
the kernel additional time to detect devices. Adding rootdelay=10 to
your kernel command line should do the trick, unless you are using
some broken initramfs.

Re: [gentoo-user] udev or Gentoo issue?

[Samuli Suominen]

On 15/05/14 02:59, Grant wrote:
>>>>>>> I'm having a problem starting the USB network interfaces properly on
>>>>>>> one of my systems.  I brought the problem to the udev list and they're
>>>>>>> indicating that it's a Gentoo problem:
>>>>>>>
>>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
>>>>>>>
>>>>>>> Should I file a bug?
>>>>>>>
>>>>>>> - Grant
>>>>>>>
>>>>>> Like pointed out in the upstream thread, it's either wrongly built
>>>>>> net-misc/dhcpcd (should be with USE="udev")
>>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
>>>>>> /etc/init.d/net.lo depend() { } section --
>>>>>> it's possible it's missing dependency that forces /etc/init.d/udev start
>>>>>> first, specially if OpenRC is using parallel
>>>>>> startup
>>>>>>
>>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
>>>>>> OR bug in dependencies of netifrc's net.lo script
>>>>> I'm starting two interfaces, one that uses dhcpcd and one that does
>>>>> not.  Both fail to start in the default runlevel until they are
>>>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
>>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
>>>>> problem?  Please confirm that I should file a Gentoo bug for this.
>>>>>
>>>>> - Grant
>>>>>
>>>> Try adding 'after udev' to net.lo's depend() { } section and see if that
>>>> helps, if it does, file a bug
>>>> saying so.
>>> I added it like this and rebooted:
>>>
>>> depend()
>>> {
>>>         after udev
>>>
>>> but the result was the same.  I also have udev and udev-mount in the
>>> sysinit runlevel.
>>>
>>>
>>>> It was more of an educated guess than 100% accurate knowledge. I can't
>>>> think of an another
>>>> way to force netifrc to behave, since it's not coded in C, and it can't
>>>> link to libudev, so...
>>>>
>>>> However since you say *both*, even the one with dhcpcd fail to start,
>>>> before filing that bug,
>>>> see if disabling netifrc hotplugging works:
>>>>
>>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>>> Will that disable interface renaming or hotplugging?  The system with
>>> the issue is remote and if the interfaces aren't renamed or if
>>> hotplugging doesn't happen then I won't be able to access the system
>>> for up to 24 hours.  That's fine and I'm happy to test stuff like this
>>> anyway but I don't think this particular test will be informative
>>> because:
>> It will disable the hotplugging, it means you *must* have the net.*
>> stuff added
>> to the default to runlevel yourself, like eg.
>>
>> # rc-update add net.foooooobar default
>
> They're in the default runlevel:
>
> # rc-update|grep net.enp
>       net.enp0s20u2u1 |      default
>       net.enp0s20u2u2 |      default
>
> I can disable hotplugging with rc_hotplug in rc.conf.  Hotplugging is
> actually disabled by default there and my network interfaces won't
> start automatically that way.
>
>

I'm not 100% sure the rc_hotplug will also disable the 90-network.rules
triggered
interface hotplugging
Don't count on that

- Samuli

Re: [gentoo-user] udev or Gentoo issue?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3718 bytes --]

On Friday 16 May 2014 11:43:41 Samuli Suominen wrote:
> On 15/05/14 02:59, Grant wrote:
> >>>>>>> I'm having a problem starting the USB network interfaces properly
> >>>>>>> on one of my systems.  I brought the problem to the udev list and
> >>>>>>> they're indicating that it's a Gentoo problem:
> >>>>>>> 
> >>>>>>> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/ms
> >>>>>>> g18840.html
> >>>>>>> 
> >>>>>>> Should I file a bug?
> >>>>>>> 
> >>>>>>> - Grant
> >>>>>> 
> >>>>>> Like pointed out in the upstream thread, it's either wrongly built
> >>>>>> net-misc/dhcpcd (should be with USE="udev")
> >>>>>> and if not using dhcpcd, it might be a bug in net-misc/netifrc's
> >>>>>> /etc/init.d/net.lo depend() { } section --
> >>>>>> it's possible it's missing dependency that forces /etc/init.d/udev
> >>>>>> start first, specially if OpenRC is using parallel
> >>>>>> startup
> >>>>>> 
> >>>>>> So not really a udev bug, rather a misconfiguration in dhcpcd USE
> >>>>>> flags OR bug in dependencies of netifrc's net.lo script
> >>>>> 
> >>>>> I'm starting two interfaces, one that uses dhcpcd and one that does
> >>>>> not.  Both fail to start in the default runlevel until they are
> >>>>> hotplugged later.  I do have dhcpcd built with USE=udev.  The string
> >>>>> "udev" does not occur in /etc/init.d/net.lo so maybe that's the
> >>>>> problem?  Please confirm that I should file a Gentoo bug for this.
> >>>>> 
> >>>>> - Grant
> >>>> 
> >>>> Try adding 'after udev' to net.lo's depend() { } section and see if
> >>>> that helps, if it does, file a bug
> >>>> saying so.
> >>> 
> >>> I added it like this and rebooted:
> >>> 
> >>> depend()
> >>> {
> >>> 
> >>>         after udev
> >>> 
> >>> but the result was the same.  I also have udev and udev-mount in the
> >>> sysinit runlevel.
> >>> 
> >>>> It was more of an educated guess than 100% accurate knowledge. I can't
> >>>> think of an another
> >>>> way to force netifrc to behave, since it's not coded in C, and it
> >>>> can't link to libudev, so...
> >>>> 
> >>>> However since you say *both*, even the one with dhcpcd fail to start,
> >>>> before filing that bug,
> >>>> see if disabling netifrc hotplugging works:
> >>>> 
> >>>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
> >>> 
> >>> Will that disable interface renaming or hotplugging?  The system with
> >>> the issue is remote and if the interfaces aren't renamed or if
> >>> hotplugging doesn't happen then I won't be able to access the system
> >>> for up to 24 hours.  That's fine and I'm happy to test stuff like this
> >>> anyway but I don't think this particular test will be informative
> >> 
> >>> because:
> >> It will disable the hotplugging, it means you *must* have the net.*
> >> stuff added
> >> to the default to runlevel yourself, like eg.
> >> 
> >> # rc-update add net.foooooobar default
> > 
> > They're in the default runlevel:
> > 
> > # rc-update|grep net.enp
> > 
> >       net.enp0s20u2u1 |      default
> >       net.enp0s20u2u2 |      default
> > 
> > I can disable hotplugging with rc_hotplug in rc.conf.  Hotplugging is
> > actually disabled by default there and my network interfaces won't
> > start automatically that way.
> 
> I'm not 100% sure the rc_hotplug will also disable the 90-network.rules
> triggered
> interface hotplugging
> Don't count on that

Samuli's right.  I was experimenting on a new install how to stop net.eth0 
from coming up (it was stalling forever because there was no ethernet cable 
present).  No matter what I tried with /etc/rc.conf, or eselect rc, I couldn't 
stop the darn thing starting up.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] udev or Gentoo issue?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Fri, 16 May 2014 17:07:33 +0100, Mick wrote:

> Samuli's right.  I was experimenting on a new install how to stop
> net.eth0 from coming up (it was stalling forever because there was no
> ethernet cable present).  No matter what I tried with /etc/rc.conf, or
> eselect rc, I couldn't stop the darn thing starting up.

AFAIR you ned to install ifplugd, but not configure or run it. openrc
uses it to determine if a cable is plugged in and delay setting up the
interface if there is none.


-- 
Neil Bothwick

New Intel opcode #007 PUKE: Put unmeaningful keywords everywhere

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev or Gentoo issue?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 784 bytes --]

On Friday 16 May 2014 21:04:41 Neil Bothwick wrote:
> On Fri, 16 May 2014 17:07:33 +0100, Mick wrote:
> > Samuli's right.  I was experimenting on a new install how to stop
> > net.eth0 from coming up (it was stalling forever because there was no
> > ethernet cable present).  No matter what I tried with /etc/rc.conf, or
> > eselect rc, I couldn't stop the darn thing starting up.
> 
> AFAIR you ned to install ifplugd, but not configure or run it. openrc
> uses it to determine if a cable is plugged in and delay setting up the
> interface if there is none.

That's how I have been doing it, using ifplugd to monitor the presence of a 
link, but seem to recall that there is/was a netifrc-way of managing which 
network interface comes up at boot.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] udev or Gentoo issue?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Sat, 17 May 2014 08:15:19 +0100, Mick wrote:

> > AFAIR you ned to install ifplugd, but not configure or run it. openrc
> > uses it to determine if a cable is plugged in and delay setting up the
> > interface if there is none.  
> 
> That's how I have been doing it, using ifplugd to monitor the presence
> of a link, but seem to recall that there is/was a netifrc-way of
> managing which network interface comes up at boot.

I'm not saying you should use ifplugd, only that you should install it so
that openrc can use it.


-- 
Neil Bothwick

"Energize!" said Picard and the pink bunny appeared...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>> I have this:
>>
>> # dmesg | grep enp
>> [    4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1
>> [    4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2
>> [    6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1
>> [    7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1
>> #
>>
>> That doesn't tell us when the network initscripts tried and failed to
>> start but this from /var/log/messages/everything/current shows the
>> first time in the boot sequence that a dependent service failed to
>> start because of the networking failure so it should be before this:
>>
>> [kernel] [    0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12
>> [/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1
>> would not start
>> [kernel] [    0.792081] rtc_cmos 00:04: alarms up to one month, y3k,
>> 242 bytes nvram, hpet irqs
>>
>
> Yeah, so I think the kernel is detecting your network card after udev
> has already started.
>
> One interesting experiment would be to delay the boot process to allow
> the kernel additional time to detect devices. Adding rootdelay=10 to
> your kernel command line should do the trick, unless you are using
> some broken initramfs.


I tried that and it works great which I think confirms our suspicions
that the kernel is detecting my network cards after udev has already
started.  If I remove rootdelay=10 and I do this:

# ln -s /dev/null /etc/udev/rules.d/90-network.rules

the network interfaces fail to come up which is the same thing I've
experienced with rc_hotplug="net.*".

- Grant

Re: [gentoo-user] udev or Gentoo issue?

[Mike Gilbert]

On Sat, May 17, 2014 at 2:39 PM, Grant <emailgrant@gmail.com> wrote:
>>> I have this:
>>>
>>> # dmesg | grep enp
>>> [    4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1
>>> [    4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2
>>> [    6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1
>>> [    7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1
>>> #
>>>
>>> That doesn't tell us when the network initscripts tried and failed to
>>> start but this from /var/log/messages/everything/current shows the
>>> first time in the boot sequence that a dependent service failed to
>>> start because of the networking failure so it should be before this:
>>>
>>> [kernel] [    0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12
>>> [/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1
>>> would not start
>>> [kernel] [    0.792081] rtc_cmos 00:04: alarms up to one month, y3k,
>>> 242 bytes nvram, hpet irqs
>>>
>>
>> Yeah, so I think the kernel is detecting your network card after udev
>> has already started.
>>
>> One interesting experiment would be to delay the boot process to allow
>> the kernel additional time to detect devices. Adding rootdelay=10 to
>> your kernel command line should do the trick, unless you are using
>> some broken initramfs.
>
>
> I tried that and it works great which I think confirms our suspicions
> that the kernel is detecting my network cards after udev has already
> started.  If I remove rootdelay=10 and I do this:
>
> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>
> the network interfaces fail to come up which is the same thing I've
> experienced with rc_hotplug="net.*".
>

Yeah, so this is not solvable using service dependencies. You will
either need to make that boot delay permanent, or rely on the hotplug
functionality to start the net.en* services. In the latter case, you
should remove them from the default runlevel.

You may want to define rc_need="!net" to prevent init scripts that
"need net" from automatically starting the net.* services. For most
services this is fine, but it will obviously break things like ntpdate
which actually need a usable network connection.

Re: [gentoo-user] udev or Gentoo issue?

[Grant]

>>>> I have this:
>>>>
>>>> # dmesg | grep enp
>>>> [    4.297862] systemd-udevd[659]: renamed network interface eth0 to enp0s20u2u1
>>>> [    4.778289] systemd-udevd[660]: renamed network interface eth0 to enp0s20u2u2
>>>> [    6.496193] ax88179_178a 3-2.1:1.0 enp0s20u2u1: ax88179 - Link status is: 1
>>>> [    7.905393] ax88179_178a 3-2.2:1.0 enp0s20u2u2: ax88179 - Link status is: 1
>>>> #
>>>>
>>>> That doesn't tell us when the network initscripts tried and failed to
>>>> start but this from /var/log/messages/everything/current shows the
>>>> first time in the boot sequence that a dependent service failed to
>>>> start because of the networking failure so it should be before this:
>>>>
>>>> [kernel] [    0.787433] serio: i8042 AUX port at 0x60,0x64 irq 12
>>>> [/etc/init.d/unbound] ERROR: cannot start unbound as net.enp0s20u2u1
>>>> would not start
>>>> [kernel] [    0.792081] rtc_cmos 00:04: alarms up to one month, y3k,
>>>> 242 bytes nvram, hpet irqs
>>>>
>>>
>>> Yeah, so I think the kernel is detecting your network card after udev
>>> has already started.
>>>
>>> One interesting experiment would be to delay the boot process to allow
>>> the kernel additional time to detect devices. Adding rootdelay=10 to
>>> your kernel command line should do the trick, unless you are using
>>> some broken initramfs.
>>
>>
>> I tried that and it works great which I think confirms our suspicions
>> that the kernel is detecting my network cards after udev has already
>> started.  If I remove rootdelay=10 and I do this:
>>
>> # ln -s /dev/null /etc/udev/rules.d/90-network.rules
>>
>> the network interfaces fail to come up which is the same thing I've
>> experienced with rc_hotplug="net.*".
>>
>
> Yeah, so this is not solvable using service dependencies. You will
> either need to make that boot delay permanent, or rely on the hotplug
> functionality to start the net.en* services. In the latter case, you
> should remove them from the default runlevel.


Was the 10-second boot delay based on anything in particular or can I
try a lower delay like 5 seconds?  It's tricky to get the machine back
when I lose it otherwise I would just test it myself.

Would it make sense for me to submit a feature request for network
interfaces to wait until all USB devices have been initialized before
starting (or something like that)?


> You may want to define rc_need="!net" to prevent init scripts that
> "need net" from automatically starting the net.* services. For most
> services this is fine, but it will obviously break things like ntpdate
> which actually need a usable network connection.


I don't follow this.  Doesn't hotplug need to be able to start the
net.* services in order for that solution to work?

- Grant