Bug 1733674 - networkd doesn't manage network devices during boot
Summary: networkd doesn't manage network devices during boot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-27 07:44 UTC by Georg Sauthoff
Modified: 2019-07-27 09:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-27 09:16:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Georg Sauthoff 2019-07-27 07:44:33 UTC
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'.

Comment 1 Zbigniew Jędrzejewski-Szmek 2019-07-27 09:11:53 UTC
Please attach the boot log (journalctl -b -u systemd-networkd -u systemd-udevd).

Comment 2 Georg Sauthoff 2019-07-27 09:16:02 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.