Comment 7 for bug 1802004

Revision history for this message
William Foster (williamfoster) 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 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 the syslog.

Removing the 'set-name' directive again resolved the issue and the interface got an IP during boot.

I did some further testing on this system since was the worst result.

After the system had booted without 'set-name' the interface had an IP and was named 'ens160'. I then added the 'set-name' line to the configuration and ran 'netplan apply' which resulted in no change to the interface; it was still called 'ens160' and had an IP.

I then booted the system with 'set-name' and the interface had no IP. I then removed the 'set-name' line from the configuration and ran 'netplan apply'; the interface came up named 'ens160' and got an IP immediately.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System-04 (Works fine) - netplan.io 0.40.1~18.04.2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This test was on a VMware VM on the same host and using a VM template I created from System-03. It was setup one day after System-03.

I used the same config and just like System-02 it had no issues with the renamed interface getting an IP after booting up.

~~~~~~~~~~
Conclusion
~~~~~~~~~~

I have no idea why the exact same configuration is working on one physical and one virtual system, but not on the other physical and virtual systems. Either way this is definitely an issue for some of our development as we tend to use specific names for interfaces across systems depending on what the connection is to.

I have attached a file showing showing the syslog startup from each system; as I seem to only be able to add one attachement it is all concatenated into one file with sections for each system. If any other logs or output would be helpful then let me know.

As I said System-01 has the same result as what is discussed in this bug, so I thought it would be appropriate to add to this bug. If it would be better for me to create a new bug report I can do that instead.