Bug 1733674
| Summary: | networkd doesn't manage network devices during boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Georg Sauthoff <fedora> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 29 | CC: | lnykryn, msekleta, ssahani, s, systemd-maint, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-27 09:16:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Please attach the boot log (journalctl -b -u systemd-networkd -u systemd-udevd). Hm, I was confused by `systemctl status systemd-networkd` reporting: Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: disabled) Turns out it wasn't really enabled and a following `systemctl enable systemd-networkd` did create some links: Created symlink /etc/systemd/system/multi-user.target.wants/systemd-networkd.service → /usr/lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/sockets.target.wants/systemd-networkd.socket → /usr/lib/systemd/system/systemd-networkd.socket. Created symlink /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service → /usr/lib/systemd/system/systemd-networkd-wait-online.service. Meaning that it wasn't really enabled, before. The 'link is not managed by us' apparently come from the dhcp6 client (which is enabled because of RAs) which arguably kind of misleading. I saw them during boot because networkd was actually enabled in the initramfs. |
Description of problem: After switching from NetworkManager to networkd, networkd still claims `link is not managed by us` for all devices. Thus, the system ends up without any connectivity. Curiously, manually starting `systemd-networkd` again after boot all links are then managed and the connected one is configured. Version-Release number of selected component (if applicable): systemd-239-12.git8bca462.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. systemctl mask NetworkManager 2. systemctl enable systemd-networkd 3. cat /etc/systemd/network/20-wired.network [Match] Name=en* [Network] DHCP=ipv4 4. shutdown -r now Actual results: # networkctl list [..] unmanaged [... for all links] # systemctl status systemd-networkd [...] eth1: Interface name change detected, eth0 has been renamed to eno1. [...] eno1: Link is not managed by us [... similar for other links ..] Stopping Network Service... Stopped Network Service. Expected results: Links are actually managed by networkd as part of the boot process. Additional info: After boot an explicit: # systemctl start systemd-networkd # systemctl status [... active (running) ...] eno1: DHCPv4 address ... eno1: Configured [..] # networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eno1 ether routable configured 3 eno2 ether no-carrier configuring 4 eno3 ether no-carrier configuring 5 eno4 ether no-carrier configuring 5 links listed. [note that only eno1 is connected] I've also tried removing NetworkManager (with dnf), but networkd still claims that 'link is not managed by us'.