Re: [gentoo-user] udev or Gentoo issue?
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
Re: [gentoo-user] udev or Gentoo issue?
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] udev or Gentoo issue?
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... signature.asc Description: PGP signature
Re: [gentoo-user] udev or Gentoo issue?
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?
On Sat, May 17, 2014 at 2:39 PM, Grant emailgr...@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?
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.foobar 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?
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.foobar 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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] udev or Gentoo issue?
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 signature.asc Description: PGP signature
Re: [gentoo-user] udev or Gentoo issue?
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.foobar 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?
On Thu, May 15, 2014 at 8:18 AM, Grant emailgr...@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?
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?
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.foobar default
Re: [gentoo-user] udev or Gentoo issue?
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?
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?
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.foobar 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?
On Wed, May 14, 2014 at 7:59 PM, Grant emailgr...@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.foobar 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?
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?
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?
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?
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.
