Netplan does not apply at startup

I installed Ubuntu 17.10 with latest updates on a vmware virtual machine. Netplan does not configure my 2 ethernets.

Here is my /etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    lan:
      match:
        macaddress: 00:12:34:a8:29:e8
      set-name: lan
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 10.10.0.48/24
        - 1701:5740:5000:3301::48/64

    failover:
      match:
        macaddress: 00:45:57:89:27:e8
      set-name: failover
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 17.25.111.30/27
        - 1701:5740:5000:3300::30/64
      gateway4: 17.25.111.1
      gateway6: 1701:5740:5000:3300::1

      nameservers:
        search:
          - example.at
          - intern.example.at
        addresses:
          - 10.10.0.1
          - 1701:5740::66

I switched back to predictable devices like eth0, and after boot all devices are named properly, but not configured.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: lan: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:12:34:a8:29:e8 brd ff:ff:ff:ff:ff:ff
3: failover: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:45:57:89:27:e8 brd ff:ff:ff:ff:ff:ff

After login and fireing systemctl restart systemd-networkd devices are configured. netplan apply also does the job.

I played so much around with systemd-networkd.service and systemd-networkd.timer but nothing helped.

It is quite frustrating set up the network manually after each reboot. Does anyone know how to solve this?

Solution 1:

I have exactly the same issue on Ubuntu 18.04, but R. Pietsch's solution doesn't solve it :(

sudo crontab -e
@reboot /usr/sbin/netplan apply

I also tried to enable the root user, that it's disabled by default on Ubuntu, but no luck.

The only way I have to gain connectivity is to:

1. login into the machine using its own keyboard;
2. type "sudo netplan apply";
3. then I'm finally able to SSH into the machine.

If I don't "sudo netplan apply", I have no connection on the machine. How is it possible to put into a LTS release such a broken piece of software?

I would like to add more details about my scenario, to be useful to other people to recognize the phenomena we are talking about. This is what it was happening in my case:

• I installed Ubuntu 18.04 on my Intel NUC using the netinstall;
• I configured the netplan YAML file to get a static ip address when wireless connected;
• I applied it with "sudo netplan apply";
• I rebooted my NUC;
• I launched a "ping -t " from my Windows machine;
• Once re-started, the NUC showed the LXDE login prompt;
• At that point, the NUC was unreachable according to the ping;
• I logged in, typed "sudo netplan apply" and after few second it became reachable.

I think netplan is a good improvement compared to /etc/network/interfaces, but this behaviour should be fixed as soon as possible :)

UPDATE:

I debugged the issue using the following commands:

$ journalctl --no-pager -lu systemd-networkd
$ networkctl

It seems it was the Network Manager panel in LXDE interfering with it. Even if the connections were displayed as "unmanaged", I un-checked the "Enable Networking" and it seems it fixed the issue.

We can close this one :)

Solution 2:

I think you've hit LP: #1770082 - "systemd-networkd not renaming devices on boot".

Basically, when your system is booting, the network device will come up as eth0/eth1 etc. The order is not predictable, so udev renames the devices to things like ens3 or enp2s0 in the initrd phase of boot. (You should be able to see this by grepping the output of dmesg.)

You have a set-name stanza in your netplan YAML. Later in boot, that set-name generates a renaming rule in a systemd link file, which is read by udev. However, a link file will not cause a device to be renamed if it's already been renamed. In your case then, the device won't be renamed because it's probably been renamed earlier in initrd.

I opened a bug against systemd (issue #9006 - "udev: interface name in link file not applied") about this. I also proposed a change to netplan (PR #31 - "Generate udev rules files to rename devices") that will cause a systemd rules file to be created as well as a link file, as a rules file is honoured even if the device has already been renamed.

As a workaround, try booting with net.ifnames=0 on the kernel command line. For a long term solution, expect my change to netplan to be backported to Bionic and released in the next month or so.

Solution 3:

I've now tried it with Ubuntu 18.04 and I think this bug has been fixed.
It works for me now.

Solution 4:

Ok better answer I fixed it go back to ifupdown until netplan is fixed. sudo apt install ifupdown then configure the interface sudo nano /etc/network/interfaces

auto enp3s0
iface enp3s0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.1
    dns-nameservers 192.168.1.0,8.8.8.8

and whoever implemented this in an LTS server release obviously didnt test it