Verification-done on bionic with netplan.io 0.40.1~18.04.2:

Using the following config:

network:
    version: 2
    ethernets:
        maas0:
            addresses:
            - 10.3.21.29/20
            gateway4: 10.3.16.1
            match:
                macaddress: 52:54:00:4d:3e:84
            mtu: 1500
            set-name: maas0

The interface renaming is correctly done at boot time; then changing
set-name to 'maas1', bringing down the interface with 'ip link set dev
maas0 down', and running 'netplan apply'; the interface is correctly
renamed:


ubuntu@nice-baboon:~$ sudo vi /etc/netplan/50-cloud-init.yaml 
ubuntu@nice-baboon:~$ sudo netplan apply
ubuntu@nice-baboon:~$ ip addr
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: maas0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
    link/ether 52:54:00:4d:3e:84 brd ff:ff:ff:ff:ff:ff
    inet 10.3.21.29/20 brd 10.3.31.255 scope global maas0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4d:3e84/64 scope link 
       valid_lft forever preferred_lft forever
ubuntu@nice-baboon:~$ 
ubuntu@nice-baboon:~$ sudo vi /etc/netplan/50-cloud-init.yaml 
ubuntu@nice-baboon:~$ ip link set dev maas0 down
RTNETLINK answers: Operation not permitted
ubuntu@nice-baboon:~$ sudo !!
sudo ip link set dev maas0 down
ubuntu@nice-baboon:~$ ip addr
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: maas0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group 
default qlen 1000
    link/ether 52:54:00:4d:3e:84 brd ff:ff:ff:ff:ff:ff
    inet 10.3.21.29/20 brd 10.3.31.255 scope global maas0
       valid_lft forever preferred_lft forever
ubuntu@nice-baboon:~$ sudo netplan apply
ubuntu@nice-baboon:~$ ip addr
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: maas1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
    link/ether 52:54:00:4d:3e:84 brd ff:ff:ff:ff:ff:ff
    inet 10.3.21.29/20 brd 10.3.31.255 scope global maas1
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4d:3e84/64 scope link 
       valid_lft forever preferred_lft forever


** Tags removed: verification-failed-bionic verification-needed
** Tags added: verification-done-bionic

** Tags removed: verification-done-xenial verification-needed-cosmic
** Tags added: verification-needed-xenial

** Tags removed: verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Fix Released
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Released
Status in netplan.io source package in Bionic:
  Fix Committed
Status in netplan.io source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
      version: 2
      ethernets:
          ens3:
              dhcp4: true
              match:
                  macaddress: 52:54:00:de:bd:f6
              set-name: myif0
  - Bring down interface : 'ip link set dev ens3 down'
  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
      link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
      version: 2
      ethernets:
          ens3:
              dhcp4: true
              match:
                  macaddress: 52:54:00:de:bd:f6
              set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ 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: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
qlen 1000
      link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  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: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
      link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
      inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
         valid_lft 3575sec preferred_lft 3575sec
      inet6 fe80::5054:ff:fede:bdf6/64 scope link
         valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to