netplan won't apply config on renamed interface

Bug #1802004 reported by Marcos on 2018-11-06
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
netplan
Undecided
Unassigned

Bug Description

Netplan does not configure interfaces *if* set-name is used.

Config:
root@ubuntu:/etc/netplan# cat 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:
    eth0:
      match:
          macaddress: 08:00:27:f0:97:15
      set-name: eth0
      dhcp4: no
      addresses: [ "192.168.56.2/24" ]
      gateway4: 192.168.56.1

Result after reboot:
ubuntu@ubuntu:~$ ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:f0:97:15 brd ff:ff:ff:ff:ff:ff

ubuntu@ubuntu:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth0 ether off unmanaged

2 links listed.

*After netplan apply*

ubuntu@ubuntu:~$ sudo netplan apply
ubuntu@ubuntu:~$ ip address show dev eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:f0:97:15 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.2/16 brd 192.168.56.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fef0:9715/64 scope link
       valid_lft forever preferred_lft forever

ubuntu@ubuntu:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  3 eth0 ether routable configured

2 links listed.

Attached syslog files for better debugging.

Also, this bug only occurs (in my tests) if the VM was installed with the debian-installer image (ubuntu-18.04-server-amd64.iso). If it was installed from subiquity (ubuntu-18.04-live-server-amd64.iso) it works as expected.

Marcos (markinholiveira) wrote :
Marcos (markinholiveira) wrote :

Added syslog file after running sudo netplan apply...

set-name is used in my config, and it works just fine. This might be driver-specific, or otherwise an issue with carrier detection?

Is see no other reason for things not to work, could there be a race due to renames? There looks to be many different renames on your system, from eth0 to enp0s3 and back. How are these systems deployed? Is it a new, clean install of Ubuntu?

Changed in netplan:
status: New → Incomplete
Alex Tomlins (alex-tomlins) wrote :

I'm seeing the same issue. I can reproduce it with a fresh install using http://cdimage.ubuntu.com/releases/18.04.1/release/ubuntu-18.04.1-server-amd64.iso in a virtualbox VM with all updates applied. I've tested with both the virtio, and Intel PRO/1000 network drivers with the same results.

# ls -l /etc/netplan
-rw-r--r-- 1 root root 360 Nov 9 17:12 01-netcfg.yaml
# 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:
    lan0:
      match:
        macaddress: 08:00:27:3d:1a:a4
      set-name: lan0
      addresses: [10.10.10.99/24]
      gateway4: 10.10.10.1
      nameservers:
        addresses: [10.10.10.1]
# 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: lan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:3d:1a:a4 brd ff:ff:ff:ff:ff:ff
# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 lan0 ether off unmanaged

2 links listed.
# netplan apply
# 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
3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:3d:1a:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.99/24 brd 10.10.10.255 scope global lan0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3d:1aa4/64 scope link
       valid_lft forever preferred_lft forever
# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  3 lan0 ether routable configured

2 links listed.

I've noticed another oddity - it seems to occasionally work correctly after a soft reboot of the VM. It seems to always exhibits the above behaviour after a cold boot of the VM.

Marcos (markinholiveira) wrote :

@Mathieu: Have you tried on a server installed with ubuntu-18.04-server-amd64.iso??? And with netplan.io:0.40.1~18.04.2 package installed?? Because renames were not working properly before 0.40.1~18.04.2 and after that, renames were ok (both on boot and on netplan apply) but no other configs are applied on boot, just on netplan apply....

Marcos (markinholiveira) wrote :

@Mathieu: Also, isn't the first rename (from eth0 to enp0s3) done by systemd? Because it happens even with a clean install of Ubuntu, without further netplan configurations...

William Foster (williamfoster) wrote :
Download full text (5.0 KiB)

I can definitely confirm that there is an issue with using the 'set-name' directive as just adding that to the config file gives me three different results across four systems. One of the outcomes is identical to the reported issue.

All of these are on installs of Ubuntu Server 18.04.1 using the traditional installer (not Subiquity) image ubuntu-18.04.1-server-amd64.iso. I am testing this using the exact same netplan configuration on each system with the following results:
 - One system does not get an IP after boot until 'netplan apply' is run.
 - One system does not get an IP at all, even after running 'netplan apply'.
 - Two systems are working just fine.

Two of these are physical systems and are running netplan.io 0.36.3 that are connected to the same switch, the other two are VMware VMs on the same host running netplan.io 0.40.1~18.04.2. All systems are using the same DHCP server.

Here is the config I am using on each system:

network:
    version: 2
    renderer: networkd
    ethernets:
        testnet:
            match:
                macaddress: XX:XX:XX:XX:XX:XX
            dhcp4: yes
            dhcp-identifier: mac
            set-name: testnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System-01 (No IP after boot) - netplan.io 0.36.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is an industrial embedded system with 2 Intel i210 interfaces. One interface will be configured for DHCP internet and the other will eventually be a static IP direct connected to an industrial gateway, but right now I am only configuring the first interface.

What happened is I had just completed a fresh install of 18.04.1 with the traditional installer and then changed the configuration for the LAN interface to use 'set-name'; then after rebooting no IP was given to the interface. This was resolved by running 'netplan apply', but after every reboot the issue repeats. If I remove the 'set-name' line from the configuration then the interface gets an IP immediately after reboot without me having to run 'netplan apply'.

This seems to be identical to the issue reported in this ticket.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System 02 (Works fine) - netplan.io 0.36.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I then tested this configuration on a different system on my desk that I installed 18.04.1 on last week using the traditional installer. This is a PC104 SBC that is the same chipset as System-01, but with only one network interface (also Intel i210) and some extra I/O.

This system has no issues after rebooting, it both renames the interface and gets an IP during boot.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System-03 (No IP at all) - netplan.io 0.40.1~18.04.2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As another test I used the above configuration on a VMware VM I setup a few weeks ago with the traditional installer on our ESXI 6.0 server. After rebooting it exhibited the same issues as the System-01, no IP on the interface after booting up. But this time when I ran 'netplan apply' the interface still wouldn't get an IP. No error messages are displayed or shown in th...

Read more...

Download full text (6.2 KiB)

Hello,

For any system that's failing collecting some additional debugging
information may help

1) enable systemd-networkd debugging

% mkdir /etc/systemd/system/systemd-networkd.service.d/
% echo -e "[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug" >
/etc/systemd/system/systemd-networkd.service.d/10-debug.conf

After rebooting collect and attach:

a) /run/systemd/network/*
b) journalctl -b
c) networkctl status --all

On Wed, Nov 21, 2018 at 8:10 PM William Foster
<email address hidden> wrote:
>
> I can definitely confirm that there is an issue with using the 'set-
> name' directive as just adding that to the config file gives me three
> different results across four systems. One of the outcomes is identical
> to the reported issue.
>
> All of these are on installs of Ubuntu Server 18.04.1 using the traditional installer (not Subiquity) image ubuntu-18.04.1-server-amd64.iso. I am testing this using the exact same netplan configuration on each system with the following results:
> - One system does not get an IP after boot until 'netplan apply' is run.
> - One system does not get an IP at all, even after running 'netplan apply'.
> - Two systems are working just fine.
>
> Two of these are physical systems and are running netplan.io 0.36.3 that are connected to the same switch, the other two are VMware VMs on the same host running netplan.io 0.40.1~18.04.2. All systems are using the same DHCP server.
>
> Here is the config I am using on each system:
>
> network:
> version: 2
> renderer: networkd
> ethernets:
> testnet:
> match:
> macaddress: XX:XX:XX:XX:XX:XX
> dhcp4: yes
> dhcp-identifier: mac
> set-name: testnet
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> System-01 (No IP after boot) - netplan.io 0.36.3
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This is an industrial embedded system with 2 Intel i210 interfaces. One
> interface will be configured for DHCP internet and the other will
> eventually be a static IP direct connected to an industrial gateway, but
> right now I am only configuring the first interface.
>
> What happened is I had just completed a fresh install of 18.04.1 with
> the traditional installer and then changed the configuration for the LAN
> interface to use 'set-name'; then after rebooting no IP was given to the
> interface. This was resolved by running 'netplan apply', but after
> every reboot the issue repeats. If I remove the 'set-name' line from
> the configuration then the interface gets an IP immediately after reboot
> without me having to run 'netplan apply'.
>
> This seems to be identical to the issue reported in this ticket.
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> System 02 (Works fine) - netplan.io 0.36.3
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I then tested this configuration on a different system on my desk that I
> installed 18.04.1 on last week using the traditional installer. This is
> a PC104 SBC that is the same chipset as System-01, but with only one
> network interface (also Intel i210) and some extra I/O.
>
> This system has no issues after rebooting, it both re...

Read more...

Marcos (markinholiveira) wrote :

@Ryan: Attached the additional info.

@Mathieu: I confirmed that the first rename comes from systemd... So not so weird. Maybe netplan could overcome that to do just one rename, but if not, every interface that uses set-name must have at least two renames.

Ryan Harper (raharper) wrote :

On Mon, Nov 26, 2018 at 12:06 PM Marcos <email address hidden> wrote:
>
> @Ryan: Attached the additional info.
>
> @Mathieu: I confirmed that the first rename comes from systemd... So not
> so weird. Maybe netplan could overcome that to do just one rename, but
> if not, every interface that uses set-name must have at least two
> renames.
>
> ** Attachment added: "Additional logs"
> https://bugs.launchpad.net/netplan/+bug/1802004/+attachment/5216555/+files/debug.zip

Thanks. It appears that the kernel does the initial rename (as
expected) to persistent names.
And then when networkd comes online, the existing
/run/network/10-netplan-eth0.network files
are not considered for "eth0" which is currently named enp0s3; this is
due to the Name=eth0
in the [Match] section of the .network file.

What's unclear is why udev did not enforce the .link files. We've had
a bug open for this...

https://bugs.launchpad.net/netplan/+bug/1770082
https://github.com/systemd/systemd/issues/9006

This is supposedly fixed in systemd-239, and this system is running
systemd-237 which means
that the rename in the .link file is going to be ignored due to
systemd already renaming the
interface once (eth0 -> enp0s3).

As to why things behave differently on different systems, it may have
to do the the devices.
For example if the target nic device does not get a "persistent name"
that differs from the kernel
name, then the existing .network [Match] section will apply and the
configuration
is applied.

Alex Tomlins (alex-tomlins) wrote :

@Ryan I've also attached additional logs etc from a failing system. This is running in a Virtualbox VM installed from the server iso.

Is there a workaround on 18.04? How can I rename an interface? Use udev rules like before?

Alex Tomlins (alex-tomlins) wrote :

I'm currently working around this using a systemd .link file. I created /etc/systemd/network/50-lan0.link as follows:

[Match]
MACAddress=08:00:27:3d:1a:a4

[Link]
Name=lan0

Then ran update-initramfs -u

I then use netplan to configure the lan0 interface without doing any renaming.

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

Other bug subscribers

Remote bug watches

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