| 2018-05-09 05:53:07 |
Daniel Axtens |
bug |
|
|
added bug |
| 2018-05-09 05:53:16 |
Daniel Axtens |
netplan: status |
New |
Confirmed |
|
| 2018-05-09 05:53:44 |
Daniel Axtens |
bug |
|
|
added subscriber Dominique Poulain |
| 2018-05-09 06:25:40 |
Daniel Axtens |
bug |
|
|
added subscriber Mark Thomas |
| 2018-05-09 07:13:37 |
Daniel Axtens |
description |
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called crazy3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 07:47:18 |
Daniel Axtens |
description |
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be named to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
Oddly, while it doesn't work on reboot, it does work if you unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 07:47:32 |
Daniel Axtens |
description |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be named to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
Oddly, while it doesn't work on reboot, it does work if you unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
Oddly, while it doesn't work on reboot, it does work if you unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 07:48:21 |
Daniel Axtens |
description |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
Oddly, while it doesn't work on reboot, it does work if you unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
Oddly, while it doesn't work on reboot, it does work if you unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 07:51:26 |
Daniel Axtens |
description |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
Oddly, while it doesn't work on reboot, it does work if you unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 07:51:59 |
Daniel Axtens |
tags |
|
bionic |
|
| 2018-05-09 07:52:40 |
Daniel Axtens |
bug task added |
|
systemd (Ubuntu) |
|
| 2018-05-09 07:55:21 |
Daniel Axtens |
description |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 08:07:03 |
Daniel Axtens |
summary |
set-name doesn't work on boot, only with netplan apply |
systemd-networkd not renaming devices on boot |
|
| 2018-05-09 08:12:23 |
Daniel Axtens |
description |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-05-09 13:43:20 |
Mathieu Trudel-Lapierre |
netplan: status |
Confirmed |
Incomplete |
|
| 2018-05-14 04:41:29 |
Daniel Axtens |
attachment added |
|
link-files-in-run.debdiff https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139062/+files/link-files-in-run.debdiff |
|
| 2018-05-14 08:21:39 |
Ubuntu Foundations Team Bug Bot |
tags |
bionic |
bionic patch |
|
| 2018-05-14 08:21:47 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2018-05-14 14:44:39 |
Alexis Howells |
bug |
|
|
added subscriber Alexis Howells |
| 2018-05-14 14:53:24 |
Nicorac |
bug |
|
|
added subscriber Nicorac |
| 2018-05-15 17:29:26 |
Daniel Axtens |
attachment added |
|
journalctl -b output on Xenial VM with multiple renames https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139894/+files/journalctl-b.txt |
|
| 2018-05-16 01:52:58 |
Daniel Axtens |
bug watch added |
|
https://github.com/systemd/systemd/issues/9006 |
|
| 2018-05-17 17:05:46 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2018-05-17 17:45:48 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2018-05-24 11:57:38 |
Launchpad Janitor |
systemd (Ubuntu): status |
New |
Confirmed |
|
| 2018-05-24 11:59:10 |
Mike Jonkmans |
bug |
|
|
added subscriber Mike Jonkmans |
| 2018-05-25 13:36:52 |
Mathieu Trudel-Lapierre |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2018-05-25 13:37:04 |
Mathieu Trudel-Lapierre |
netplan: status |
Incomplete |
Confirmed |
|
| 2018-05-25 13:37:11 |
Mathieu Trudel-Lapierre |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2018-05-25 13:51:57 |
Mathieu Trudel-Lapierre |
attachment added |
|
draft systemd patch to skip should_rename(), adds extra debug info https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1770082/+attachment/5144272/+files/debug.patch |
|
| 2018-05-25 17:56:58 |
Mathieu Trudel-Lapierre |
bug task added |
|
netplan.io (Ubuntu) |
|
| 2018-05-25 17:57:10 |
Mathieu Trudel-Lapierre |
netplan.io (Ubuntu): status |
New |
In Progress |
|
| 2018-05-25 17:57:14 |
Mathieu Trudel-Lapierre |
netplan.io (Ubuntu): assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2018-06-14 03:19:13 |
Will |
bug |
|
|
added subscriber Will |
| 2018-06-23 10:25:53 |
skettler |
bug |
|
|
added subscriber skettler |
| 2018-06-25 04:18:29 |
Nathan Lutchansky |
bug |
|
|
added subscriber Nathan Lutchansky |
| 2018-06-29 15:19:33 |
Launchpad Janitor |
netplan.io (Ubuntu): status |
In Progress |
Fix Released |
|
| 2018-06-29 17:25:53 |
Mathieu Trudel-Lapierre |
bug task added |
|
nplan (Ubuntu) |
|
| 2018-06-29 17:26:04 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu): status |
New |
Fix Released |
|
| 2018-07-05 13:31:49 |
Mathieu Trudel-Lapierre |
description |
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying different settings to the network interfaces. Changes in settings on network interfaces, missing parameters (especially on bonds, bridges) should be investigated as potential regressions. Other failures to apply network settings might also happen if there's a race between applying renames via the udev rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-07-05 14:59:17 |
Łukasz Zemczak |
nplan (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2018-07-05 14:59:19 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-07-05 14:59:20 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2018-07-05 14:59:24 |
Łukasz Zemczak |
tags |
bionic patch |
bionic patch verification-needed verification-needed-xenial |
|
| 2018-07-05 22:06:23 |
Simon Quigley |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2018-07-06 01:59:33 |
Daniel Axtens |
tags |
bionic patch verification-needed verification-needed-xenial |
bionic patch verification-done-xenial verification-needed |
|
| 2018-07-06 18:43:28 |
Steve Langasek |
netplan.io (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2018-07-06 18:43:38 |
Steve Langasek |
tags |
bionic patch verification-done-xenial verification-needed |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
|
| 2018-07-08 10:25:29 |
Nicorac |
tags |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
|
| 2018-07-08 10:25:42 |
Nicorac |
tags |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
bionic patch verification-done-xenial verification-failed-bionic |
|
| 2018-07-09 00:49:43 |
Daniel Axtens |
tags |
bionic patch verification-done-xenial verification-failed-bionic |
bionic patch verification-done-bionic verification-done-xenial |
|
| 2018-07-16 15:15:16 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-07-16 15:16:03 |
Launchpad Janitor |
nplan (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-07-16 15:25:21 |
Launchpad Janitor |
netplan.io (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-20 08:18:05 |
Daniel Axtens |
netplan: status |
Confirmed |
Fix Released |
|
| 2018-07-26 05:57:18 |
Steve Dodd |
bug |
|
|
added subscriber Steve Dodd |
| 2018-08-29 11:43:53 |
John Morton |
bug |
|
|
added subscriber John Morton |
| 2018-09-10 13:59:58 |
Marcos |
bug |
|
|
added subscriber Marcos |
| 2018-09-28 16:35:35 |
Łukasz Zemczak |
netplan.io (Ubuntu Bionic): status |
Fix Released |
Fix Committed |
|
| 2018-09-28 16:35:38 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-09-28 16:35:47 |
Łukasz Zemczak |
tags |
bionic patch verification-done-bionic verification-done-xenial |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
|
| 2018-10-01 14:40:31 |
Nicorac |
tags |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
|
| 2018-10-01 14:40:47 |
Nicorac |
tags |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
bionic patch verification-done-xenial verification-failed-bionic |
|
| 2018-10-04 18:25:50 |
Łukasz Zemczak |
tags |
bionic patch verification-done-xenial verification-failed-bionic |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
|
| 2018-10-05 08:28:33 |
Nicorac |
tags |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
|
| 2018-10-09 20:20:54 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
bionic patch verification-done-bionic verification-done-xenial verification-needed |
|
| 2018-10-11 12:29:48 |
Łukasz Zemczak |
tags |
bionic patch verification-done-bionic verification-done-xenial verification-needed |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
|
| 2018-10-23 22:01:06 |
Brian Murray |
tags |
bionic patch verification-done-xenial verification-failed-bionic verification-needed |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
|
| 2018-10-23 22:18:35 |
Brian Murray |
netplan.io (Ubuntu Cosmic): status |
Fix Released |
Fix Committed |
|
| 2018-10-23 22:18:46 |
Brian Murray |
tags |
bionic patch verification-done-xenial verification-needed verification-needed-bionic |
bionic patch verification-done-xenial verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2018-10-24 13:03:24 |
Nicorac |
tags |
bionic patch verification-done-xenial verification-needed verification-needed-bionic verification-needed-cosmic |
bionic patch verification-done-xenial verification-failed-bionic verification-needed verification-needed-cosmic |
|
| 2018-10-26 12:53:05 |
Simon Déziel |
bug |
|
|
added subscriber Simon Déziel |
| 2018-10-26 15:46:14 |
James Gregory-Monk |
bug |
|
|
added subscriber James Gregory-Monk |
| 2018-10-31 23:48:22 |
Launchpad Janitor |
netplan.io (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2018-11-01 16:46:01 |
Mathieu Trudel-Lapierre |
description |
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying different settings to the network interfaces. Changes in settings on network interfaces, missing parameters (especially on bonds, bridges) should be investigated as potential regressions. Other failures to apply network settings might also happen if there's a race between applying renames via the udev rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying different settings to the network interfaces. Changes in settings on network interfaces, missing parameters (especially on bonds, bridges) should be investigated as potential regressions. Other failures to apply network settings might also happen if there's a race between applying renames via the udev rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create /etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm still trying to hunt down.
This breaks some forms of migration in certain cloud environments. |
|
| 2018-11-01 16:51:55 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-done-xenial verification-failed-bionic verification-needed verification-needed-cosmic |
bionic patch verification-done-bionic verification-done-xenial verification-needed-cosmic |
|
| 2018-11-01 16:54:20 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-done-bionic verification-done-xenial verification-needed-cosmic |
bionic patch verification-done-bionic verification-needed-xenial |
|
| 2018-11-01 16:59:38 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-done-bionic verification-needed-xenial |
bionic patch verification-done-bionic |
|
| 2018-11-01 17:21:29 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-done-bionic |
bionic patch verification-done-bionic verification-done-cosmic |
|
| 2018-11-05 18:42:39 |
Alex Tomlins |
bug |
|
|
added subscriber Alex Tomlins |
| 2018-11-06 18:13:46 |
Launchpad Janitor |
netplan.io (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-11-07 13:29:24 |
Launchpad Janitor |
netplan.io (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-11-08 17:03:54 |
Steve Langasek |
netplan.io (Ubuntu Bionic): status |
Fix Released |
Fix Committed |
|
| 2018-11-08 17:04:10 |
Steve Langasek |
netplan.io (Ubuntu Cosmic): status |
Fix Released |
Fix Committed |
|
| 2018-11-26 19:21:23 |
Adam Conrad |
tags |
bionic patch verification-done-bionic verification-done-cosmic |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2018-11-26 19:24:52 |
Adam Conrad |
tags |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2018-11-29 14:51:57 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
bionic patch verification-done-bionic verification-done-cosmic |
|
| 2018-12-04 20:22:29 |
Launchpad Janitor |
netplan.io (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-12-05 18:47:48 |
Launchpad Janitor |
netplan.io (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-02-20 14:34:36 |
Luigi Calligaris |
bug |
|
|
added subscriber Luigi Calligaris |
| 2019-03-22 09:10:55 |
Timo Aaltonen |
netplan.io (Ubuntu Cosmic): status |
Fix Released |
Fix Committed |
|
| 2019-03-22 09:11:09 |
Timo Aaltonen |
tags |
bionic patch verification-done-bionic verification-done-cosmic |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2019-03-22 09:18:17 |
Timo Aaltonen |
netplan.io (Ubuntu Bionic): status |
Fix Released |
Fix Committed |
|
| 2019-03-22 09:18:25 |
Timo Aaltonen |
tags |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2019-03-22 09:21:07 |
Timo Aaltonen |
netplan.io (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-03-22 09:21:18 |
Timo Aaltonen |
netplan.io (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-03-22 09:21:45 |
Timo Aaltonen |
tags |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
bionic patch verification-done verification-done-bionic verification-done-cosmic |
|
| 2019-03-29 01:14:33 |
Steve Langasek |
netplan.io (Ubuntu Cosmic): status |
Fix Released |
Fix Committed |
|
| 2019-03-29 01:14:46 |
Steve Langasek |
tags |
bionic patch verification-done verification-done-bionic verification-done-cosmic |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2019-03-29 01:21:13 |
Steve Langasek |
netplan.io (Ubuntu Bionic): status |
Fix Released |
Fix Committed |
|
| 2019-03-29 01:21:24 |
Steve Langasek |
tags |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2019-04-02 15:16:23 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
bionic patch verification-done-bionic verification-done-cosmic |
|
| 2019-04-08 15:19:31 |
Dan Streetman |
removed subscriber Dan Streetman |
|
|
|
| 2019-04-10 21:19:56 |
Steve Langasek |
tags |
bionic patch verification-done-bionic verification-done-cosmic |
bionic patch verification-done-cosmic verification-needed verification-needed-bionic |
|
| 2019-04-11 18:51:09 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-done-cosmic verification-needed verification-needed-bionic |
bionic patch verification-done-bionic verification-done-cosmic |
|
| 2019-04-15 22:32:43 |
Launchpad Janitor |
netplan.io (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-04-15 23:18:34 |
John Morton |
removed subscriber John Morton |
|
|
|
| 2019-04-16 13:20:03 |
James Gregory-Monk |
removed subscriber James Gregory-Monk |
|
|
|
| 2019-04-18 23:38:55 |
Steve Langasek |
netplan.io (Ubuntu Cosmic): status |
Fix Released |
Fix Committed |
|
| 2019-04-30 21:03:07 |
Brian Murray |
tags |
bionic patch verification-done-bionic verification-done-cosmic |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2019-04-30 21:57:07 |
Brian Murray |
tags |
bionic patch verification-done-bionic verification-needed verification-needed-cosmic |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2019-05-06 19:53:06 |
Mathieu Trudel-Lapierre |
tags |
bionic patch verification-needed verification-needed-bionic verification-needed-cosmic |
bionic patch verification-done-bionic verification-done-cosmic |
|
| 2019-05-08 00:00:42 |
Launchpad Janitor |
netplan.io (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-05-08 00:01:20 |
Launchpad Janitor |
netplan.io (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-05-13 18:44:18 |
Jamie Lokier |
bug |
|
|
added subscriber Jamie Lokier |
| 2023-03-28 16:51:01 |
Alberto Contreras |
bug |
|
|
added subscriber Alberto Contreras |
| 2023-06-12 20:21:15 |
Nick Rosbrook |
systemd (Ubuntu): status |
Confirmed |
Invalid |
|
