[Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Ryan Harper]

Can you provide the journalctl -b output for the boot that does this
rename?  Is the reproduce the same, can you provide your steps and
I'll replicate.

Xenial does not enable netplan by default so we have a different path
there at least.


On Mon, May 14, 2018 at 9:58 PM, Daniel Axtens
<daniel.axtens at canonical.com> wrote:
> This is not a full solution. In Xenial this renaming works even if
> initramfs has *not* been updated and there is no 70-persistent-net.rules
> file in the initial ramdisk. I'm still figuring out why this is, but it
> means that even if my patch were applied, there would be a regression in
> bionic vs xenial.
>
> Here's a snippet from dmesg showing the same device being renamed twice,
> this is a xenial guest. It shows the device going from the kernel name
> (eth0) to the udev slot based name (ens16), to the name specified in the
> udev rules file that is *not* present in initrd.
>
> ubuntu at xt2:~$ dmesg|grep renamed
> [    2.428015] virtio_net virtio3 ens16: renamed from eth0
> [    5.317990] virtio_net virtio3 ens3: renamed from ens16
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https://bugs.launchpad.net/bugs/1770082
>
> Title:
>   systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions

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

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === 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