netplan set-name option not working on freshly installed Ubuntu server 18.04

Bug #1768827 reported by Nicorac
120
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Netplan
Confirmed
Undecided
Unassigned

Bug Description

=== bug description ===

Need to change network card kernel assigned name (enp0s15) to a more meaningful one (eth_lan).
Using set-name option in netplan config (matching device by MAC address) does not work.

=== versions ===

# lsb_release -rd
Description: Ubuntu 18.04 LTS
Release: 18.04

# uname -a
Linux server 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# apt-cache policy netplan
netplan:
  Installed: (none)
  Candidate: 1.10.1-5build1
  Version table:
     1.10.1-5build1 500
        500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

=== test case ===

Set netplan configuration like this:

# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    # original network card name: enp0s15
    id0:
      match:
        macaddress: xx:xx:xx:xx:xx:xx
      set-name: eth_lan
      addresses:
        - 10.0.0.10/24
      gateway4: 10.0.0.254
      nameservers:
        addresses: [ 8.8.8.8, 8.8.4.4 ]

=== expected behavior ===

Network card renamed to "eth_lan" and assigned the IP address 10.0.0.10

=== actual behavior ===

This is network state after reboot:

# ip -4 address
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
2: enp0s15: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

As you can see, after reboot the interface is still named enp0s15 and was not assigned the static IP address.

=== workaround ===

If I manually run "netplan apply" just after reboot, the device is renamed and configuration is applied correctly:

# ip -4 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.0.0.10/24 brd 10.0.0.255 scope global eth_lan
       valid_lft forever preferred_lft forever

Tags: sts
Nicorac (nicorac)
description: updated
Revision history for this message
Bram Matthys (syzop) wrote :

I have the same issue as the reporter. Interface does not rename and does not come up automatically after reboot, need to run 'netplan apply'.
I use interface renaming on basically all my virtual machines so it's immediately clear what is connected to what network/vlan. I'm now back to ifupdown together with udev renaming like I've been using for years now, which is fine for me but you probably want to get this fixed :)

** netplan config **

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    inet1:
      match:
        macaddress: xx:xx:xx:xx:xx:xx
      set-name: inet1
      addresses: [ xxxxx/28 ]
      gateway4: xxxxxx
      nameservers:
          search: [ xxxxx ]
          addresses:
              - "xxxx"
              - "xxxx"

** And tried this as well (same behavior) **

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      match:
        macaddress: xx:xx:xx:xx:xx:xx
      set-name: inet1
    inet1:
      addresses: [ xxxxx/28 ]
      gateway4: xxxxxx
      nameservers:
          search: [ xxxxx ]
          addresses:
              - "xxxx"
              - "xxxx"

Revision history for this message
Ryan Harper (raharper) wrote :

Hello,

Thank you for the bug report.

Would you be able to apply some debugging and report back:

% sudo mkdir -p /etc/systemd/system/systemd-networkd.service.d/
% echo -e "[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug" | sudo tee /etc/systemd/system/systemd-networkd.service.d/10-debug.conf
% sudo systemctl daemon-reload

Then, if you could reboot and after the reboot is complete, please capture

% sudo journalctl -b -u systemd-networkd.service

Changed in netplan:
status: New → Incomplete
Revision history for this message
Nicorac (nicorac) wrote :
Download full text (6.0 KiB)

NOTE: I've switched to a freshly installed Ubuntu 18.04 x64 VirtualBox VM, so everyone should be able to reproduce it easily.

Here you are the requested log.
I see a lot of "ignoring file..." at the begin, because of wrong file extension.
Because of that, I'm attaching the content of first ignored one too (/run/systemd/network/10-netplan-id0.network)

----------------------------------------------------------------
% sudo journalctl -b -u systemd-networkd.service
-- Logs begin at Thu 2018-02-22 14:32:55 CET, end at Wed 2018-05-09 11:18:49 CEST. --
Feb 22 14:43:51 srvaddc systemd[1]: Starting Network Service...
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Failed to connect to bus, trying again in 5s: No such file or directory
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory
Feb 22 14:43:51 srvaddc systemd-networkd[305]: timestamp of '/etc/systemd/network' changed
Feb 22 14:43:51 srvaddc systemd-networkd[305]: timestamp of '/run/systemd/network' changed
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /run/systemd/network/10-netplan-id0.network, because it's not a regular file with suffix .netdev.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /run/systemd/network/10-netplan-id0.link, because it's not a regular file with suffix .netdev.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /run/systemd/network/10-netplan-id0.link, because it's not a regular file with suffix .network.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network.
Feb 22 14:43:51 srvaddc systemd-networkd[305]: enp0s3: Flags change: +MULTICAST +BROADCAST
Feb 22 14:43:51 srvaddc systemd-networkd[305]: enp0s3: Link 2 added
Feb 22 14:43:51 srvaddc systemd-networkd[305]: enp0s3: udev initialized link
Feb 22 14:43:51 srvaddc systemd-networkd[305]: enp0s3: Saved original MTU: 1500
Feb 22 14:43:51 srvaddc systemd-networkd[305]: lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING
Feb 22 14:43:51 srvaddc systemd-networkd[305]: lo: Link 1 added
Feb 22 14:43:51 srvaddc systemd-networkd[305]: lo: udev initialized link
Feb 22 14:43:51 srvaddc systemd-networkd[305]: lo: Saved original MTU: 0
Feb 22 14:43:51 srvaddc systemd-networkd[305]: lo: Adding address: ::1/128 (valid forever)
Feb 22 14:43:51 srvaddc systemd-networkd[305]: lo: Adding address: 127.0.0.1/8 (valid forever)
Feb 22 14:43:51 srvaddc systemd-networkd[305]: rtnl: received address with invalid family 129, ignoring.
Feb 22 1...

Read more...

Revision history for this message
Ryan Harper (raharper) wrote :

Can you try:

% sudo update-initramfs -u
% reboot

And see if the name is applied afterwards?

Revision history for this message
Nicorac (nicorac) wrote :

Yes I did, not working.
After reboot the network card still has the kernel name and no assigned IP.
Running 'netplan apply' fixes it.

Revision history for this message
Nicorac (nicorac) wrote :

I have this bug both on a physical server (Intel ethernet card) and on a VirtualBox VM.
I also reinstalled a fresh Ubuntu 18.04 x64 Server VM (selecting the "Minimal server" setup mode) and it has the same bad behavior.

NOTE: Netplan option "wakeonlan: g" is not working too, maybe it's related to this bug.
I'll wait for this bug to be fixed and check if the wakeonlan bug is fixed too, otherwise I'll open another one.

Nicorac (nicorac)
Changed in netplan:
status: Incomplete → Confirmed
Revision history for this message
Ryan Harper (raharper) wrote :

We've sorted the issue with rename here:

https://bugs.launchpad.net/netplan/+bug/1770082

I'll end up duping one of these bugs to the other.

Note that mtu/wakeonlan issues likely fallout from the name since the .network and files have a [Match] section that includes the intended name. If that's not set properly due to the bug then those settings may not work as well.

If you end up using the workaround in the other bug and still find that wakeonlan is not working, please file a new bug for that particular issue.

Revision history for this message
Nicorac (nicorac) wrote :
Download full text (4.0 KiB)

Version 0.36.3 fixed set-name bug but now IPs are not assigned anymore, both static and dynamic.
Running "netplan apply" just after boot fixes everything.

Steps to reproduce:
- trashed old VM and reinstalled a new Ubuntu Server 18.04 in VBox (no Guest Additions).
- apt update && apt-dist-upgrade
- enabled -proposed repo and updated both nplan/bionic-proposed and netplan.ion/bionic-proposed packages to 0.36.3

*************
Configuration
*************
# dpkg -s netplan.io
Package: netplan.io
Status: install ok installed
Priority: important
Section: net
Architecture: amd64
Version: 0.36.3

# cat /etc/netplan/01-netcfg.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    id0:
      match:
        macaddress: 08:00:27:6b:d8:91
      set-name: eth_static
      addresses: [ 1.2.3.4/16 ]
      gateway4: 5.6.7.8
    id1:
      match:
        macaddress: 08:00:27:23:68:f5
      set-name: eth_dhcp
      dhcp4: true

*************************
*** just after boot ***
*************************
# ifconfig -a
eth_dhcp: flags=4098<BROADCAST,MULTICAST> mtu 1500
        ether 08:00:27:23:68:f5 txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth_static: flags=4098<BROADCAST,MULTICAST> mtu 1500
        ether 08:00:27:6b:d8:91 txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        RX packets 2 bytes 78 (78.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 2 bytes 78 (78.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth_static ether off unmanaged
  3 eth_dhcp ether off unmanaged

3 links listed.

***************************************
*** after running "netplan apply" ***
***************************************
# ifconfig -a
eth_dhcp: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.0.0.42 netmask 255.255.0.0 broadcast 10.0.255.255
        inet6 fe80::a00:27ff:fe23:68f5 prefixlen 64 scopeid 0x20<link>
        ether 08:00:27:23:68:f5 txqueuelen 1000 (Ethernet)
        RX packets 5709 bytes 688255 (688.2 KB)
        RX errors 0 dropped 1065 overruns 0 frame 0
        TX packets 112 bytes 16149 (16.1 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth_static: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 1.2.3.4 netmask 255.255.0.0 broadcast 1.2.255.255
        inet6 fe80::a00:27ff:fe6b:d891 prefixlen 64 scopeid 0x20<link>
        ether 08:00:27:6b:d8:91 txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        ...

Read more...

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Could you please attach the contents of the files in /run/systemd/network/ before you run 'netplan apply'? We need to see what was generated at boot that makes it such that networkd doesn't want to manage these devices.

Revision history for this message
Nicorac (nicorac) wrote :

Of course.
This is the status just after the boot:

*********************************************************
# ifconfig -a
eth_dhcp: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.0.0.57 netmask 255.255.0.0 broadcast 10.0.255.255
        inet6 fe80::a00:27ff:fe23:68f5 prefixlen 64 scopeid 0x20<link>
        ether 08:00:27:23:68:f5 txqueuelen 1000 (Ethernet)
        RX packets 10493 bytes 1244056 (1.2 MB)
        RX errors 0 dropped 829 overruns 0 frame 0
        TX packets 105 bytes 22485 (22.4 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth_static: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 1.2.3.4 netmask 255.255.0.0 broadcast 1.2.255.255
        inet6 fe80::a00:27ff:fe6b:d891 prefixlen 64 scopeid 0x20<link>
        ether 08:00:27:6b:d8:91 txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 15 bytes 1146 (1.1 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        RX packets 342 bytes 20654 (20.6 KB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 342 bytes 20654 (20.6 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

*********************************************************
# ll /run/systemd/network/
total 16
drwxr-xr-x 2 root root 120 Jul 12 08:33 ./
drwxr-xr-x 22 root root 520 Jul 12 08:34 ../
-rw-r--r-- 1 root root 75 Jul 12 08:33 10-netplan-id0.link
-rw-r--r-- 1 root root 99 Jul 12 08:33 10-netplan-id0.network
-rw-r--r-- 1 root root 73 Jul 12 08:33 10-netplan-id1.link
-rw-r--r-- 1 root root 108 Jul 12 08:33 10-netplan-id1.network

*********************************************************
# cat 10-netplan-id0.link
[Match]
MACAddress=08:00:27:6b:d8:91

[Link]
Name=eth_static
WakeOnLan=off

*********************************************************
# cat 10-netplan-id0.network
[Match]
MACAddress=08:00:27:6b:d8:91
Name=eth_static

[Network]
Address=1.2.3.4/16
Gateway=5.6.7.8

*********************************************************
# cat 10-netplan-id1.link
[Match]
MACAddress=08:00:27:23:68:f5

[Link]
Name=eth_dhcp
WakeOnLan=off

*********************************************************
# cat 10-netplan-id1.network
[Match]
MACAddress=08:00:27:23:68:f5
Name=eth_dhcp

[Network]
DHCP=ipv4

[DHCP]
UseMTU=true
RouteMetric=100

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

In that output, eth_dhcp has an IP address. Was that really after reboot, but BEFORE running 'netplan apply'? This is very important, as we really need to see what the state is after booting if you don't do any workarounds or commands. If you have any changes on the system, those should be removed too. Best is to reproduce this on another system which would be a brand new install...

Revision history for this message
Nicorac (nicorac) wrote :

Yes it seems wrong, sorry.
I don't remember what it should read like (more than 2 months have passed).

Anyway I'm still following bug 1770082 here:
https://bugs.launchpad.net/netplan/+bug/1770082

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Could it be that you are booting with a remote root filesystem, so with ip= set on the kernel command-line? This would usually show up as having YAML files in /run/netplan, and those can interfere with the renaming.

Otherwise, deploying systems with maas leads to network interfaces being renamed forcefully at boot, that's files in /etc/cloud/cloud.cfg.d/50-curtin-networking.conf

Revision history for this message
Nicorac (nicorac) wrote :

No it's not.
It's a plain vanilla Ubuntu Server 18.04.1 x86 installed in a VirtualBox VM.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

So, is the issue that things are not renamed or that you have no IP at boot? If both, please make sure *we have separate bugs for each*.

Also, please include the output of 'networkctl'.

Revision history for this message
Francois Lafont (francois-lafont) wrote :
Download full text (13.6 KiB)

Hi @all,

I have the same problem which has been reported by nicorac, ie :

1. the interface is well renamed...
2. but the interface has no IP address after the reboot.

Here is some paste of configs, logs etc.:

*********************************************************
# It's a updated Ubuntu Bionic, fresh installed.
root@bionic-vbox:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

root@bionic-vbox:~# dpkg -l systemd | grep ^ii
ii systemd 237-3ubuntu10.9 amd64 system and service manager

root@bionic-vbox:~# dpkg -l netplan.io | grep ^ii
ii netplan.io 0.40.1~18.04.3 amd64 YAML network configuration abstraction for various backends
*********************************************************

Here my simple netplan configuration:

*********************************************************
root@bionic-vbox:~# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      match:
        macaddress: '08:00:27:bb:bb:0d'
      set-name: eth0
      addresses: ['10.111.222.13/24']
      gateway4: '10.111.222.1'
      nameservers:
        addresses: ['10.111.222.1']
        search: ['virt.priv']
*********************************************************

After the reboot, the interface is well renamed but without IP address:

*********************************************************
# Just after the reboot.

root@bionic-vbox:~# ip a
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: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:bb:bb:0d brd ff:ff:ff:ff:ff:ff

root@bionic-vbox:~# journalctl -b -u systemd-networkd.service
-- Logs begin at Tue 2018-10-16 15:04:45 CEST, end at Mon 2018-12-10 16:31:22 CET. --
Dec 10 16:31:17 bionic-vbox systemd[1]: Starting Network Service...
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: Bus n/a: changing state UNSET → OPENING
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: Added inotify watch for /run on bus n/a: 2
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: Added inotify watch for /run/dbus on bus n/a: -1
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: Bus n/a: changing state OPENING → WATCH_BIND
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: timestamp of '/etc/systemd/network' changed
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: timestamp of '/run/systemd/network' changed
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: Ignoring /run/systemd/network/10-netplan-enp0s3.network, because it's not a regular file with suffix .netdev.
Dec 10 16:31:18 bionic-vbox systemd-networkd[240]: I...

Revision history for this message
Francois Lafont (francois-lafont) wrote :

Sorry, I have made an error of copy and paste in my previous message concerning the files:

- /run/systemd/network/10-netplan-enp0s3.network
- /run/systemd/network/10-netplan-enp0s3.link

Here is the correct content just after the reboot:

******************************************************
root@bionic-vbox:~# cat /run/systemd/network/10-netplan-enp0s3.network
[Match]
MACAddress=08:00:27:bb:bb:0d
Name=eth0

[Network]
LinkLocalAddressing=ipv6
Address=10.111.222.13/24
Gateway=10.111.222.1
DNS=10.111.222.1
Domains=virt.priv

root@bionic-vbox:~# cat /run/systemd/network/10-netplan-enp0s3.link
[Match]
MACAddress=08:00:27:bb:bb:0d

[Link]
Name=eth0
WakeOnLan=off
******************************************************

Revision history for this message
Tom Sillence (tomsillence) wrote :

I'm seeing exactly the same behaviour as above, on a fresh VM as well as a physical server. No special configuration is needed to see this bug, just attempt to use set-name and reboot. The rename happens but the device is left unconfigured til "netplan apply" or "service systemd-networkd restart" is run.

* It doesn't matter whether you match on MAC address or driver.

* Booting with net.ifnames=0 (as mentioned as a workaround to a previous similar bug) has no effect.

* I can confirm that networkd "sees" the rename (but then takes no action to configure the device):

Feb 27 10:10:14 bidev systemd-networkd[252]: enp0s3: Interface name change detected, enp0s3 has been renamed to meaningfulname.

* This still happens with the latest netplan (master 8b779f9) from github.

The following hack works, which may tell you something about the order in which things are happening:

********************************************************
toms@bidev:~$ cat /etc/systemd/system/fixnetplan.service
[Unit]
Description=Fix netplan (re-apply)
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/netplan apply
********************************************************

Lastly, my very simple config:
********************************************************
toms@bidev:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      match:
        driver: e1000
      set-name: meaningfulname
      dhcp4: yes
*******************************************************

Revision history for this message
Paul Rouse (paul.rouse) wrote :

I am seeing the same problem, too: the interface can be renamed using set-name,
but then static IP addresses are not assigned during boot. This is on 18.04
server installs, fully updated, with netplan configurations which

* Use the networkd renderer
* Rename the interface
* Apply static IP addressing

However, I have found a work-around which seems to be reliable - so far on
three separate machines:

1. netplan apply
2. cp /run/systemd/network/*.link /etc/systemd/network/
3. update-initramfs -u
4. reboot # all is well now

The point is that it forces the renaming to be applied early, in the initramfs,
and this seems to be sufficient for the interface to be configured and brought
up during boot. I have verified that the renaming happens early now - and did
not before this work around - by using `break=mount` on the kernel command
line.

This suggest to me that there is a timing issue or dependency which needs to
be resolved to address this problem fully.

Revision history for this message
Klaus Brueningen (brueningen) wrote :

I had the same issue and found another solution. I know it sounds a bit weired but it works:

The interface definition with set-name must not be the last entry in the file.

If there is another interface configured after the one with the set-name option that has not also a set-name, then it works for the first interface.

What I do now is, I put the "version: 2" line at the end of the file and everything works.

Revision history for this message
Robert Voje (robert-voje-dk) wrote :

I can confirm that Pauls workaround (#19) is working for me too.

My earlier workaround was to add "netplan apply" to the root crontab, but then I missed the early boot logs on my syslog server.

Tested on 18.04 LTS on vmWare.

Klaus's solution did not work for me, but then again, I don't have multiple interfaces.

Revision history for this message
Joachim Wickman (floppe) wrote :

I can also confirm that Pauls workaround (#19) is working for me on a new Xen guest. Had the same issue that interfaces are renamed, but no IPs assigned.

It does work on older Xen guests with same netplan versions though. Anything with recent Ubuntu updates or have I forgot to install something on my new guest?

Revision history for this message
John Stimson (orthonormal) wrote :

I am also experiencing the case where the renaming works, but the interface isn't configured after boot. I am on a freshly installed instance of Kubuntu 18.3.4 on a standalone PC with two ethernet interfaces.

I can cause it to configure the interface with netplan apply after boot. However, that's not a good workaround because named, dhcpd, or both fail to attach to the interface on boot, requiring me to restart those services as well.

Klaus' workaround does not work for me. I am reluctant to try Paul's because I would prefer to work within the netplan framework and hope that this bug is eventually fixed. For now, I will just use the default names, which so far seem not to change from boot to boot.

tags: added: sts
Revision history for this message
Maaike (ekki-a) wrote :

I am also experiencing this on Ubuntu 20.04. Add 'netplan apply' in crontab works, the workarounds of Paul and Klaus did not work on my pc.

Is there a possibility to fix this?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.