systemd-networkd not renaming devices on boot

[Daniel Axtens]

[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.

[Mathieu Trudel-Lapierre (cyphermox)]

Works for me. I've been using a config like this for a while, the system sets the interface name at boot as expected:

network:
  version: 2
  renderer: networkd
  ethernets:
    mainif:
      match:
        macaddress: "b8:27:eb:b6:35:86"
      set-name: mainif
      addresses: [ "10.3.0.5/23" ]
      gateway4: 10.3.0.1
      [...]

The difference here is that this is hardware rather than a VM. Are we sure that the network interface shows up sufficiently early, and that the mac can be matched at the time?

[Daniel Axtens (daxtens)]

Both the original cloudy report and my test use a VM. The issue seems to happen for both virtio and emulated e1000 network hardware.

What happens differently with a VM?

[Ryan Harper (raharper)]

Are you providing network config to cloud-init? Otherwise, cloud-init is going to generate a fallback network config like your original, dhcp on one of the interfaces.

If you want to persist network changes, you need to add them to a separate netplan yaml config, or provide an updated network-config to cloud-init; otherwise it's going to regenerate the same configuration which will clobber a local change.

[Daniel Axtens (daxtens)]

Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and
I've never seen it regenerated.

I also don't see anything in /run/netplan or /run/systemd/network that has
been autogenerated.

I haven't touched anything else generated by cloud-init. When would
cloud-init regenerate a network config file?

[Ryan Harper (raharper)]

On Wed, May 9, 2018 at 9:13 AM, Daniel Axtens
<email address hidden> wrote:
> Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and
> I've never seen it regenerated.

Ah, right, it doesn't regenerate unless you change instance-ids.

>
> I also don't see anything in /run/netplan or /run/systemd/network that has
> been autogenerated.
>
> I haven't touched anything else generated by cloud-init. When would
> cloud-init regenerate a network config file?

Nothing, you're right. You can make a local change and reboot but typically
for cloud instances you'd want to have it set during the first boot.

So your scenario is:

1) deploy instance
2) log in and modify /etc/netplan/50-cloud-init.yaml to add a set-name:
3) reboot?

And the result is that you don't see a name change?

Yes, I think this is the udev scenario where it won't change a device
name whose 'name_assign_type' is either 3 or 4;

The driver unplug code in netplan is designed to workaround this
design issue with udev itself.

Can you confirm the driver for the interface you're renaming? ethtool
-i <iface name>

>
> --
> 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

[Ryan Harper (raharper)]

Investigating, it appears that the interfaces are getting renamed by udev in the initramfs, which pushes their name_assign_type value to 4, and udev refuses to rename an interface if the name_assign_type value is 4.

So, I can make this scenario work if I do:

4. sudo update-initramfs -u
5. reboot

After rebooting, the interface is correct.

I'll add a systemd task here in case we want to poke at allowing renames even if assign-type is 4.

[Daniel Axtens (daxtens)]

Ryan, I can't get that to work on my systems. What is it that update-initramfs is supposed to change? I don't see any files in my initramfs that are generated or read by netplan. Neither do I see netplan itself in the initramfs!

Mathieu, I thought netplan was supposed to be initramfs friendly by virtue of being in C. Is it supposed to be in the initramfs?

For both of you, how are you getting through initrd without your device being given a generic udev name (like ens3 or enp1s0)? On both my physical and virtual machines, my various network cards all get renamed in initrd, well before netplan is run.

[PS. I know the scenario as described sounds far-fetched - the original way this came up was a cloud setup where you can change the type of a network interface but keep the same MAC. The different type leads to a different udev name, which is what revealed that set-name: wasn't taking effect.]

[Ryan Harper (raharper)]

On Fri, May 11, 2018 at 3:25 AM, Daniel Axtens
<email address hidden> wrote:
> Ryan, I can't get that to work on my systems. What is it that update-
> initramfs is supposed to change? I don't see any files in my initramfs
> that are generated or read by netplan. Neither do I see netplan itself
> in the initramfs!

The .link files end up getting pulled into the initramfs, where
systemd-udev will run and apply the
names there. When systemd-udev does a rename, the kernel marks an
interface 'name_assign_type' to a value of 4
and systemd-udev will refuse to further rename a device, despite
having a rule (.link file) to do so.

Netplan works around this in 'apply' by unplugging the driver, which
resets the state of the 'name_assign_type' value
in the kernel.

>
> Mathieu, I thought netplan was supposed to be initramfs friendly by
> virtue of being in C. Is it supposed to be in the initramfs?

The generator is, the cli is not.

>
> For both of you, how are you getting through initrd without your device
> being given a generic udev name (like ens3 or enp1s0)? On both my
> physical and virtual machines, my various network cards all get renamed
> in initrd, well before netplan is run.

We're not; udev runs in the initramfs and triggers renames there.

>
> [PS. I know the scenario as described sounds far-fetched - the original
> way this came up was a cloud setup where you can change the type of a
> network interface but keep the same MAC. The different type leads to a
> different udev name, which is what revealed that set-name: wasn't taking
> effect.]

Cloud scenarios are slightly different when cloud-init is involved;
Cloud-init itself will handle device renames if
they are needed. Typically cloud-init just re-uses the name the
interface got from udev when it renders it's netplan config during
boot.

For non-cloud scenarios (or if you attempt to use set-name in a cloud
instances without launching a new instance) we're seeing this
situation where we are creating new .link files but they need to be
present in the initramfs otherwise when udevd runs, it will set the
name
to the predictable name and then ignore any of the .link files on the rootfs.

This really needs fixing in udev; I don't think there's a good reason
to have udev refuse to rename an interface.

>
> --
> 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

[Daniel Axtens (daxtens)]

Ok, so the bit I'm stuck on is how the link files and the netplan generator are getting pulled into the initramfs then.

ubuntu@btest:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic

ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \\.link
lib/systemd/network/99-default.link
ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep netplan
ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep generate
ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep system-generators

As you can see there's no generator and no link files in my initramfs - by what mechanism is it supposed to work? What package/script/tool is supposed to pull the link files in?

[Ryan Harper (raharper)]

I'm just verifying that on my end; note that the 99-default.link is
going to be sufficient to trigger a rename from eth0 to ens3; which
then prevents any rename once we mount root.

Here's the trigger:

% /usr/share/initramfs-tools/hooks/udev
# copy .link files containing interface naming definitions
mkdir -p $DESTDIR/lib/systemd/network/
find /lib/systemd/network -name '*.link' -execdir cp -pt
$DESTDIR/lib/systemd/network/ '{}' +
if [ -d /etc/systemd/network ]; then
  find /etc/systemd/network -name '*.link' -execdir cp -pt
$DESTDIR/lib/systemd/network/ '{}' +
fi

If you create a .link file in /etc/systemd/network/ lower than 99-*
then those link rules will apply first.

On Fri, May 11, 2018 at 9:24 AM, Daniel Axtens
<email address hidden> wrote:
> Ok, so the bit I'm stuck on is how the link files and the netplan
> generator are getting pulled into the initramfs then.
>
> ubuntu@btest:~$ sudo update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
>
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \\.link
> lib/systemd/network/99-default.link
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep netplan
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep generate
> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep system-generators
>
> As you can see there's no generator and no link files in my initramfs -
> by what mechanism is it supposed to work? What package/script/tool is
> supposed to pull the link files in?
>
> --
> 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

[Ryan Harper (raharper)]

root@rharper-b1:~# vi /etc/netplan/50-cloud-init.yaml
# changed the set-name: to eth_lan
root@rharper-b1:~# netplan generate
root@rharper-b1:~# cp /run/systemd/network/10-netplan-ens3.link
/etc/systemd/network/

# just the default link file in the initramfs
root@rharper-b1:~# lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \.link
lib/systemd/network/99-default.link
lib/modules/4.15.0-20-generic/kernel/net/core/devlink.ko
lib/udev/rules.d/80-net-setup-link.rules
bin/readlink

root@rharper-b1:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic

# now we see the local .link file from /etc copied in.
root@rharper-b1:~# lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \.link
lib/modules/4.15.0-20-generic/kernel/net/core/devlink.ko
lib/systemd/network/99-default.link
lib/systemd/network/10-netplan-ens3.link
lib/udev/rules.d/80-net-setup-link.rules
bin/readlink

On Fri, May 11, 2018 at 9:35 AM, Ryan Harper <email address hidden> wrote:
> I'm just verifying that on my end; note that the 99-default.link is
> going to be sufficient to trigger a rename from eth0 to ens3; which
> then prevents any rename once we mount root.
>
> Here's the trigger:
>
> % /usr/share/initramfs-tools/hooks/udev
> # copy .link files containing interface naming definitions
> mkdir -p $DESTDIR/lib/systemd/network/
> find /lib/systemd/network -name '*.link' -execdir cp -pt
> $DESTDIR/lib/systemd/network/ '{}' +
> if [ -d /etc/systemd/network ]; then
> find /etc/systemd/network -name '*.link' -execdir cp -pt
> $DESTDIR/lib/systemd/network/ '{}' +
> fi
>
> If you create a .link file in /etc/systemd/network/ lower than 99-*
> then those link rules will apply first.
>
>
> On Fri, May 11, 2018 at 9:24 AM, Daniel Axtens
> <email address hidden> wrote:
>> Ok, so the bit I'm stuck on is how the link files and the netplan
>> generator are getting pulled into the initramfs then.
>>
>> ubuntu@btest:~$ sudo update-initramfs -u
>> update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
>>
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \\.link
>> lib/systemd/network/99-default.link
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep netplan
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep generate
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep system-generators
>>
>> As you can see there's no generator and no link files in my initramfs -
>> by what mechanism is it supposed to work? What package/script/tool is
>> supposed to pull the link files in?
>>
>> --
>> 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

[Daniel Axtens (daxtens)]

Right. Yes, I can replicate that, thanks heaps!

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.

 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.

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

 3) Something else?

Regards,
Daniel

[Ryan Harper (raharper)]

On Fri, May 11, 2018 at 10:18 AM, Daniel Axtens
<email address hidden> 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

[Daniel Axtens (daxtens)]

Ok, how does this look?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "link-files-in-run.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Daniel Axtens (daxtens)]

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@xt2:~$ dmesg|grep renamed
[ 2.428015] virtio_net virtio3 ens16: renamed from eth0
[ 5.317990] virtio_net virtio3 ens3: renamed from ens16

[Ryan Harper (raharper)]

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
<email address hidden> 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@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

[Daniel Axtens (daxtens)]

Hi Ryan,

[Journal Output]
Attached.

[Reproducer]
uvt-kvm create xenial-test release=xenial arch=amd64
virsh edit xenial-test # change network interface pci slot: s/0x03/0x10/
virsh destroy xenial-test
virsh start xenial-test
uvt-kvm ssh xenial-test
dmesg|grep rename
[ 2.790623] virtio_net virtio3 ens16: renamed from eth0
[ 6.048520] virtio_net virtio3 ens3: renamed from ens16

[Analysis]
I've been working on this a lot, and I think I have the cause of the difference.

In udev-events.c, udev_execute_rules will _forcibly_ rename a device with via a netlink message if there is a matching rule that sets a name. Under Xenial, there *is* a matching rule, in 70-persistent-net.rules, so this forces a rename. This rename will occur even if the device already has a name, and therefore even if the rules file isn't in the initramfs.

Under Bionic, this rules file doesn't exist, there is a .link file instead. Unfortunately, a name in a .link file will only take effect if the device hasn't been renamed - because of the renaming in initrd, this means that a link file that is not present in the initrd will never be able to cause a rename.

[Solutions]
There are a couple of ways we could fix this that come to mind:

 - make netplan generate a file in /run/udev/rules.d for each device
 - make systemd rename devices from a link file even if they've been renamed

My preference is the first, but I'm open to anything we can get upstream.

Thanks again.

Regards,
Daniel

[Ryan Harper (raharper)]

Note, that uvt-kvm is going to use cloud-init; how are you making
sure that cloud-init isn't doing the rename itself?
Xenial by default doesn't use netplan; it still uses eni; the network
configuration generation in cloud-init using eni
does create a 70-persistent-net.rules file that handles renames on
subsequent reboots; in a netplan world (bionic)
the .link file is meant to be the equivalent of a .rules file.

I've not attempted to determine if systemd-udev in bionic would
respect renames from .rules file; it certainly seems
odd to have .rules files allow renames independent of name_assign_type
value where .link files do.

On Tue, May 15, 2018 at 12:29 PM, Daniel Axtens
<email address hidden> wrote:
> Hi Ryan,
>
> [Journal Output]
> Attached.
>
> [Reproducer]
> uvt-kvm create xenial-test release=xenial arch=amd64
> virsh edit xenial-test # change network interface pci slot: s/0x03/0x10/
> virsh destroy xenial-test
> virsh start xenial-test
> uvt-kvm ssh xenial-test
> dmesg|grep rename
> [ 2.790623] virtio_net virtio3 ens16: renamed from eth0
> [ 6.048520] virtio_net virtio3 ens3: renamed from ens16
>
> [Analysis]
> I've been working on this a lot, and I think I have the cause of the difference.
>
> In udev-events.c, udev_execute_rules will _forcibly_ rename a device
> with via a netlink message if there is a matching rule that sets a name.
> Under Xenial, there *is* a matching rule, in 70-persistent-net.rules, so
> this forces a rename. This rename will occur even if the device already
> has a name, and therefore even if the rules file isn't in the initramfs.
>
> Under Bionic, this rules file doesn't exist, there is a .link file
> instead. Unfortunately, a name in a .link file will only take effect if
> the device hasn't been renamed - because of the renaming in initrd, this
> means that a link file that is not present in the initrd will never be
> able to cause a rename.
>
> [Solutions]
> There are a couple of ways we could fix this that come to mind:
>
> - make netplan generate a file in /run/udev/rules.d for each device
> - make systemd rename devices from a link file even if they've been renamed
>
> My preference is the first, but I'm open to anything we can get
> upstream.
>
> Thanks again.
>
> Regards,
> Daniel
>
> ** Attachment added: "journalctl -b output on Xenial VM with multiple renames"
> https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139894/+files/journalctl-b.txt
>
> --
> 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

[Daniel Axtens (daxtens)]

> Note, that uvt-kvm is going to use cloud-init; how are you making
> sure that cloud-init isn't doing the rename itself?

I instrumented the kernel. I added a call to dump_stack() in the function that does interface renaming: dev_change_name() in net/core/dev.c. That showed that the process that sent the netlink message was systemd-udevd:

[ 1.007200] virtio_net virtio3 ens16: renamed from eth0
[ 1.008453] CPU: 0 PID: 124 Comm: systemd-udevd Not tainted 4.4.59+ #1
[ 1.009887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1.011938] 0000000000000286 00000000d38795d9 ffff88001ed3b970 ffffffff813f3f63
[ 1.012435] ffff88001f2d0000 0000000000000000 ffff88001ed3b9d8 ffffffff8170669b
[ 1.012435] ffff88001ed3b9c8 ffff88001ed3b9a0 ffffffff812255af 0000000030687465
[ 1.012435] Call Trace:
[ 1.012435] [<ffffffff813f3f63>] dump_stack+0x63/0x90
[ 1.012435] [<ffffffff8170669b>] dev_change_name+0x25b/0x2e0
<call chain back to syscall snipped>

...

[ 2.336114] virtio_net virtio3 ens3: renamed from ens16
[ 2.336121] CPU: 0 PID: 454 Comm: systemd-udevd Not tainted 4.4.59+ #1
[ 2.336122] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 2.336124] 0000000000000286 0000000027d63c85 ffff88001c59b970 ffffffff813f3f63
[ 2.336126] ffff88001f2d0000 0000000000000000 ffff88001c59b9d8 ffffffff8170669b
[ 2.336128] 0000000000000001 ffff88001c59b9b0 ffffffff810b3f1c 0000003631736e65
[ 2.336130] Call Trace:
[ 2.336135] [<ffffffff813f3f63>] dump_stack+0x63/0x90
[ 2.336138] [<ffffffff8170669b>] dev_change_name+0x25b/0x2e0
<call chain back to syscall snipped>

Notice in both cases: "Comm: systemd-udevd". Also notice the change in PID, suggesting that the first one is in initrd and the second one is not.

I then grepped the source code for netlink stuff and quickly narrowed in on rename_if in udev-events.c.

> Xenial by default doesn't use netplan; it still uses eni; the network
> configuration generation in cloud-init using eni
> does create a 70-persistent-net.rules file that handles renames on
> subsequent reboots; in a netplan world (bionic)
> the .link file is meant to be the equivalent of a .rules file.

I am aware of this. (I've hacked on netplan quite a bit.)

The issue is that a .link file does not seem to be functionally equivalent to a .rules file. I don't know if this difference is deliberate or an oversight. I will open an issue upstream and ask.

> I've not attempted to determine if systemd-udev in bionic would
> respect renames from .rules file; it certainly seems
> odd to have .rules files allow renames independent of name_assign_type
> value where .link files do.

The end-user tested with a .rules file on Bionic and reported that it worked. I have also just verified that it does respect renames from a rules file regardless of name_assign_type. (The codepaths are unchanged between systemd-229 and systemd-237.)

[Daniel Axtens (daxtens)]

Opened https://github.com/systemd/systemd/issues/9006

[Stefan Beckers privat (stefan-beckers)]

I was struggling with this for quite some time and played around using netplan.io and not using it. I figured out that you need to run "update-initramfs -u" to make settings persist reboots in "/etc/systemd/network/" when not using netplan.io.

But netplan.io saves the configuration in "/run/systemd/network/". Here the update of initramfs does not make any difference and on boot the network set-up fails to rename the interfaces as configured with all consequences for the system.

To me it appears that "update-initramfs" needs to include the generated configuration from netplan.io to get the network configuration correct on reboot.

The following workaround does the job for me after every configuration change in netplan.io:

1. netplan apply
2. rm /etc/systemd/network/10-netplan-*.link
3. cp /run/systemd/network/10-netplan-*.link /etc/systemd/network/
4. update-initramfs -u

Now the generated link files are found by update-initrd. Never the less there should be a consistent solution.

[Mike Jonkmans (mjo)]

Things seem to work when i change the NamePolicy in the initrd file /lib/systemd/network/99-default.link to
`NamePolicy=kernel`

Leaving out the other NamePolicy-options, prevents renaming in the initrd fase.
Which allows later renames from .link files/netplan.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ryan Harper (raharper)]

We really only want to be allowed to rename interfaces that have requested it.
This means other interfaces which do not have a set-name directive
will have the kernel name.

On Thu, May 24, 2018 at 6:56 AM, Mike Jonkmans
<email address hidden> wrote:
> Things seem to work when i change the NamePolicy in the initrd file /lib/systemd/network/99-default.link to
> `NamePolicy=kernel`
>
> Leaving out the other NamePolicy-options, prevents renaming in the initrd fase.
> Which allows later renames from .link files/netplan.
>
> --
> 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

[Mike Jonkmans (mjo)]

As discussed on https://github.com/systemd/systemd/issues/9006

The initrd (!) should have NamePolicy=kernel in /lib/systemd/network/99-default.link

[Ryan Harper (raharper)]

That's not the final conclusion; the issue is still being discussed upstream; in particular as to why only the interface name cannot be modified at runtime by .link files.

[Mathieu Trudel-Lapierre (cyphermox)]

There are a couple of pieces in play here.

One aspect is that we don't really want to write the .link files for systemd-networkd to /lib or get anything from /run into the initrd -- that defeats the purpose of netplan's config being dynamic.

The second aspect is that depending on how the systems are deployed (MAAS? cloud images? openstack? VM? hardware?) changes the behavior a bit. Some USB-based network interfaces are simply "unaffected" and rename just fine at boot. Other systems may be renaming the interfaces, but seeing cloud-init re-change the name *back* to the previous value (this has been observed for MAAS-deployed systems). This is why I added cloud-init to affected packages -- cloud-init should not be second-guessing the network layer and attempting to do renames / to run udevadm, except *maybe* at first boot/when the instance data is created. I believe it should just leave it alone completely, and let netplan/systemd/NM deal with the interfaces themselves (if anything needs to be poked, it's arguably a bug in the backend).

Another issue is that systemd is also second-guessing configuration. If we set things to be renamed, we do want them to be renamed. Now, this is a bit more up to discussion upstream, but I do think systemd should always rename if configuration tells it to (via .link files or udev rules -- .link files are "cleaner", easier to write). Users renaming their interfaces manually via 'ip link dev X name Y' are doing so on their own, and the change would not be persistent across a reboot -- renaming in configuration is expected to work normally.

[Mathieu Trudel-Lapierre (cyphermox)]

My recommended course of action for cosmic:

 - drop udevadm (net_setup_link) call from cloud-init
 - drop set-name "renaming" from cloud-init / maas
 - drop replug code in netplan; replace with proper .link code, possibly call to net_setup_link.
 - maybe write udev rule for renaming in netplan (think belt and suspenders)
 - make sure .link files are written correctly by netplan for renaming
 - patch systemd to not second-guess renaming from .link files

[Mathieu Trudel-Lapierre (cyphermox)]

My recommended course of action for SRUs:

 - write udev .rules files from netplan to enforce renaming
 - drop udevadm (net_setup_link) call from cloud-init

The above should be sufficient and non-intrusive enough for SRU. The tasks for cosmic are additional changes to clean up the behavior for the future.

[Mathieu Trudel-Lapierre (cyphermox)]

netplan changes are available in git:

Daniel's patch to write udev rules (SRU material):
https://github.com/CanonicalLtd/netplan/commit/b0c51bfa8ba8b898a9feaed9cd7d8790d147d35d

Daniel's patch + dropping replug code + rework 'netplan apply' (code for cosmic); in progress for upload to cosmic:
https://github.com/CanonicalLtd/netplan/tree/live-rename

[Mathieu Trudel-Lapierre (cyphermox)]

I'm not completely sure where the code lives in cloud-init; it looks a bit like what's in:

cloudinit/net/netplan.py

But the code does read as though it should not be running 'udevadm test-builtin net_setup_link'. However, deploying a system with MAAS shows a /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg file, which contains data referring to the network interfaces:

network:
  config:
  - id: ens6
    mac_address: 52:54:00:31:27:2c
    mtu: 1500
    name: ens6
    subnets:
    - address: 10.3.99.13/24
      gateway: 10.3.99.1
      type: static
    type: physical
  version: 1

With that file in place, any netplan config renaming the interface to something other than ens6 will see the interface being renamed *again* back to ens6, when that file is removed, this behavior does not appear.

[Ryan Harper (raharper)]

"This is why I added
cloud-init to affected packages -- cloud-init should not be second-
guessing the network layer and attempting to do renames / to run"

There is no second guessing. In the case where we have no network
config, there is no renaming; we accept whatever name is given.

If the config passed to cloud-init includes a name for an interface, then
cloud-init applies that name; this is the MAAS scenario;

Given the unreliable nature of udev w.r.t naming (see this very bug)
The *only* way for cloud-init to ensure that a directive to name an interface
matches the config (also note cloud-init accepts network config in
various formats
not just netplan) is to handle naming if requested directly, precisely
due to this bug.

If we fix systemd-udevd to allow renames of interfaces reliably that helps
most cases where udevd runs. For the remaining cases where udev doesn't run,
containers for example, cloud-init will still need to use iproute2 to
set an interface
name if requested.

On Fri, May 25, 2018 at 8:55 AM, Mathieu Trudel-Lapierre
<email address hidden> wrote:
> netplan changes are available in git:
>
> Daniel's patch to write udev rules (SRU material):
> https://github.com/CanonicalLtd/netplan/commit/b0c51bfa8ba8b898a9feaed9cd7d8790d147d35d
>
> Daniel's patch + dropping replug code + rework 'netplan apply' (code for cosmic); in progress for upload to cosmic:
> https://github.com/CanonicalLtd/netplan/tree/live-rename
>
> --
> 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

[Ryan Harper (raharper)]

On Fri, May 25, 2018 at 8:48 AM, Mathieu Trudel-Lapierre
<email address hidden> wrote:
> My recommended course of action for cosmic:
>
> - drop udevadm (net_setup_link) call from cloud-init

This will still be needed in the case that we have a network config with names.
Cloud-init runs after udev coldplug, so any .link files would have to already be
present. We're generating a network config post coldplug, but pre networking.

Now, if after we netplan generate, if links could be applied or if
networkd kicks udev
to rename interfaces, that's fine. But it doesn't do that today.

> - drop set-name "renaming" from cloud-init / maas

I've already replied, but this is required for instances where udev
doesn't run but
network config has been provided.

> - drop replug code in netplan; replace with proper .link code, possibly call to net_setup_link.

+1

> - maybe write udev rule for renaming in netplan (think belt and suspenders)

? Instead of the .link files?

> - make sure .link files are written correctly by netplan for renaming
> - patch systemd to not second-guess renaming from .link files

+1

>
> --
> 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

[Ryan Harper (raharper)]

On Fri, May 25, 2018 at 9:09 AM, Mathieu Trudel-Lapierre
<email address hidden> wrote:
> I'm not completely sure where the code lives in cloud-init; it looks a
> bit like what's in:
>
> cloudinit/net/netplan.py
>
> But the code does read as though it should not be running 'udevadm test-
> builtin net_setup_link'. However, deploying a system with MAAS shows a
> /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg file, which contains
> data referring to the network interfaces:
>
> network:
> config:
> - id: ens6
> mac_address: 52:54:00:31:27:2c
> mtu: 1500
> name: ens6
> subnets:
> - address: 10.3.99.13/24
> gateway: 10.3.99.1
> type: static
> type: physical
> version: 1
>
> With that file in place, any netplan config renaming the interface to
> something other than ens6 will see the interface being renamed *again*
> back to ens6, when that file is removed, this behavior does not appear.

Cloud-init only renders network config once per-instance. If a user
wanted to modify this to something else (and we fix udev to handle
.link file name changes) then there won't be any additional renames.
Even without the change, cloud-init isn't going to call udevadm test-builtin
more than once per-instance.

>
> --
> 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

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.38

---------------
netplan.io (0.38) cosmic; urgency=medium

  * New upstream release:
    - Write udev .rules files to /run/udev/rules.d to enforce interface
      renaming. (LP: #1770082)
    - Don't traceback for 'netplan ip leases' when iface is not managed or
      doesn't DHCP (LP: #1768823)
    - Fix duplicate "/" path separator in error messages (LP: #1771440)
    - Fix incorrect terminal reset in 'netplan try' on Ctrl-C. (LP: #1768798)
    - Updated doc entries: mtu, fix fwmark->mark, cleanup optional.
      (LP: #1768783)
    - Added documentation validation at build.
    - Added configuration example for multi-ip interfaces.
  * tests/integration.py: fix test_eth_and_bridge autopkg test harder.
  * debian/control:
    - Add iproute2 to Depends.
    - Add python3-netifaces to Depends, Build-Depends.

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 04 Jun 2018 14:45:26 -0400

[Nicorac (nicorac)]

Thanks for the update.

Referring to this duplicate bug (https://bugs.launchpad.net/netplan/+bug/1768827), is it going to be backported to 18.04?
Or is there a way to install 0.38 on Ubuntu Server 18.04?

[Łukasz Zemczak (sil2100)]

Could this bug be updated with SRU relevant information? Also, it would also be nice if we had the same changes prepared for netplan.io in bionic.

[Łukasz Zemczak (sil2100)]

Hello Daniel, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Nicorac (nicorac)]

Still not working on my side (plain vanilla Ubuntu Server 18.04, fully updated, no cloud).

The renaming regression of 0.40.1~18.04.1 has been fixed, but it's still not applying IP address just after boot.

A manual "netplan apply" correctly configures the network interface.

-----------------------------------------------------
root@test:~# dpkg -s netplan.io | grep Version
Version: 0.40.1~18.04.2
-----------------------------------------------------

=======================
=== Just after boot ===
=======================

root@test:~# ifconfig -a
eth_lan: flags=4098<BROADCAST,MULTICAST> mtu 1500
        ether 08:00:27:6b:d8:91 txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        RX packets 6 bytes 318 (318.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 6 bytes 318 (318.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

-----------------------------------------------------
root@test:~# 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:
    id0:
      match:
        macaddress: 08:00:27:6b:d8:91
      set-name: eth_lan
      addresses: [ 192.168.1.10/24 ]
      gateway4: 192.168.1.1
      nameservers:
          addresses: [ 8.8.4.4 ]

-----------------------------------------------------
root@test:~# cat /run/systemd/network/10-netplan-id0.link
[Match]
MACAddress=08:00:27:6b:d8:91

[Link]
Name=eth_lan
WakeOnLan=off

-----------------------------------------------------
root@test:~# cat /run/systemd/network/10-netplan-id0.network
[Match]
MACAddress=08:00:27:6b:d8:91
Name=eth_lan

[Network]
LinkLocalAddressing=ipv6
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=8.8.4.4

-----------------------------------------------------

====================================
=== After manual "netplan apply" ===
====================================

root@test:~# ifconfig -a
eth_lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255
        inet6 fe80::a00:27ff:fe6b:d891 prefixlen 64 scopeid 0x20<link>
        ether 08:00:27:6b:d8:91 txqueuelen 1000 (Ethernet)
        RX packets 277 bytes 51263 (51.2 KB)
        RX errors 0 dropped 128 overruns 0 frame 0
        TX packets 13 bytes 946 (946.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        RX packets 20 bytes 1470 (1.4 KB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 20 bytes 1470 (1.4 KB)
        TX errors 0 dropped 0 overr...

[Marcos (markinholiveira)]

Tested just now... It is working for the subiquity installer version (ubuntu-18.04-live-server-amd64.iso) but it does not apply ip address on boot if installed with the debian-intaller version (ubuntu-18.04-server-amd64.iso).

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.40.2.1

---------------
netplan.io (0.40.2.1) cosmic; urgency=medium

  * Fix typo breaking rename on 'netplan apply'. (LP: #1770082)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 22 Oct 2018 14:58:40 -0400

[Mathieu Trudel-Lapierre (cyphermox)]

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

[Mathieu Trudel-Lapierre (cyphermox)]

Verification-done for cosmic using netplan.io 0.40.2.1:

I have verified that renames happen correctly with the config provided in test cases and the config I have shown for the testing on bionic.

In all cases, set-name is applied as the new name for the interface, as expected. On reboot, this is sufficient for the interface to be renamed. After boot, the interface must first be brought down before it can be renamed (this is expected behavior, renaming does not work on a busy interface).

[Nicorac (nicorac)]

@Marcos,#80: ubuntu-18.04-server-amd64.iso is exactly the ISO I'm using for my installations.

@Mathieu,#82: you've removed the verification-failed-bionic tag but 0.40.1~18.04.2 is still not working on my side, both on VirtualBox VM and on Proxmox VM (KDE).
Interface renaming works but IP address/netmask doesn't.
I'm using ubuntu-18.04-server-amd64.iso to install both of them, and they both have the same issue.

PS: I actually have a production server VM witn netplan-0.40.1~18.04.2 and, after reboot, I need to connect to it (thanks to Proxmox HTTP-VNC console) and manually execute "netplan apply" to bring the network up.
This is unaccetable so I'll soon remove netplan and switch back to the rock solid ifupdown for such a simple newtork configuration like mine.

Sorry to say that netplan brought me nothing but issues...

[Mathieu Trudel-Lapierre (cyphermox)]

Yes, that's because it doesn't appear like the issues you have are a regression caused by the updates, and we don't know what's wrong. You have a bug open for your issue, and we still need to figure out what doesn't work there.

[Marcos (markinholiveira)]

@Mathieu: I reinstalled my Virtualbox VM (using the ubuntu-18.04-server-amd64.iso image) and tested again and the result was the same.

netplan config:
ubuntu@ubuntu:~$ 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:
    eth0:
      match:
          macaddress: 08:00:27:f0:97:15
      set-name: eth0
      dhcp4: yes

Result after reboot:
ubuntu@ubuntu:~$ ip address show
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: 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

As you can see, the interface is successfully renamed, but the IP address is not applied.

Do you have an idea why it works with the ubuntu-18.04-live-server-amd64.iso image and not with ubuntu-18.04-server-amd64.iso? Perhaps it depends on something from cloud-init package?

[Nicorac (nicorac)]

@Marcos: same bug on my side.
I was also asked to switch from DHCP to a static IP, to make the configuration as simple as possible and remove any doubt about DHCP server issues.

Once I did it I've had the same issue (no IP at boot).
Could you please try the same thing on your side and confirm that IP address is still not set at boot?

[Marcos (markinholiveira)]

@Nicorac: Tested with static IP and had same result.

ubuntu@ubuntu:~$ 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:
    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

ubuntu@ubuntu:~$ ip address show
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: 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

[Mathieu Trudel-Lapierre (cyphermox)]

Please use bug 1768827 to track such "no IP at boot" issues; there's nothing that currently indicates that this is a regression, it needs further investigation, but not here.

[Mathieu Trudel-Lapierre (cyphermox)]

@Marcos:

Please file a new bug for your own issue; include the output of 'networkctl', and report the bug number here so we can find it.

From a quick look, I think there's no carrier detected. This could be a driver bug.

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.40.1~18.04.2

---------------
netplan.io (0.40.1~18.04.2) bionic; urgency=medium

  * Fix typo breaking rename on 'netplan apply'. (LP: #1770082)

netplan.io (0.40.1~18.04.1) bionic; urgency=medium

  * Backport netplan 0.40.1 to 18.04. (LP: #1793309)

netplan.io (0.40.1) cosmic; urgency=medium

  * tests/generate.py: use random.sample() instead of random.choices() to
    better support older pythons.
  * Deal gracefully with empty files on 'netplan apply' (LP: #1795343)

netplan.io (0.40) cosmic; urgency=medium

  * New upstream release:
    - networkd: route source is PreferredSource= not From=
    - Improve NetworkManager error reporting on unrenderable routes.
    - Don't render ipv4 dns-search unless we have an ipv4 address.
      (LP: #1786726)
    - Set permissive umask on networkd .network, .link and .netdev files
      (LP: #1736965, LP: #1768560)
    - Fix support for link-scope routes. (LP: #1747455)
    - Update man pages for deletion of replug code.
    - Spell Gratuitous ARP correctly and make it work. (LP: #1756701)
    - Many typo fixes for documentation. (LP: #1783940)
    - Various build system fixes.
    - Fix integration tests:
      - iproute2 output changes for link-scope routes
      - fix stability of networkd igmp-resend test
      - fix manual_addresses test now that networkd lists ~. domain
    - Deduplicate code for parsing interface options
    - Add support for optional-addresses.

netplan.io (0.39) cosmic; urgency=medium

  * New upstream release:
    - Allow link-local addresses to be configured. (LP: #1771704)
    - Forces bridges with no addresses to be brought online. (LP: #1736975)

netplan.io (0.38) cosmic; urgency=medium

  * New upstream release:
    - Write udev .rules files to /run/udev/rules.d to enforce interface
      renaming. (LP: #1770082)
    - Don't traceback for 'netplan ip leases' when iface is not managed or
      doesn't DHCP (LP: #1768823)
    - Fix duplicate "/" path separator in error messages (LP: #1771440)
    - Fix incorrect terminal reset in 'netplan try' on Ctrl-C. (LP: #1768798)
    - Updated doc entries: mtu, fix fwmark->mark, cleanup optional.
      (LP: #1768783)
    - Added documentation validation at build.
    - Added configuration example for multi-ip interfaces.
  * tests/integration.py: fix test_eth_and_bridge autopkg test harder.
  * debian/control:
    - Add iproute2 to Depends.
    - Add python3-netifaces to Depends, Build-Depends.

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 22 Oct 2018 15:02:30 -0400

[Marcos (markinholiveira)]

@Mathieu: Me and Nicorac have the same bug: if set-name is used, there will be no IP at boot. The bug 1768827 is about the same problem as this one (set-name not renaming interface at boot), which is resolved by now...
The strange thing is the inconsistency between the two installation types (subiquity and the legacy debian-installer). Please, could you try and install a vm with the debian-installer and try it yourself? Why does one work and the other doesn't?

Created bug 1802004, IMO 17868827 should be closed, as renames are working as expected now...

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.40.2.1

---------------
netplan.io (0.40.2.1) cosmic; urgency=medium

  * Fix typo breaking rename on 'netplan apply'. (LP: #1770082)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 22 Oct 2018 14:58:40 -0400

[Dmitrii Shcherbakov (dmitriis)]

This change introduces a regression: calling netplan apply is not idempotent for bonds, see https://bugs.launchpad.net/netplan/+bug/1802322

[Steve Langasek (vorlon)]

The SRU has been rolled back while the fix for the regression is being prepared. I still consider the previous SRU verification valid so am resetting the bug state but not the tags.

[Adam Conrad (adconrad)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.40.2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Adam Conrad (adconrad)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.40.1~18.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Mathieu Trudel-Lapierre (cyphermox)]

Resetting the tags to verification-done as per the discussion above.

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.40.2.2

---------------
netplan.io (0.40.2.2) cosmic; urgency=medium

  * Fix idempotency in renaming: bond members should be exempt from rename, as
    they may all share a single MAC for the bond device. (LP: #1802322)
  * tests/integration.py: add test designed to catch the above regression.

netplan.io (0.40.2.1) cosmic; urgency=medium

  * Fix typo breaking rename on 'netplan apply'. (LP: #1770082)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Nov 2018 14:28:42 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.40.1~18.04.3

---------------
netplan.io (0.40.1~18.04.3) bionic; urgency=medium

  * Fix idempotency in renaming: bond members should be exempt from rename, as
    they may all share a single MAC for the bond device. (LP: #1802322)
  * tests/integration.py: add test designed to catch the above regression.

netplan.io (0.40.1~18.04.2) bionic; urgency=medium

  * Fix typo breaking rename on 'netplan apply'. (LP: #1770082)

netplan.io (0.40.1~18.04.1) bionic; urgency=medium

  * Backport netplan 0.40.1 to 18.04. (LP: #1793309)

netplan.io (0.40.1) cosmic; urgency=medium

  * tests/generate.py: use random.sample() instead of random.choices() to
    better support older pythons.
  * Deal gracefully with empty files on 'netplan apply' (LP: #1795343)

netplan.io (0.40) cosmic; urgency=medium

  * New upstream release:
    - networkd: route source is PreferredSource= not From=
    - Improve NetworkManager error reporting on unrenderable routes.
    - Don't render ipv4 dns-search unless we have an ipv4 address.
      (LP: #1786726)
    - Set permissive umask on networkd .network, .link and .netdev files
      (LP: #1736965, LP: #1768560)
    - Fix support for link-scope routes. (LP: #1747455)
    - Update man pages for deletion of replug code.
    - Spell Gratuitous ARP correctly and make it work. (LP: #1756701)
    - Many typo fixes for documentation. (LP: #1783940)
    - Various build system fixes.
    - Fix integration tests:
      - iproute2 output changes for link-scope routes
      - fix stability of networkd igmp-resend test
      - fix manual_addresses test now that networkd lists ~. domain
    - Deduplicate code for parsing interface options
    - Add support for optional-addresses.

netplan.io (0.39) cosmic; urgency=medium

  * New upstream release:
    - Allow link-local addresses to be configured. (LP: #1771704)
    - Forces bridges with no addresses to be brought online. (LP: #1736975)

netplan.io (0.38) cosmic; urgency=medium

  * New upstream release:
    - Write udev .rules files to /run/udev/rules.d to enforce interface
      renaming. (LP: #1770082)
    - Don't traceback for 'netplan ip leases' when iface is not managed or
      doesn't DHCP (LP: #1768823)
    - Fix duplicate "/" path separator in error messages (LP: #1771440)
    - Fix incorrect terminal reset in 'netplan try' on Ctrl-C. (LP: #1768798)
    - Updated doc entries: mtu, fix fwmark->mark, cleanup optional.
      (LP: #1768783)
    - Added documentation validation at build.
    - Added configuration example for multi-ip interfaces.
  * tests/integration.py: fix test_eth_and_bridge autopkg test harder.
  * debian/control:
    - Add iproute2 to Depends.
    - Add python3-netifaces to Depends, Build-Depends.

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Nov 2018 14:42:59 -0500

[Timo Aaltonen (tjaalton)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Timo Aaltonen (tjaalton)]

no need to re-test this on bionic/cosmic

[Steve Langasek (vorlon)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Mathieu Trudel-Lapierre (cyphermox)]

No need to re-test these; it's already been included in bionic/cosmic and bug comments are a side-effect of the changelogs for the upload with this backport.

[Steve Langasek (vorlon)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Mathieu Trudel-Lapierre (cyphermox)]

This does not need re-testing, already in bionic/cosmic, just closed again due to changelog for this big backport.

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.10.2

---------------
netplan.io (0.96-0ubuntu0.18.10.2) cosmic; urgency=medium

  * d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
    Partially revert changes to networkd jobs ordering: leave systemd-networkd
    enabled in multi-user.target instead of network-online.target, as in some
    minimal setups there might be no job requiring network-online.target,
    whereas the natural target to reach for booting is multi-user.target.
    (LP: #1821867)

netplan.io (0.96-0ubuntu0.18.10.1) cosmic; urgency=medium

  * Backport netplan.io 0.96 to 18.10.
  * debian/patches/glib_changes.patch: Patch tests to work again on older GLib.
  * debian/control: adjust Depends for cosmic / re-add nplan package.

netplan.io (0.96-0ubuntu1) disco; urgency=medium

  * New upstream release 0.96.
    - Moved netplan-wpa@ services to earlier at boot (LP: #1819014)
    - Restart services when unconfiguring (LP: #1811868)
    - Use the .nmconnection extension for NM keyfiles (LP: #1817655)
    - Fixed integration tests runner to correctly report failures
    - Enforce integrity for use-routes in networkd backend.
    - Ensure terminal state at end of test (LP: #1817660)
    - Various small test fixes.
    - Fix typos in documentation.
  * debian/control: Update Maintainer for ubuntu upload.

netplan.io (0.95-2) unstable; urgency=medium

  * Set Priority to optional (Closes: #920327).

netplan.io (0.95-1) unstable; urgency=medium

  * New upstream release.
  * Update autopkgtests from the upstream.
  * Add debian/watch following GitHub releases.
  * Add Homepage (Closes: #917233).

netplan.io (0.95) disco; urgency=medium

  * New upstream release:
    - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
    - Added support for setting up IP tunnels; supporting the types: ipip,
      gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
      + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
    - Add support to override networkd UseMTU setting (LP: #1807273)
    - Generate output files in dependency order
    - Refactored unit and integration tests, along with various cleanups.
    - Add DHCP overrides to control route usage and default metric for DHCP
      routes. (LP: #1776228)
    - Mitigate against bad matching on devices behind bonds then they share
      the same MAC from a physical interface. (LP: #1804861)
    - Added snapcraft.yaml.

netplan.io (0.90.1) disco; urgency=medium

  * Do not assume /etc/network exists in postinst, as netbase 5.5 no longer
    creates it.
  * netplan/cli/commands/ip.py: fix a flake.

netplan.io (0.90) disco; urgency=medium

  * New upstream release:
    - build: fixes for building on RPM-based distros
    - build: code prettiness changes (make indentation consistent)
    - Fix device name-changes detection (LP: #1770082)
    - Add support for IPv6 Privacy Extensions (LP: #1750392)
    - Add dhcp{4,6}-overrides to control DNS, NTP, hostname updates via DHCP
      (LP: #1759014)
    - Clarify MAC and MTU setting requirements (LP: #1800668)
    - Various documentation fixes (LP: #1800669)
    -...

[Steve Langasek (vorlon)]

A possible SRU regression has been reported against netplan.io 0.96-0ubuntu0.18.10.2 in LP: #1825206. This version has been rolled back to -proposed while the investigation is ongoing.

[Brian Murray (brian-murray)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.10.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Daniel, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.96-0ubuntu0.18.04.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Mathieu Trudel-Lapierre (cyphermox)]

Still verification-done on bionic and cosmic; this hasn't changed with the new revision in -proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.04.4

---------------
netplan.io (0.96-0ubuntu0.18.04.4) bionic; urgency=medium

  * debian/patches/git_revert_explicit_renderer_def_ebc212a.patch: revert
    commit ebc212a: make renderer values explicit at the end of each parsing
    pass; it breaks "default" renderer behavior when multiple files may set
    a global renderer and expect the last to take effect globally.
    (LP: #1825206)
  * debian/patches/git_reorg_netdef_validation_181b583.patch: correct the
    fallout from the above change: validate netdefs in a single pass at the
    very end of parsing, once we know which is the applicable renderer. This
    makes sure tunnels get validated correctly.

netplan.io (0.96-0ubuntu0.18.04.3) bionic; urgency=medium

  * debian/patches/disable-networkd-tunnels-ipip-gre.patch: disable IPIP and
    GRE tunnel tests; those appear to be broken because neither the kernel nor
    networkd bring up the device automatically as in other releases.

netplan.io (0.96-0ubuntu0.18.04.2) bionic; urgency=medium

  * d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
    Partially revert changes to networkd jobs ordering: leave systemd-networkd
    enabled in multi-user.target instead of network-online.target, as in some
    minimal setups there might be no job requiring network-online.target,
    whereas the natural target to reach for booting is multi-user.target.
    (LP: #1821867)

netplan.io (0.96-0ubuntu0.18.04.1) bionic; urgency=medium

  * Backport netplan.io 0.96 to 18.04.
  * debian/patches/glib_changes.patch: Patch tests to work again on older GLib.
  * debian/control: adjust Depends for bionic / re-add nplan package.

netplan.io (0.96-0ubuntu1) disco; urgency=medium

  * New upstream release 0.96.
    - Moved netplan-wpa@ services to earlier at boot (LP: #1819014)
    - Restart services when unconfiguring (LP: #1811868)
    - Use the .nmconnection extension for NM keyfiles (LP: #1817655)
    - Fixed integration tests runner to correctly report failures
    - Enforce integrity for use-routes in networkd backend.
    - Ensure terminal state at end of test (LP: #1817660)
    - Various small test fixes.
    - Fix typos in documentation.
  * debian/control: Update Maintainer for ubuntu upload.

netplan.io (0.95-2) unstable; urgency=medium

  * Set Priority to optional (Closes: #920327).

netplan.io (0.95-1) unstable; urgency=medium

  * New upstream release.
  * Update autopkgtests from the upstream.
  * Add debian/watch following GitHub releases.
  * Add Homepage (Closes: #917233).

netplan.io (0.95) disco; urgency=medium

  * New upstream release:
    - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
    - Added support for setting up IP tunnels; supporting the types: ipip,
      gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
      + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
    - Add support to override networkd UseMTU setting (LP: #1807273)
    - Generate output files in dependency order
    - Refactored unit and integration tests, along with various cleanups.
    - Add DHCP overrides to control ...

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.96-0ubuntu0.18.10.3

---------------
netplan.io (0.96-0ubuntu0.18.10.3) cosmic; urgency=medium

  * debian/patches/git_revert_explicit_renderer_def_ebc212a.patch: revert
    commit ebc212a: make renderer values explicit at the end of each parsing
    pass; it breaks "default" renderer behavior when multiple files may set
    a global renderer and expect the last to take effect globally.
    (LP: #1825206)
  * debian/patches/git_reorg_netdef_validation_181b583.patch: correct the
    fallout from the above change: validate netdefs in a single pass at the
    very end of parsing, once we know which is the applicable renderer. This
    makes sure tunnels get validated correctly.

netplan.io (0.96-0ubuntu0.18.10.2) cosmic; urgency=medium

  * d/p/0001-Partially-revert-the-change-for-enabling-systemd-net.patch:
    Partially revert changes to networkd jobs ordering: leave systemd-networkd
    enabled in multi-user.target instead of network-online.target, as in some
    minimal setups there might be no job requiring network-online.target,
    whereas the natural target to reach for booting is multi-user.target.
    (LP: #1821867)

netplan.io (0.96-0ubuntu0.18.10.1) cosmic; urgency=medium

  * Backport netplan.io 0.96 to 18.10.
  * debian/patches/glib_changes.patch: Patch tests to work again on older GLib.
  * debian/control: adjust Depends for cosmic / re-add nplan package.

netplan.io (0.96-0ubuntu1) disco; urgency=medium

  * New upstream release 0.96.
    - Moved netplan-wpa@ services to earlier at boot (LP: #1819014)
    - Restart services when unconfiguring (LP: #1811868)
    - Use the .nmconnection extension for NM keyfiles (LP: #1817655)
    - Fixed integration tests runner to correctly report failures
    - Enforce integrity for use-routes in networkd backend.
    - Ensure terminal state at end of test (LP: #1817660)
    - Various small test fixes.
    - Fix typos in documentation.
  * debian/control: Update Maintainer for ubuntu upload.

netplan.io (0.95-2) unstable; urgency=medium

  * Set Priority to optional (Closes: #920327).

netplan.io (0.95-1) unstable; urgency=medium

  * New upstream release.
  * Update autopkgtests from the upstream.
  * Add debian/watch following GitHub releases.
  * Add Homepage (Closes: #917233).

netplan.io (0.95) disco; urgency=medium

  * New upstream release:
    - Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
    - Added support for setting up IP tunnels; supporting the types: ipip,
      gretap, VTI, ISATAP (NetworkManager only), sit, gre, ipip6 and ip6ip6.
      + Fixes sit (ipv6) tunnels using Hurricane Electric (LP: #1799487)
    - Add support to override networkd UseMTU setting (LP: #1807273)
    - Generate output files in dependency order
    - Refactored unit and integration tests, along with various cleanups.
    - Add DHCP overrides to control route usage and default metric for DHCP
      routes. (LP: #1776228)
    - Mitigate against bad matching on devices behind bonds then they share
      the same MAC from a physical interface. (LP: #1804861)
    - Added snapcraft.yaml.

netplan.io (0.90.1) disco; urgency=medium

  * Do ...

[Jamie Lokier (jamie-shareable)]

For what it's worth, I'm still seeing set-name having no affect on a server's only interface.

Server is using Ubuntu 19.04, with netplan.io-0.96-0ubuntu4.1, AMD64 arch. It's a bare-metal server with a single "e1000e" ethernet device. No cloud-init installed.

Config file /etc/netplan/01-netcfg.yaml starts like this:

    network:
      version: 2
      renderer: networkd
      ethernets:
        enp4s0:
          match:
            name: enp4s0
          set-name: eth0
          addresses:
            - $IPV4
            - $IPV6
           (etc.)

The interface is configured adequately in boot, but the interface name is not changed according to "set-name eth0". It just doesn't change, with "netplan apply" or not.

[Christopher Trahey (ctrahey91)]

Is it possible this regressed sometime between Bionic and Focal? I am observing this in 20.04. Early in dmesg I see my interface renamed from eth1 to eno2, then my netplan attempts to rename with a match (on name=eno2) to my desired name ("ceph" in this case). I see syslog message:

systemd-udevd[844]: eno2: Config file /run/systemd/network/10-netplan-eno2.link matches device based on renamed interface name, ignoring

but after boot and login, netplan apply is succsesful.

Steps in #11 do not work, even though I verify the link file is in the new initrd.img at usr/lib/systemd/network/10-netplan-eno2.link

What _did_ work for me, is editing this file first to refer to the eth1 name instead of eno2 (the file was written, I believe, by netplan). After this I can change my netplan to refer to the desired name with no set-name rule. Obvs. I can cut out some steps as I replicate this solution to the other servers.

To summarize: write out /etc/systemd/network/10-netplan-eno2.link in a way that refers to eth1 (instead of eno2) and sets ultimately desired name. update-initramfs. netplan uses desired name without rename rules. I suppose I can/should rename that file to 10-netplan-ceph.link :-)

[Christopher Trahey (ctrahey91)]

Clarifying what worked for me across all the servers where I need this config:

cat <<EOF | tee /etc/systemd/network/10-netplan-ceph.link
[Match]
OriginalName=eth1

[Link]
Name=ceph
WakeOnLan=off
EOF

# Manual: ensure /etc/netplan/NN-FOO.yaml refers to desired name, no set-name:
# network:
# ethernets:
# ...
# ceph:
# addresses:
# - 10.5.12.2/16
#

update-initramfs -u
reboot now