netplan try: ethernet device not reverted

Bug #1768802 reported by Daniel Axtens
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netplan.io (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

I have an ethernet device, with an MTU of 1500:

ubuntu@netplan:~$ ip l
...
3: ens8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:f9:e9:dd brd ff:ff:ff:ff:ff:ff

I try the following config, 1-mtu.yaml:

network:
    version: 2
    ethernets:
        ens8:
            match:
                macaddress: 52:54:00:f9:e9:dd
            addresses:
               - 10.10.10.2/24
            mtu: 1280

I then do netplan try and let it time out and reset:

ubuntu@netplan:~$ sudo netplan try --timeout 10 --config 1-mtu.yaml
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 1 seconds
Reverting.
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket

I then observe that the device has in no way been reverted: it's still up, has the IP and the MTU. To add insult to injury, it's been renamed to eth0:

ubuntu@netplan:~$ ip a
...
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:f9:e9:dd brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.2/24 brd 10.10.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fef9:e9dd/64 scope link
       valid_lft forever preferred_lft forever

I have tested this with virtio and rtl8139 devices in a KVM guest; both exhibit exactly the same behaviour.

Revision history for this message
Daniel Axtens (daxtens) wrote :

Oh, this is with 0.36.1:

ubuntu@netplan:~$ apt list netplan.io
Listing... Done
netplan.io/bionic,now 0.36.1 amd64 [installed,automatic]

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

systemd-networkd won't drop interfaces/ remove addresses for interfaces that are "not managed".

There's some extra work that will be needed to handle some corner cases like this one, to figure out some of the changes and enforcing some of the changes.

Changed in netplan.io (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.