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

Fri May 11 17:27:55 UTC 2018

On Fri, May 11, 2018 at 10:18 AM, Daniel Axtens
<daniel.axtens at canonical.com> wrote:
> Right. Yes, I can replicate that, thanks heaps!

Great!

>
> So to summarise, you can make the rename take effect on boot if you:
>  1) copy the files from /run/systemd/network -> /etc/systemd/network
>  2) then update-initramfs -u
>
> This seems pretty far outside of the way that netplan is supposed to work -
> indeed using /etc/systemd/ is basically bypassing netplan. So we still have
> the issue that just changing 'set-name' in /etc/netplan/*.yaml doesn't work
> as expected. What should we change so that set-name works as expected?
>
> I see a few options:
>
>  0) Document that set-name is fragile and stop relying on it. This is
> actually really easy to do and I have a netplan patch drafted already. The
> reason that we have no network connectivity when set-name fails is that the
> network file netplan creates maches on *both* the new name and the mac
> address. We can just drop the new name from the [Match] section of the
> relevant .network file and match only on the provided mac address (or
> whatever else was used in the netplan match stanza). This means that
> regardless of the interface name it's brought up and networking works.

IIUC, we want to stop include the Name= value in the .network config since the
name is flaky;  we may want to hold off on that as I think we want the naming to
be solid.  You've outlined at least one way below.  We should make
set-name reliable
and we can do that, even within netplan itself.

>
>  1) Make the initramfs hook for udev copy the files from /run (as well as
> from /lib and /etc) into the initial ramdisk. This is probably my
> preference; we can run netplan generate beforehand to make sure we get a
> clean copy, and then document that update-initramfs is required to get
> stuff to stick.

Yes, I think that's also reasonable, it's a new location where .link
files may be present.

>
>  2) Allow udev to re-rename interfaces. I don't know if this would be
> acceptable to systemd upstream?
>
>  3) Something else?

Netplan can do what cloud-init does and check that if the current name
of an interface doesn't match
the set-name value, to ip link set name on it.

>
> Regards,
> Daniel
>
> --
> 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