systemd-networkd not renaming devices on boot
- Bionic (18.04)
- Bug #1770082
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Netplan |
Fix Released
|
Undecided
|
Unassigned | ||
cloud-init (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
netplan.io (Ubuntu) |
Fix Released
|
Undecided
|
Mathieu Trudel-Lapierre | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Mathieu Trudel-Lapierre | ||
nplan (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
systemd (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
- 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/
[Match]
MACAddress=
[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,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,
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:/
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/
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
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,
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,
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,
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,
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:
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.
Changed in netplan: | |
status: | New → Confirmed |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
tags: | added: bionic |
description: | updated |
summary: |
- set-name doesn't work on boot, only with netplan apply + systemd-networkd not renaming devices on boot |
description: | updated |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #1 |
Changed in netplan: | |
status: | Confirmed → Incomplete |
Daniel Axtens (daxtens) wrote : | #2 |
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) wrote : | #3 |
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) wrote : Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot | #4 |
Ryan: I removed /etc/netplan/
I've never seen it regenerated.
I also don't see anything in /run/netplan or /run/systemd/
been autogenerated.
I haven't touched anything else generated by cloud-init. When would
cloud-init regenerate a network config file?
Ryan Harper (raharper) wrote : | #5 |
On Wed, May 9, 2018 at 9:13 AM, Daniel Axtens
<email address hidden> wrote:
> Ryan: I removed /etc/netplan/
> 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/
> 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/
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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Ryan Harper (raharper) wrote : | #6 |
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) wrote : | #7 |
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) wrote : | #8 |
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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Daniel Axtens (daxtens) wrote : | #9 |
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.
ubuntu@btest:~$ lsinitramfs /boot/initrd.
lib/systemd/
ubuntu@btest:~$ lsinitramfs /boot/initrd.
ubuntu@btest:~$ lsinitramfs /boot/initrd.
ubuntu@btest:~$ lsinitramfs /boot/initrd.
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) wrote : | #10 |
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/
# copy .link files containing interface naming definitions
mkdir -p $DESTDIR/
find /lib/systemd/
$DESTDIR/
if [ -d /etc/systemd/
find /etc/systemd/
$DESTDIR/
fi
If you create a .link file in /etc/systemd/
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.
>
> ubuntu@btest:~$ lsinitramfs /boot/initrd.
> lib/systemd/
> ubuntu@btest:~$ lsinitramfs /boot/initrd.
> ubuntu@btest:~$ lsinitramfs /boot/initrd.
> ubuntu@btest:~$ lsinitramfs /boot/initrd.
>
> 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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Ryan Harper (raharper) wrote : | #11 |
root@rharper-b1:~# vi /etc/netplan/
# changed the set-name: to eth_lan
root@rharper-b1:~# netplan generate
root@rharper-b1:~# cp /run/systemd/
/etc/systemd/
# just the default link file in the initramfs
root@rharper-b1:~# lsinitramfs /boot/initrd.
lib/systemd/
lib/modules/
lib/udev/
bin/readlink
root@rharper-b1:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.
# now we see the local .link file from /etc copied in.
root@rharper-b1:~# lsinitramfs /boot/initrd.
lib/modules/
lib/systemd/
lib/systemd/
lib/udev/
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/
> # copy .link files containing interface naming definitions
> mkdir -p $DESTDIR/
> find /lib/systemd/
> $DESTDIR/
> if [ -d /etc/systemd/
> find /etc/systemd/
> $DESTDIR/
> fi
>
> If you create a .link file in /etc/systemd/
> 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.
>>
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.
>> lib/systemd/
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.
>> ubuntu@btest:~$ lsinitramfs /boot/initrd.
>>
>> 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:/
>>
>> Title:
>> systemd-networkd not renaming devices on boot
>>
>> To manage notifications about this bug go to:
>> https:/
Daniel Axtens (daxtens) wrote : | #12 |
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/
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) wrote : | #13 |
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/
> 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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Daniel Axtens (daxtens) wrote : | #14 |
Ubuntu Foundations Team Bug Bot (crichton) wrote : | #15 |
The attachment "link-files-
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]
tags: | added: patch |
Daniel Axtens (daxtens) wrote : | #16 |
This is not a full solution. In Xenial this renaming works even if initramfs has *not* been updated and there is no 70-persistent-
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) wrote : | #17 |
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-
> 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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Daniel Axtens (daxtens) wrote : | #18 |
- journalctl -b output on Xenial VM with multiple renames Edit (59.3 KiB, text/plain)
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-
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) wrote : | #19 |
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-
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-
> 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:/
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Daniel Axtens (daxtens) wrote : | #20 |
> 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] [<ffffffff813f3
[ 1.012435] [<ffffffff81706
<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] [<ffffffff813f3
[ 2.336138] [<ffffffff81706
<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-
> 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) wrote : | #21 |
Stefan Beckers privat (stefan-beckers) wrote : | #22 |
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/
But netplan.io saves the configuration in "/run/systemd/
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/
3. cp /run/systemd/
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) wrote : | #23 |
Things seem to work when i change the NamePolicy in the initrd file /lib/systemd/
`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) wrote : | #24 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in systemd (Ubuntu): | |
status: | New → Confirmed |
Ryan Harper (raharper) wrote : | #25 |
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/
> `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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Mike Jonkmans (mjo) wrote : | #26 |
As discussed on https:/
The initrd (!) should have NamePolicy=kernel in /lib/systemd/
Ryan Harper (raharper) wrote : | #27 |
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.
Changed in netplan: | |
status: | Incomplete → Confirmed |
Changed in cloud-init (Ubuntu): | |
status: | New → Confirmed |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #28 |
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) wrote : | #29 |
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) wrote : | #30 |
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) wrote : | #31 |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #32 |
netplan changes are available in git:
Daniel's patch to write udev rules (SRU material):
https:/
Daniel's patch + dropping replug code + rework 'netplan apply' (code for cosmic); in progress for upload to cosmic:
https:/
Mathieu Trudel-Lapierre (cyphermox) wrote : | #33 |
I'm not completely sure where the code lives in cloud-init; it looks a bit like what's in:
cloudinit/
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/
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) wrote : | #34 |
"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:/
>
> Daniel's patch + dropping replug code + rework 'netplan apply' (code for cosmic); in progress for upload to cosmic:
> https:/
>
> --
> You received this bug notification because you are subscribed to
> netplan.
> Matching subscriptions: netplan
> https:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Ryan Harper (raharper) wrote : | #35 |
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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Ryan Harper (raharper) wrote : | #36 |
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/
>
> 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/
> 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:/
>
> Title:
> systemd-networkd not renaming devices on boot
>
> To manage notifications about this bug go to:
> https:/
Changed in netplan.io (Ubuntu): | |
status: | New → In Progress |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
Launchpad Janitor (janitor) wrote : | #37 |
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/integrati
* 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
Changed in netplan.io (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in nplan (Ubuntu): | |
status: | New → Fix Released |
Nicorac (nicorac) wrote : | #38 |
Thanks for the update.
Referring to this duplicate bug (https:/
Or is there a way to install 0.38 on Ubuntu Server 18.04?
Łukasz Zemczak (sil2100) wrote : | #39 |
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.
description: | updated |
Łukasz Zemczak (sil2100) wrote : Please test proposed package | #40 |
Hello Daniel, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
Changed in nplan (Ubuntu Xenial): | |
status: | New → Fix Committed |
tags: | added: verification-needed verification-needed-xenial |
Daniel Axtens (daxtens) wrote : | #41 |
Hi Łukasz,
I couldn't find the package in -proposed, but I was able to download it from the link.
I verified that a device was not renamed with 0.32~16.04.5 but was correctly renamed with 0.32~16.04.6, so for Xenial, verification succeeds.
Regards,
Daniel
tags: |
added: verification-done-xenial removed: verification-needed-xenial |
Steve Langasek (vorlon) wrote : | #42 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
Changed in netplan.io (Ubuntu Bionic): | |
status: | New → Fix Committed |
tags: | added: verification-needed-bionic |
Nicorac (nicorac) wrote : | #43 |
Partially working here on fully updated Ubuntu 18.04 Server on VirtualBox :(
I've enabled -proposed repo and updated both nplan/bionic-
Now interfaces got renamed, but IPs are not assigned at boot (both DHCP and static ones).
Calling "netplan generate && netplan apply" after boot only sets the static IPs while DHCP still remains unset.
# dpkg -s netplan.io
Package: netplan.io
Status: install ok installed
Priority: important
Section: net
Architecture: amd64
Version: 0.36.3
# cat /etc/netplan/
network:
version: 2
renderer: networkd
ethernets:
id0:
match:
macaddress: 08:00:27:6b:d8:91
set-name: eth_static
addresses: [ 1.2.3.4/16 ]
gateway4: 5.6.7.8
id1:
match:
macaddress: 08:00:27:23:68:f5
set-name: eth_dhcp
dhcp4: true
*** (just after boot) ***
# ifconfig -a
eth_dhcp: flags=4098<
ether 08:00:27:23:68:f5 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
eth_static: flags=4098<
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<
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 2 bytes 78 (78.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2 bytes 78 (78.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
*** (after "netplan apply") ***
eth_dhcp: flags=4098<
ether 08:00:27:23:68:f5 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
eth_static: flags=4098<
inet 1.2.3.4 netmask 255.255.0.0 broadcast 1.2.255.255
inet6 fe80::a00:
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<
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 2 bytes 78 (78.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2 bytes 78 (78.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tags: |
added: verification-failed-bionic removed: verification-needed-bionic |
tags: | removed: verification-needed |
tags: |
added: verification-done-bionic removed: verification-failed-bionic |
Daniel Axtens (daxtens) wrote : | #44 |
Hi,
I can verify correct behaviour with renaming, static IPs and DHCP with KVM. I'm about to check some cloud services as well.
Nicorac, are you claiming this is a regression or just an incomplete fix?
If it's just an incomplete fix, I think we should spin that out into another bug and fix it after this SRU goes through.
Regards,
Daniel
Daniel Axtens (daxtens) wrote : | #45 |
Hi,
I have confirmed that the Bionic package works on the cloud service where the bug was originally observed. With this package, the affected migrations now succeed.
Regards,
Daniel
Nicorac (nicorac) wrote : | #46 |
@Daniel: no, it's a regression to me because set-name never worked and now DHCP stopped working too.
But I'm not testing the same environment as you, I'm on VirtualBox and this is my original bug report (linked to this one):
https:/
Daniel Axtens (daxtens) wrote : Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot | #47 |
Hi,
I'm a bit confused then.
This is the netplan config you mentioned:
network:
version: 2
renderer: networkd
ethernets:
id0:
match:
macaddress: 08:00:27:6b:d8:91
set-name: eth_static
addresses: [ 1.2.3.4/16 ]
gateway4: 5.6.7.8
id1:
match:
macaddress: 08:00:27:23:68:f5
set-name: eth_dhcp
dhcp4: true
With the current version (not the -proposed version), my understanding
is that both devices keep their original names, neither device comes
up at all, and neither device will get an IP, dynamic or static. But
if I understand your comment correctly, you're saying that one of the
devices (the one with mac :f5) comes up and gets a DHCP IP? Is that
right? And if so, what is the device called - eth_dhcp or something
else?
Do you have virtualbox guest additions? I wonder if that's doing
something funky. And just checking you don't have ifupdown installed?
Regards,
Daniel
Nicorac (nicorac) wrote : | #48 |
Sorry for the confusion.
Current version (0.36.2):
- both devices not renamed after boot (have original enp.. names)
- static and dynamic IPs correctly assigned
Proposed version (0.36.3):
- both devices correctly renamed after boot:
:91 gets renamed eth_static
:f5 gets renamed to eth_dhcp
- only eth_static got the configured static address, eth_dhcp not configured (need to call "ifconfig -a" to show it)
No VB Additions, just plain Ubuntu Server 18.04 install followed by "apt update && apt dist-upgrade".
Mathieu Trudel-Lapierre (cyphermox) wrote : | #49 |
I'd be a bit surprised if there really was a regression due to the change, we're more likely seeing something going down due to the DHCP server being slow to respond, possibly because it already responded before?
What does the 'networkctl' command show immediately after boot?
Let's continue debugging this on your own bug (1768827).
Nicorac (nicorac) wrote : | #50 |
The behavior is not reproducible, maybe a race condition?
I'm actually not getting IP addres for static interface too :-(
I agree, let's continue there: https:/
Łukasz Zemczak (sil2100) wrote : | #51 |
Since the new issue is tracked in a separate bug and currently only reproducible by the reporter, I am releasing the current update as is. In case this indeed turns out to be a regression, let's consider fixing it with a subsequent upload.
Łukasz Zemczak (sil2100) wrote : Update Released | #52 |
The verification of the Stable Release Update for netplan.io has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Launchpad Janitor (janitor) wrote : | #53 |
This bug was fixed in the package nplan - 0.32~16.04.6
---------------
nplan (0.32~16.04.6) xenial; urgency=medium
[ Mathieu Trudel-Lapierre ]
* tests/integrati
cleanup every time, so later tests don't unnecessarily wait for an
interface not configured to be up. (LP: #1775097)
[ Daniel Axtens ]
* Generate udev rules files to rename devices (LP: #1770082)
Due to a systemd issue[1], using link files to rename interfaces
doesn't work as expected. Link files will not rename an interface
if it was already renamed, and interfaces are renamed in initrd, so
set-name will often not work as expected when rebooting. However,
rules files will cause a renaming, even if the interface has been
renamed in initrd.
-- Mathieu Trudel-Lapierre <email address hidden> Tue, 03 Jul 2018 12:55:11 -0400
Changed in nplan (Ubuntu Xenial): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #54 |
This bug was fixed in the package netplan.io - 0.36.3
---------------
netplan.io (0.36.3) bionic; urgency=medium
* Generate udev rules files to rename devices (LP: #1770082)
Due to a systemd issue[1], using link files to rename interfaces
doesn't work as expected. Link files will not rename an interface
if it was already renamed, and interfaces are renamed in initrd, so
set-name will often not work as expected when rebooting. However,
rules files will cause a renaming, even if the interface has been
renamed in initrd.
* tests/integrati
* tests/integrati
-- Mathieu Trudel-Lapierre <email address hidden> Thu, 05 Jul 2018 16:54:52 -0400
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Changed in netplan: | |
status: | Confirmed → Fix Released |
Marcos (markinholiveira) wrote : | #55 |
This problem still exists in a fresh (minimal) installation of Ubuntu 18.04. To reproduce, just install from mini.iso without selecting any packages at tasksel. I've discovered that if you install ebtables it works as expected. That's why it works if you select an Desktop or Server option at tasksel, because both end up installing ebtables (idk why, but whatever).
Marcos (markinholiveira) wrote : | #56 |
Can't edit, so I'm writing another message. I was wrong about ubuntu-desktop, it does not install ebtables by default, but server does.
Nicorac (nicorac) wrote : | #57 |
Do you mean that removing ebtables (if possible) let rename work properly?
Marcos (markinholiveira) wrote : | #58 |
Yes... I tried multiple times on VirtualBox. Installed from mini.iso without selecting anything, then edited /etc/netplan/
Marcos (markinholiveira) wrote : | #59 |
Nicorac, I misread your message, what I meant to say is that installing ebtables makes netplan to work properly.
Nicorac (nicorac) wrote : | #60 |
Just tried with a fresh installed Ubuntu SERVER 18.04.1.
The interface now got renamed but IP address is not applied, both static and DHCP.
If I run "netplan apply" just after reboot+login, network interface is configured correctly (again, both with static/DHCP address).
-------
Just after reboot + login
-------
# ifconfig -a
eth_lan: flags=4098<
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<
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 14 bytes 910 (910.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14 bytes 910 (910.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
-------
After netplan apply
-------
# netplan apply
# ifconfig -a
eth_lan: flags=4163<
inet 10.0.3.200 netmask 255.255.0.0 broadcast 10.0.255.255
inet6 fe80::a00:
ether 08:00:27:6b:d8:91 txqueuelen 1000 (Ethernet)
RX packets 28739 bytes 2625648 (2.6 MB)
RX errors 0 dropped 3379 overruns 0 frame 0
TX packets 186 bytes 19916 (19.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 197 bytes 14182 (14.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 197 bytes 14182 (14.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
-------
netplan config
-------
# cat /etc/netplan/
# 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
# dhcp4: true
addresses: [ 10.0.3.200/16 ]
gateway4: 10.0.0.1
nameservers:
- 8.8.4.4
I'm going to remove all of this netplan stuff and get back to old working /ets/network/
Nicorac (nicorac) wrote : | #61 |
@Marcos: ebtables is ininfluent on my side.
It is installed with server version and the bug persists both with and without it.
Nicorac (nicorac) wrote : | #62 |
I've tried some workarounds:
- kernel parameter "net.ifnames=0" on kernel commandline: NOT WORKING
- ebtables: NOT WORKING
- add "@reboot /usr/sbin/netplan apply" to root cron: NOT WORKING
The following works on my side:
* create a new unit file: /etc/systemd/
-------
[Unit]
After=syslog.
[Service]
ExecStart=
[Install]
WantedBy=
-------
* enable and start it
# systemctl enable netplan-
# systemctl start netplan-
Łukasz Zemczak (sil2100) wrote : Please test proposed package | #63 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Released → Fix Committed |
tags: |
added: verification-needed verification-needed-bionic removed: verification-done-bionic |
Nicorac (nicorac) wrote : | #64 |
Sorry for being such a buzzkill, but it's still not working on my side :(
=======
Reinstalled 18.04.1 server x64 from scratch in a clean VirtualBox VM.
=======
# lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
=======
Enabled -proposed repo and updated netplan.io
=======
# dpkg -s netplan.io | grep Version
Version: 0.40~18.04.1
=======
Set a very basic network configuration
=======
# cat /etc/netplan/
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:
=======
After reboot the interface is renamed
but IP address is not set
=======
# ifconfig -a
eth_lan: flags=4098<
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<
...
=======
After manually running "netplan apply" (after boot)
things go even worst: network interface is renamed
again to "id0"
=======
# netplan apply
# ifconfig -a
id0: flags=4098<
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<
...
tags: |
added: verification-failed-bionic removed: verification-needed-bionic |
tags: | removed: verification-needed |
Łukasz Zemczak (sil2100) wrote : | #65 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
tags: |
added: verification-needed verification-needed-bionic removed: verification-failed-bionic |
Nicorac (nicorac) wrote : | #66 |
Sorry, still not working here. Same behavior as my previous post.
Maybe it's due to VirtualBox? Haven't tried on my production KDE (Proxmox) yet...
---------------
# dpkg -s netplan.io | grep Version
Version: 0.40~18.04.1
---------------
tags: |
added: verification-failed-bionic removed: verification-needed-bionic |
Nicorac (nicorac) wrote : | #67 |
Wrong cut&paste:
---------------
# dpkg -s netplan.io | grep Version
Version: 0.40.1~18.04.1
---------------
Mathieu Trudel-Lapierre (cyphermox) wrote : | #68 |
Resetting to verification-done for bionic; using netplan.io 0.40.1~18.04.1:
I have run more tests and I can verify that renames at boot are behaving correctly with netplan -- netplan follows exactly the configuration provided on the system:
network:
version: 2
ethernets:
ens6:
match:
mtu: 1500
- 10.3.21.28/20
- 10.3.21.25
- cloud.cyphermox.net
This leads to my system having a single interface "myiface11":
ubuntu@new-man:~$ ip link
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: myiface11: <BROADCAST,
link/ether 52:54:00:ab:37:d8 brd ff:ff:ff:ff:ff:ff
I have removed the duplicate tag from bug 1768827 so we can keep investigating and figure out why this isn't working for Nicorac; it looks like there's something competing with netplan somewhere, either from cloud-init or something else.
tags: |
added: verification-done-bionic removed: verification-failed-bionic |
Daniel Axtens (daxtens) wrote : | #69 |
Hi,
This works on reboot but not so well after the system boots.
Say I have the following file:
network:
version: 2
ethernets:
ens7:
dhcp4: true
match:
If I reboot, everything is fine:
ubuntu@netplan2:~$ ip l
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,
link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: myif1: <BROADCAST,
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff
But if I now change set-name to myif0, I can't get it to change the name 'live'.
If I apply with the interface 'up', nothing happens, which is fine:
ubuntu@netplan2:~$ sudo netplan apply
ubuntu@netplan2:~$ ip l
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,
link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: myif1: <BROADCAST,
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff
But if I bring it down and run netplan apply, the interface is renamed to ens7, not myif0, and it stays down.
ubuntu@netplan2:~$ sudo ip l set dev myif1 down
ubuntu@netplan2:~$ sudo netplan apply
ubuntu@netplan2:~$ ip l
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,
link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: ens7: <BROADCAST,
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff
If I downgrade to 0.36.3, the interface is correctly renamed and brought up:
9: myif0: <BROADCAST,
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff
So not an unqualified success here.
Regards,
Daniel
Łukasz Zemczak (sil2100) wrote : | #70 |
So the bug here is about renaming interfaces on boot and this seems to be resolved by the new upload. Does this regress previous behavior? Did renaming interfaces on a running system work in the previous version and this upload introduces a regression? If not, we should fill in a separate bug and try getting it fixed with the next upload.
Will be waiting with releasing this package until it's clear what's the situation here.
Marcos (markinholiveira) wrote : | #71 |
Just confirmed the regression... It's working as expected on boot, but is renaming to the "ID" key, instead of the "set-name" when live.
E.g. if we have:
ens0p3:
match:
macaddress: 01:02:03:04:05:06
set-name: eth0
It will be renamed to ens0p3 on netplan apply.
eth0:
match:
macaddress: 01:02:03:04:05:06
set-name: ens0p3
It will be renamed to eth0...
So basically, on boot it picks up "set-name", and afterwards it picks the ID. If you keep both equal, no problem, but if have different "ID" and "set-name"...
Łukasz Zemczak (sil2100) wrote : | #72 |
Ok, I also re-read Daniel's comment and I see that he mentioned it working on the previous upload. This really seems like a regression - for the time being let's mark this verification-
tags: |
added: verification-failed-bionic removed: verification-done-bionic |
Marcos (markinholiveira) wrote : | #73 |
After some debugging, I could make it work... I'm not a programmer, so it might be wrong, but it's working:
root@netplan:~# cat fix-bug-1770082.diff
--- a/netplan/
+++ b/netplan/
@@ -170,15 +170,15 @@
link = netifaces.
if driver_name in matches[
- new_name = matches[
- logging.
+ current_name = matches[
+ logging.
- if new_name != interface:
- changes.
+ if current_name != interface:
+ changes.
if macaddress in matches['by-mac']:
- new_name = matches[
- if new_name != interface:
- changes.
+ current_name = matches[
+ if current_name != interface:
+ changes.
return changes
After applying the patch, it's working both on reboot and on netplan apply, with the interface down, of course.
Marcos (markinholiveira) wrote : | #74 |
Actually, sent the wrong patch... this is the right one:
root@netplan:~# cat fix-bug-1770082.diff
--- a/netplan/
+++ b/netplan/
@@ -170,15 +170,15 @@
link = netifaces.
if driver_name in matches[
- new_name = matches[
- logging.
+ current_name = matches[
+ logging.
- if new_name != interface:
- changes.
+ if current_name != newname:
+ changes.
if macaddress in matches['by-mac']:
- new_name = matches[
- if new_name != interface:
- changes.
+ current_name = matches[
+ if current_name != newname:
+ changes.
return changes
Nicorac (nicorac) wrote : | #75 |
IMHO if a "match" option is present (especially with a MAC condition), it should always override the ID.
Marcos (markinholiveira) wrote : | #76 |
I found time to run more tests and discovered that my patches were wrong... And the fix was actually even simpler.
root@netplan:~# cat fix-bug-1770082.diff
Index: b/netplan/
=======
--- a/netplan/
+++ b/netplan/
@@ -140,9 +140,9 @@
driver = match.get('driver')
mac = match.get(
if driver:
- matches[
+ matches[
if mac:
- matches[
+ matches[
# /sys/class/
# /sys/class/
Just changed two words...
I created a pull request on github (https:/
Brian Murray (brian-murray) wrote : | #77 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
tags: |
added: verification-needed-bionic removed: verification-failed-bionic |
Brian Murray (brian-murray) wrote : | #78 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Released → Fix Committed |
tags: | added: verification-needed-cosmic |
Nicorac (nicorac) wrote : | #79 |
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<
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<
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/
# 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:
-------
root@test:~# cat /run/systemd/
[Match]
MACAddress=
[Link]
Name=eth_lan
WakeOnLan=off
-------
root@test:~# cat /run/systemd/
[Match]
MACAddress=
Name=eth_lan
[Network]
LinkLocalAddres
Address=
Gateway=192.168.1.1
DNS=8.8.4.4
-------
=======
=== After manual "netplan apply" ===
=======
root@test:~# ifconfig -a
eth_lan: flags=4163<
inet 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::a00:
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<
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...
tags: |
added: verification-failed-bionic removed: verification-needed-bionic |
Marcos (markinholiveira) wrote : | #80 |
Tested just now... It is working for the subiquity installer version (ubuntu-
Launchpad Janitor (janitor) wrote : | #81 |
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
Changed in netplan.io (Ubuntu): | |
status: | Fix Committed → Fix Released |
description: | updated |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #82 |
Verification-done on bionic with netplan.io 0.40.1~18.04.2:
Using the following config:
network:
version: 2
ethernets:
maas0:
- 10.3.21.29/20
match:
mtu: 1500
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@
ubuntu@
ubuntu@
1: lo: <LOOPBACK,
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,
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:
valid_lft forever preferred_lft forever
ubuntu@
ubuntu@
ubuntu@
RTNETLINK answers: Operation not permitted
ubuntu@
sudo ip link set dev maas0 down
ubuntu@
1: lo: <LOOPBACK,
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,
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@
ubuntu@
1: lo: <LOOPBACK,
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,
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:
valid_lft forever preferred_lft forever
tags: |
added: verification-done-bionic removed: verification-failed-bionic verification-needed |
tags: |
added: verification-needed-xenial removed: verification-done-xenial verification-needed-cosmic |
tags: | removed: verification-needed-xenial |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #83 |
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).
tags: | added: verification-done-cosmic |
Nicorac (nicorac) wrote : | #84 |
@Marcos,#80: ubuntu-
@Mathieu,#82: you've removed the verification-
Interface renaming works but IP address/netmask doesn't.
I'm using ubuntu-
PS: I actually have a production server VM witn netplan-
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) wrote : | #85 |
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) wrote : | #86 |
@Mathieu: I reinstalled my Virtualbox VM (using the ubuntu-
netplan config:
ubuntu@ubuntu:~$ cat /etc/netplan/
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
eth0:
match:
set-name: eth0
dhcp4: yes
Result after reboot:
ubuntu@ubuntu:~$ ip address show
1: lo: <LOOPBACK,
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,
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-
Nicorac (nicorac) wrote : | #87 |
@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) wrote : | #88 |
@Nicorac: Tested with static IP and had same result.
ubuntu@ubuntu:~$ cat /etc/netplan/
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
eth0:
match:
set-name: eth0
dhcp4: no
addresses: [ "192.168.56.2/24" ]
gateway4: 192.168.56.1
ubuntu@ubuntu:~$ ip address show
1: lo: <LOOPBACK,
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,
link/ether 08:00:27:f0:97:15 brd ff:ff:ff:ff:ff:ff
Mathieu Trudel-Lapierre (cyphermox) wrote : | #89 |
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) wrote : | #90 |
@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) wrote : | #91 |
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/integrati
* 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
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Marcos (markinholiveira) wrote : | #92 |
@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) wrote : | #93 |
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
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Committed → Fix Released |
Dmitrii Shcherbakov (dmitriis) wrote : | #94 |
This change introduces a regression: calling netplan apply is not idempotent for bonds, see https:/
Steve Langasek (vorlon) wrote : | #95 |
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.
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Released → Fix Committed |
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Released → Fix Committed |
Adam Conrad (adconrad) wrote : | #96 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
tags: |
added: verification-needed verification-needed-cosmic removed: verification-done-cosmic |
tags: |
added: verification-needed-bionic removed: verification-done-bionic |
Adam Conrad (adconrad) wrote : | #97 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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) wrote : | #98 |
Resetting the tags to verification-done as per the discussion above.
tags: |
added: verification-done-bionic verification-done-cosmic removed: verification-needed verification-needed-bionic verification-needed-cosmic |
Launchpad Janitor (janitor) wrote : | #99 |
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/integrati
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
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #100 |
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/integrati
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/integrati
* 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
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Timo Aaltonen (tjaalton) wrote : | #101 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Released → Fix Committed |
tags: |
added: verification-needed verification-needed-cosmic removed: verification-done-cosmic |
Timo Aaltonen (tjaalton) wrote : | #102 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Released → Fix Committed |
tags: |
added: verification-needed-bionic removed: verification-done-bionic |
Timo Aaltonen (tjaalton) wrote : | #103 |
no need to re-test this on bionic/cosmic
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Committed → Fix Released |
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
tags: |
added: verification-done verification-done-bionic verification-done-cosmic removed: verification-needed verification-needed-bionic verification-needed-cosmic |
Steve Langasek (vorlon) wrote : | #104 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Released → Fix Committed |
tags: |
added: verification-needed verification-needed-cosmic removed: verification-done verification-done-cosmic |
Steve Langasek (vorlon) wrote : | #105 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Released → Fix Committed |
tags: |
added: verification-needed-bionic removed: verification-done-bionic |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #106 |
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.
tags: |
added: verification-done-bionic verification-done-cosmic removed: verification-needed verification-needed-bionic verification-needed-cosmic |
Steve Langasek (vorlon) wrote : | #107 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
tags: |
added: verification-needed verification-needed-bionic removed: verification-done-bionic |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #108 |
This does not need re-testing, already in bionic/cosmic, just closed again due to changelog for this big backport.
tags: |
added: verification-done-bionic removed: verification-needed verification-needed-bionic |
Launchpad Janitor (janitor) wrote : | #109 |
This bug was fixed in the package netplan.io - 0.96-0ubuntu0.
---------------
netplan.io (0.96-0ubuntu0.
* d/p/0001-
Partially revert changes to networkd jobs ordering: leave systemd-networkd
enabled in multi-user.target instead of network-
minimal setups there might be no job requiring network-
whereas the natural target to reach for booting is multi-user.target.
(LP: #1821867)
netplan.io (0.96-0ubuntu0.
* Backport netplan.io 0.96 to 18.10.
* debian/
* 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/
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)
-...
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Committed → Fix Released |
Steve Langasek (vorlon) wrote : | #110 |
A possible SRU regression has been reported against netplan.io 0.96-0ubuntu0.
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Released → Fix Committed |
Brian Murray (brian-murray) wrote : | #111 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into cosmic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
tags: |
added: verification-needed verification-needed-cosmic removed: verification-done-cosmic |
Brian Murray (brian-murray) wrote : | #112 |
Hello Daniel, or anyone else affected,
Accepted netplan.io into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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.
tags: |
added: verification-needed-bionic removed: verification-done-bionic |
Mathieu Trudel-Lapierre (cyphermox) wrote : | #113 |
Still verification-done on bionic and cosmic; this hasn't changed with the new revision in -proposed.
tags: |
added: verification-done-bionic verification-done-cosmic removed: verification-needed verification-needed-bionic verification-needed-cosmic |
Launchpad Janitor (janitor) wrote : | #114 |
This bug was fixed in the package netplan.io - 0.96-0ubuntu0.
---------------
netplan.io (0.96-0ubuntu0.
* debian/
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/
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.
* debian/
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.
* d/p/0001-
Partially revert changes to networkd jobs ordering: leave systemd-networkd
enabled in multi-user.target instead of network-
minimal setups there might be no job requiring network-
whereas the natural target to reach for booting is multi-user.target.
(LP: #1821867)
netplan.io (0.96-0ubuntu0.
* Backport netplan.io 0.96 to 18.04.
* debian/
* 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 ...
Changed in netplan.io (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #115 |
This bug was fixed in the package netplan.io - 0.96-0ubuntu0.
---------------
netplan.io (0.96-0ubuntu0.
* debian/
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/
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.
* d/p/0001-
Partially revert changes to networkd jobs ordering: leave systemd-networkd
enabled in multi-user.target instead of network-
minimal setups there might be no job requiring network-
whereas the natural target to reach for booting is multi-user.target.
(LP: #1821867)
netplan.io (0.96-0ubuntu0.
* Backport netplan.io 0.96 to 18.10.
* debian/
* 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 ...
Changed in netplan.io (Ubuntu Cosmic): | |
status: | Fix Committed → Fix Released |
Jamie Lokier (jamie-shareable) wrote : | #116 |
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.
Config file /etc/netplan/
network:
version: 2
renderer: networkd
ethernets:
enp4s0:
match:
name: enp4s0
set-name: eth0
- $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) wrote : | #117 |
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/
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/
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/
Christopher Trahey (ctrahey91) wrote : | #118 |
Clarifying what worked for me across all the servers where I need this config:
cat <<EOF | tee /etc/systemd/
[Match]
OriginalName=eth1
[Link]
Name=ceph
WakeOnLan=off
EOF
# Manual: ensure /etc/netplan/
# network:
# ethernets:
# ...
# ceph:
# addresses:
# - 10.5.12.2/16
#
update-initramfs -u
reboot now
Changed in systemd (Ubuntu): | |
status: | Confirmed → Invalid |
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?