systemd-networkd does not configure eth* devices on boot (since 243 onwards) #15445
Labels
Comments
|
Do you have a LinkLocal address in the interface or have you disabled ipv6 ? Please paste the output of |
|
I am not able to reproduce this in latest version that is 245. |
|
Hi, ipv6 is enabled. Output of
Output of
|
|
Can you reproduce this in 245 ? |
|
Sorry, second output was from v245. As you can see, address for eth1 is missing. |
|
Yes but Is the debug logs from 242 the address is getting set and I don't see it's dropping . Can you paste the logs of 245. |
|
Log is already in the first post. Sorry, the formatting was broken. I've fixed it. These lines from your last comment are missing this output. |
|
242 logs And in 245 logs, it seems networkd not able read the .network matching file. |
|
I've called the file vlan0.network because the interface eth1 will be part of a vlan between several servers. |
|
I've called the following on the running system (245): Result: Corresponding log It seems strange to me, that the file could be found then. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
yuwata
added
the
needs-reporter-feedback ❓
|
I marked the part of discussion about file permissions as resolved — the files are readable.
I think you were thinking about a container. This is a VM, and /sys should be readable. OK, so for some reason networkd is not matching the interface with .network file. According to the With 242 there is:
but with 245:
And in fact, networkctl shows:
So systemd-networkd does nothing with the link because for whatever reason it thinks udev is not done with the link and the link is in pending state. But then when you reconfigure the link, it is picked up correctly, which suggests that udev did initialize the device, but that networkd didn't pick up on this. It might be a networkd problem, but it might also be udevd problem. @lepokle can you attach also logs from udevd (i.e. turn on debug logging for udevd too)? Maybe something like |
|
I have a similar (the same?) problem and tried to analyse it. On an apple powerbook there are two network interfaces, one cabled and one wireless. They are recognized as eth0 and eth1. Both names are now saved in To solve this problem, I renamed eth1 in wlan0 on |
|
Thanks to the comments from @keszybz and @eppesuig I've found out that there seems to be a naming conflict between udevd and systemd-networkd. Log output from After setting I've no idea why this behaviour changed with version 243 onwards, but at least for me the problem has been solved now. |
|
Hello, I experienced the same situation after adding a 4x1GB Intel 82571EB/82571GB card on Ubuntu 20.04.2 all updated on a DL360G6 (systemd v 245.4-4ubuntu3.4). There are no firmware updates for this card. two (eth2, eth3) of the four ports showed up as pending under networkctl. Configuring them with netplan did not solve the issue. They didn't come up until I added a IP address manually via
so netplan seemed be be ignored? regular errors in /var/log/syslog: Errors when trying So I started to rename the interfaces with: and reloaded udev rules: then systemctl restart systemd-networkd-wait-online didn't throw any error any more. However, upon next reboot, a previously renamed, but not configured ethernet port (ens2f1) suddenly showed up as eth1, and was giving errors. so I ended up renaming all unconfigured ethernet ports via udev rules, and now after reboot all is fine: Hopefully I can help somebody solve this quicker. As this is a production server, I was very hesitant doing any quick changes. |
keszybz
removed
the
needs-reporter-feedback ❓
Closing hence. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
use at least version 243
create two files for the interfaces
reboot
Notes
The system is a clean basic system without any special software
It is a virtual server driven by KVM located at a popular German hoster
Installing v242 without any other changes solves the problem.
I've tried settings like
--any,--timeoutand-i eth0for/usr/lib/systemd/system/systemd-networkd-wait-online.servicewithout successOther issues that seems to be related unconnected ethernet interface stuck in 'configuring' state #13793, eth network stuck at routable (configuring) #8686 and Network interface stuck in state "configuring" on a VM with two NICs, DHCP, and the secondary NIC configured with #9289 are solved or are not the same/use a different version/have other suggestions that did not work
This is the log with version v242, containing lines that the state changes
The text was updated successfully, but these errors were encountered: