Home / ubuntu / Questions / 1019146
In Process
Thomas Aichinger
Asked: 2018-03-26 12:13:09 +0800 CST

Netplan does not apply at startup

  • 772

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?

networking systemd netplan

11 Answers

  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 :)

    • 9

  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.

    • 6

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

    • 2

  4. With ubuntu 18.04, netplan was also quite new for me, I followed a guide to create the /etc/netplan/01-netcfg.yaml file and run sudo netplan apply and like you, at ever reboot the connectivity was gone.

    Manually running sudo netplan apply made it work again. But that was annoying.

    In my case the solution was to edit /etc/network/interfaces and comment all the enp0** stanzas (check how they are called in your system).

    Then reboot.

    Basically the old configuration in /etc/nwtwork/interfaces was conflicting with netplan.

    • 1

  5. 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

    • 1

  6. Everything in the /etc/netplan file is generated by the cloud-init stuff (technical term I know)

    Edit /etc/cloud/cloud.cfg/50-curtin-networking.cfg the same as you were editing the /etc/netplan/*.yaml file.

    Then run

    cloud-init clean
cloud-init init
sudo netplan apply

    I've given up on the wifi stuff with netplan, and just went back to ifupdown. Good luck to anyone trying to do this with netplan as I've read that Ubuntu really screwed up on 18.04 when they didn't completely trash ifupdown and didn't full support cloud-init. :( Maybe things will be better in 19.04. Hope the info I've given above helps someone.

    • 1

  7. I fixed this problem by inserting

    @reboot /usr/sbin/netplan apply

    into the crontab of root. Not the real solution for the problem, but a workaround that fixed it.

    • 0

  8. I had an issue where I needed to retrigger the events. Essentially netplan did all config right but networkd ignored it. Replugging the devices as "netplan apply" would do fixed it.

    So for some the solution might be to do like

    $ echo virtio0 | sudo tee /sys/bus/virtio/drivers/virtio_net/virtio0/driver/unbind
$ echo virtio0 | sudo tee /sys/bus/virtio/drivers/virtio_net/bind
(or other devices / drivers in your case)

    Maybe this helps some looking for this issue.

    Since I think this is actually a bug I filed this bug about it.

    • 0

  9. Since this is an ongoing issue I have another approach to solve this issue:

    Create a systemd timer and apply network stettings after boot.

    Here is the script: check_network. You need to replace the interface ens32 with yours.

    #!/bin/bash
#
CMD="$(ip address | egrep -c "^[\s\t]*inet .* ens32$")"
if [ ${CMD} -eq "0" ]
then
   echo "check network not configured, configuring now..." | systemd-cat -p info
   netplan apply
else
   echo "check network ok" | systemd-cat -p info
fi

    This is the service unit check_network.service

    [Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

    And this is the systemd timer check_network.timer called 30 sec after boot and then every hour

    [Unit]
Description=check_network timer

[Timer]
OnBootSec=30s
OnUnitActiveSec=3600s
Persistent=true
Unit=check_network.service

[Install]
WantedBy=timers.target

    Copy the check_network to /root/jobs

    Copy the check_network.service to /etc/systemd/system

    Copy the check_network.timer to /etc/systemd/system

    And then enable service and timer

    systemctl enable check_network.service
systemctl enable check_network.timer
    • 0

  10. netplan user on 18.04.1 Assumption that the netplan config is read at networkd restart - this in itself was a bit of a problem because there are like 10 different network services that systemctl knows. None of them brought the desired result so I resorted to rebooting the whole machine. To no avail. Eventually I did found out that 'netplan apply' does help here not only in applying but also indicating syntax faults. So after change it seems that you have to do netplan apply and then you are done. This is not described in manual unless I missed it so I include this here for other poor little worms like me.

    • 0