# Odd network problem - udev related?

## MoonWalker

So I have this odd network problem, and it's odd because according to start up messages displayed on the monitor screen and dmesg the network is never coming up - but somehow it still does according to ifconfig -a and works. I only noticed this as I was trying to upgrade the kernel and while it compiled ok it somehow refused to boot just hanging midway during load and I had to restore from backup image (but that is another issue I'm going to tackle once I have solved this and can be sure it doesn't case it).  I cannot see anything wrong with my network configuration, and this box have indeed been running for years ticking as a clock. Still when looking at the boot up messages and dmesg something clearly is wrong and I hope someone can help me figure out what.

 So what I get on the screen during boot up is this:

```
* Bringing up network interface lo ...           [ok]

* Bringing up interface lo 

RTNETLINK answers: Invalid argument

Cannot send link get request: Invalid argument
```

and further down

```
* Bringing up interface enp2s0 

RTNETLINK answers: Invalid argument

Cannot send link get request: Invalid argument
```

relevant stuff from dmesg 

```
[    0.652984] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    0.653069] r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17

[    0.653261] r8169 0000:02:00.0: setting latency timer to 64

[    0.653299]   alloc irq_desc for 26 on node -1

[    0.653301]   alloc kstat_irqs on node -1

[    0.653314] r8169 0000:02:00.0: irq 26 for MSI/MSI-X

[    0.653416] r8169 0000:02:00.0: eth0: RTL8168c/8111c at 0xffffc90000312000, 00:1f:d0:cf:b5:d5, XID 1c4000c0 IRQ 26

[    0.653531] r8169 0000:02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]

...

[    3.142346] <30>systemd-udevd[206]: starting version 224

[    3.833598] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4

[    3.937584] <28>systemd-udevd[234]: Process 'net.sh eth0 start' failed with exit code 1.

...

[    7.822576] r8169 0000:02:00.0: enp2s0: link down

[    7.822587] r8169 0000:02:00.0: enp2s0: link down

[    8.378246] ip_tables: (C) 2000-2006 Netfilter Core Team

[    8.844410] Enabling conntracks and NAT for ve0

[    8.844415] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)

[    8.951635] RPC: Registered named UNIX socket transport module.

[    8.951640] RPC: Registered udp transport module.

[    8.951642] RPC: Registered tcp transport module.

[    8.951644] RPC: Registered tcp NFSv4.1 backchannel transport module.

[    9.055811] Slow work thread pool: Starting up

[    9.055876] Slow work thread pool: Ready

[    9.055923] FS-Cache: Loaded

[    9.361944] NFS: Registering the id_resolver key type

[    9.361999] FS-Cache: Netfs 'nfs' registered for caching

[    9.718621] NET: Registered protocol family 10

[    9.718879] ADDRCONF(NETDEV_UP): enp2s0: link is not ready

[    9.765984] r8169 0000:02:00.0: enp2s0: link up

[    9.766282] ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready

[   10.066623] <28>systemd-udevd[1096]: Process 'net.sh venet0 start' failed with exit code 1.

[   11.210658] CT: 101: started

[   11.271709] CT: 103: started

[   11.319045] CT: 107: started

[   11.379643] CT: 102: started

[   11.416732] CT: 104: started

[   11.463009] CT: 105: started

[   20.031259] enp2s0: no IPv6 routers present
```

 # cat /etc/conf.d/net

```
config_enp2s0="192.168.1.66/24 brd 192.168.1.255

192.168.1.67/24 brd 192.168.1.255

192.168.1.68/24 brd 192.168.1.255

192.168.1.69/24 brd 192.168.1.255"

routes_enp2s0="default via 192.168.1.1"

dns_servers_enp2s0="192.168.0.101"

dns_domain_lo="acnet"

postup() {

/usr/sbin/vzifup-post ${IFACE}

}
```

I have the proper symlinks created in /etc/init.d/ etc.

Actually, it's not hard to see what's wrong looking at the dmesg, one can think. It appears kernel offers eth0 while /etc/conf.d/net uses enp2s0 as interface, but swapping enp2s0 for eth0 in conf.d/net doesn't change anything... and it's still possible to connect outside the server. Sp I don't understand this at all, unless... this is due to a "misfit" between the kernel and udev, possibly.

this looks pretty normal to me though

```
# ifconfig -a

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.101  netmask 255.255.255.0  broadcast 192.168.1.255

        inet6 fe80::21f:d0ff:fecf:b5d5  prefixlen 64  scopeid 0x20<link>

        ether 00:1f:d0:cf:b5:d5  txqueuelen 1000  (Ethernet)

        RX packets 8651  bytes 5880387 (5.6 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 4263  bytes 417469 (407.6 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 0  (Local Loopback)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500

        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)

        RX packets 204  bytes 15100 (14.7 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 169  bytes 39589 (38.6 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

So what's really going on. I use openvz-sources and it has always worked fine with udev. I upgraded udev and changed to the predictable interface already back with udev-200 or if it was 201. I now see that the oldest udev available in the tree, udev-216 now demands kernel 2.6.39 as minimum but openvz is stuck on 2.6.32 (although heavily patched) since forever. So is this in a nutshell the problem and I simply have to give up on udev and change to eudev or mdev? anyone?

----------

## MoonWalker

Some progress, I followed the Gentoo Without systemd wiki guide and replaced udev for eudev (although portage wasn't smart enough to handle it without a helping hand, and eudev as well gives thumb down to kernels older than 2.6.39 - openvz is built on 2.6.32) and it seems to have cured some of the net failures during boot up reported by dmesg.

```
[    3.937584] <28>systemd-udevd[234]: Process 'net.sh eth0 start' failed with exit code 1. 

and

[   10.066623] <28>systemd-udevd[1096]: Process 'net.sh venet0 start' failed with exit code 1.
```

they are now gone, and ifconfig -a gives a slightly different result, especually for the very first inet line

```
# ifconfig -a

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.66  netmask 255.255.255.0  broadcast 192.168.1.255

        inet6 fe80::21f:d0ff:fecf:b5d5  prefixlen 64  scopeid 0x20<link>

        ether 00:1f:d0:cf:b5:d5  txqueuelen 1000  (Ethernet)

        RX packets 2098  bytes 288225 (281.4 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 485  bytes 95724 (93.4 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 0  (Local Loopback)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500

        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)

        RX packets 178  bytes 12863 (12.5 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 148  bytes 43808 (42.7 KiB)

        TX errors 0  dropped 6 overruns 0  carrier 0  collisions 0
```

But still the same failures reported on console during boot regarding 'bringing up interface x' where x is either of lo and enp2s0, as in first post. Anyone have an idea of what's going on there? it's odd as first 'network interface lo' comes up [ok] and obviously also enp2s0 although reported to fail, and before that just 'interface lo' fails. To me it appears as if they shouldn't be there at all but why they are, is a mystery to me. Like some "ghost process" trying to bring them up. No, the box has not been hacked, it's not accessible from outside and used by no one else than me.

[/code]

----------

## JeffBlair

OK, I think I found the issue, but no clue how to fix it.

I was getting the same error. My network wasn't starting, and getting that same error message you guys got. Well, I downgraded openrc from 18.3 to 17. After I rebooted, everything came up like normal.

After upgrading to 18.3 there's this bit:

```

"In this version of OpenRC, the loopback interface no longer"

"satisfies the net virtual."

"If you have services now which do not start because of this,"

"They can be fixed by adding rc_need=\"!net\""

"to the ${EROOT}etc/conf.d/<servicename> file."

"You should also file a bug against the service asking that"

"need net be dropped from the dependencies."

"The bug you file should block the following tracker:"

"https://bugs.gentoo.org/show_bug.cgi?id=439092"
```

I'm thinking that this is what's stopping the net.e* from starting. Any ideas?

----------

## charles17

 *MoonWalker wrote:*   

> But still the same failures reported on console during boot regarding 'bringing up interface x' where x is either of lo and enp2s0, as in first post. Anyone have an idea of what's going on there? it's odd as first 'network interface lo' comes up [ok] and obviously also enp2s0 although reported to fail, and before that just 'interface lo' fails. To me it appears as if they shouldn't be there at all but why they are, is a mystery to me. Like some "ghost process" trying to bring them up. No, the box has not been hacked, it's not accessible from outside and used by no one else than me.
> 
> 

 

Could you do dmesg | grep -i 'enp2s0\|network interface' and post the result here?  

So we could see what's gouing on.

----------

## MoonWalker

Thanks for your feedback guys but this issue is now history to me. Part of the problem seem to have been with udev, maybe because it requires at least 2.6.39 kernel and the openvz currently doesn't have any later than 2.6.32, although heavily patched. But I also had some hardware problems and after replacing the mobo, psu and gfx all now seem to be back to normal.

Strangely, eudev has the same kernel requirements but seem to work nevertheless.

----------

## JeffBlair

I fixed my issue on the new openrc as well. I added the line

```

rc_need="!net"

```

to the /etc/conf.d/net file at the top. Rebooted, and everything came up fine.

----------

