[Bug 1775566] Re: networkd not applying config - missing events?

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1775566

Title:
  networkd not applying config - missing events?

Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  TL;DR:
  - networkd config written by netplan
  - it seems we can eliminate netplan from this and still have the issue
  - networkd seems to miss the event of the devices and therefore consider them unmanaged
  - rebinding them makes it work
  - the way to trigger this I found so far are q35 KVM guests (PCIe), but 
    there might be more

  ---

  I miss some hidden trigger of "netplan apply" to understand the
  following case.

  I have kvm guests, you can spawn your own one to reproduce via:
   $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=bionic label=daily
   $ uvt-kvm create --password ubuntu bionic-netplan arch=amd64 release=bionic label=daily

  So far all is good, but I wanted to run on q35 type guests (that means PCIe instead of PCI) based and more modern. To do so:
  1. shut down your guest
  2. run virsh edit bionic-netplan
  2.1 replace pc-i440fx-bionic -> pc-q35-bionic
  2.2 replace pci-root with pcie-root
  2.3 replace piix3-uhci -> piix4-uhci
  3. start the guest again
     virsh start bionic-netplan

  It won't get network connection, this is where I started debugging.
  I thought the devices might be wrong now or anything like it, but it is more puzzling.

  First I realized that the device names changed from ens3 -> enp0s3 (the kernel naming).
  So I thought this entry might have a problem:
       ethernets:
          ens3:
              dhcp4: true
              match:
                  macaddress: 52:54:00:68:4b:62

  I tried to name these enp0s3 to match,but it didn't matter and also according to the netplan man page:
     If there are match: rules, then the ID field is a purely opaque name which is only being used
     for references from definitions of compound devices in the config

  And I found it works just fine when I run "sudo netplan apply".

  This was odd, so to summarize up to here:
  - PCIe based virt guest
  - netplan egenrated config not working after (re)boot
  - "netplan apply" makes it working

  I disabled any cloud init things as recommended by the comment
    /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
    network: {config: disabled}
  So that I can rely on my netplan yaml to stay as is.
  I tried various things but so far can't find what magic "netplan apply" does which is missing to my boot.

  I checked after reboot the devices are considered unmanaged by networkctl
  $ networkctl list
  IDX LINK             TYPE               OPERATIONAL SETUP
    1 lo               loopback           carrier     unmanaged
    2 enp0s3           ether              off         unmanaged

  But the config was generated:
  $ ll /run/systemd/network/
  total 32
  drwxr-xr-x  2 root root 200 Jun  7 09:02 ./
  drwxr-xr-x 22 root root 500 Jun  7 09:02 ../
  -rw-r--r--  1 root root  69 Jun  7 09:02 10-netplan-enp0s3.link
  -rw-r--r--  1 root root 104 Jun  7 09:02 10-netplan-enp0s3.network

  I checked the log and saw that apply restarts networkd.
  So I thought might just restart networkd, so I ran
   $ sudo systemctl restart systemd-networkd.service
  But things stayed as-is without the config being picked up.

  With some nice discussion and help on IRC I also tried to disable netplan and check if this is networkd only.
  # make this static networkd
  $ sudo cp /run/systemd/network/10-netplan-enp0s* /etc/systemd/network/
  # no netplan config
  $ sudo mv /etc/netplan/* /root

  That was supposed to show if networkd itself (or its config files) had issues.
  And with that it still did not work, so is the error in networkd instead?
  If so what magic thing does "netplan apply" do to fix it?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1775566/+subscriptions