12

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?

  • 2
    At boot time, what are the contents of /run/systemd/network and /run/systemd/netif? – slangasek Apr 2 '18 at 20:28
  • This should now be fixed in Bionic with netplan 0.36.3. Could you test it and let us know? – dja Jul 19 '18 at 9:39
  • 2
    I use 18.04 and i am facing the same problem. Do you have any solution ? – gtzinos Aug 13 '18 at 15:48
2

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

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.

  • This is now fixed with netplan 0.36.3 – dja Jul 26 '18 at 4:33
  • This solved it for me on up-to-date Ubuntu 18.04.1 including backports updates proposed and security on 2018-09-17. I disabled the set-name directives for now, didn't try the net.ifnames=0 kernel cmdline. With set-name, the devices were renamed, but not brought up. – TheJJ Sep 17 '18 at 15:20
2

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

  • It should be fixed with netplan 0.36.3 – dja Jul 26 '18 at 4:33
  • Nope, I got it right today – Dario Fumagalli Aug 12 at 10:37
0

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

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.

  • This doesn't answer the question being asked. – Thomas Ward May 17 '18 at 17:22
0

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

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

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.