netplan crashes on UbuntuCore with the network-manager snap installed

Bug #1959570 reported by Michael Vogt
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Netplan
Fix Released
Undecided
Lukas Märdian
netplan.io (Ubuntu)
Fix Released
High
Unassigned
Focal
Fix Released
Undecided
Unassigned
Jammy
Won't Fix
Undecided
Unassigned
Kinetic
Invalid
Undecided
Unassigned
Lunar
Fix Released
High
Unassigned

Bug Description

[ Impact ]

 * When using the netplan-dbus API on Ubuntu Core and the network-manager renderer (NM snap) the "netplan-dbus" application will crash. Leaving the device unreachable.

 * Netplan's CLI is unable to find the network-manager.nmcli binary from the NetworkManager snap, as it's not in netplan-dbus's PATH (nor Python's default BINDIR), therefore it cannot properly restart NM's connections to re-activate the network after changes were applied.

[ Test Plan ]

==============================
Boot an Ubuntu Core 20 system, which this fix as part of the core20 base snap
==============================
$ snap install network-manager --channel=20/stable
$ nmcli # VERIFY br54 is not there
ens3: connected to netplan-ens3
        "ens3"
        ethernet (virtio_net), 52:54:00:12:34:56, hw, mtu 1500
        ip4 default
        inet4 10.0.2.15/24
        route4 0.0.0.0/0
        route4 10.0.2.0/24
        inet6 fe80::5054:ff:fe12:3456/64
        route6 fe80::/64

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 10.0.2.3
        interface: ens3
$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=true
==============================
 Network/SSH connection will be interrupted briefly, but reconnect after some seconds.
==============================
$ netplan get # VERIFY br54 is there
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    ens3:
      dhcp4: true
  bridges:
    br54:
      dhcp4: true
$ sudo journalctl | grep FileNotFound # EMPTY => no errors
$ nmcli # VERIFY br54 is there
ens3: connected to netplan-ens3
        "ens3"
        ethernet (virtio_net), 52:54:00:12:34:56, hw, mtu 1500
        ip4 default, ip6 default
        inet4 10.0.2.15/24
        route4 0.0.0.0/0
        route4 10.0.2.0/24
        inet6 fec0::5054:ff:fe12:3456/64
        inet6 fe80::5054:ff:fe12:3456/64
        route6 fe80::/64
        route6 ::/0
        route6 fec0::/64

br54: connecting (getting IP configuration) to netplan-br54
        "br54"
        bridge, 12:E6:74:FA:8A:75, sw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 10.0.2.3
        interface: ens3

[ Test Plan 2 "Classic" ]

# Prepare environment with NetworkManager installed and the 'nmcli' binary moved to /snap/bin/nmcli (outside of PATH and outside of Python's default/fallback BINDIR).
$ apt install network-manager
$ mv /usr/bin/nmcli /snap/bin/nmcli

$ netplan get
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
$ netplan set network.renderer=NetworkManager # change global renderer to NM
$ netplan set network.bridges.br54.addresses=[10.0.0.20/24]
$ netplan get
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eth0:
      dhcp4: true
  bridges:
    br54:
      addresses:
      - "10.0.0.20/24"
$ env -u PATH /usr/sbin/netplan try # Try-Apply the configuration

=> This should NOT crash!
=> Check that the "netplan-br54" connection is "connected" and the "br54" got created correctly with IP address 10.0.0.20/24:

$ /snap/bin/nmcli d show br54
GENERAL.DEVICE: br54
GENERAL.TYPE: bridge
GENERAL.HWADDR: 6E:70:F7:76:39:67
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: netplan-br54
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]: 10.0.0.20/24
IP4.GATEWAY: --
IP4.ROUTE[1]: dst = 10.0.0.0/24, nh = 0.0.0.0, mt = 425
$ ip addr show br54
5: br54: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 6e:70:f7:76:39:67 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.20/24 brd 10.0.0.255 scope global noprefixroute br54
       valid_lft forever preferred_lft forever

# Running a similar test through 'netplan-dbus'
$ killall netplan-dbus
$ env -u PATH /usr/lib/netplan/netplan-dbus &
$ busctl call io.netplan.Netplan /io/netplan/Netplan io.netplan.Netplan Config
o "/io/netplan/Netplan/config/UV0ID2"
$ busctl call io.netplan.Netplan /io/netplan/Netplan/config/UV0ID2 io.netplan.Netplan.Config Try u 120
b true
$ busctl call io.netplan.Netplan /io/netplan/Netplan/config/UV0ID2 io.netplan.Netplan.Config Apply
b true

=> Make sure the 'netplan-dbus' binary did not crash.

[ Where problems could occur ]

 * Netplan is a core component, thus changing it bears a high risk
 * This upload modifies Netplan's CLI only, therefor the system boot-up and initial network connection should not be affect if anything goes wrong.
 * Netplan's CLI could be affected, breaking the snapd integration (dbus-netplan) and CLI commands like "netplan apply"

[ Other Info ]

 * This is addressed in Jammy via bug #2025519 (SRU/backport of 0.106.1)
 * This has been fixed upstream in https://github.com/canonical/netplan/pull/336
 * A test PPA is available here: https://launchpad.net/~slyon/+archive/ubuntu/lp1959570

=== original bug report ===

When using the netplan-dbus API on Ubuntu Core and the network-manager renderer the "netplan-dbus" appication will crash. To reproduce take a UC20 or UC22 system and run:

```
$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=true
```
(which in effect just drives the dbus API of netplan).

After that the network is lost. When manually restarting it the error is:
```
error: cannot perform the following tasks:
- Run configure hook of "core" snap (run hook "configure": cannot try netplan config: no specific reason returned from netplan and cannot cancel netplan config: Unknown object '/io/netplan/Netplan/config/VDDSG1'.)
```

and the journal reports:
```
Jan 31 10:46:04 ubuntu sudo[1746]: mvo : TTY=pts/0 ; PWD=/home/mvo ; USER=root ; COMMAND=/usr/bin/snap set system system.network.netplan.network.bridges.br54.dhcp4=true
Jan 31 10:46:04 ubuntu sudo[1746]: pam_unix(sudo:session): session opened for user root(uid=0) by mvo(uid=1000)
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: Traceback (most recent call last):
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 99, in command_try
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: NetplanApply().command_apply(run_generate=True, sync=True, exit_on_error=False, state_dir=self.state)
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/commands/apply.py", line 272, in command_apply
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: if b'\nconnected' in subprocess.check_output(cmd, env=env):
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 505, in run
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: with Popen(*popenargs, **kwargs) as process:
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 951, in __init__
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self._execute_child(args, executable, preexec_fn, close_fds,
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 1821, in _execute_child
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: raise child_exception_type(errno_num, err_msg, err_filename)
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: FileNotFoundError: [Errno 2] No such file or directory: 'nmcli'
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: During handling of the above exception, another exception occurred:
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: Traceback (most recent call last):
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/sbin/netplan", line 23, in <module>
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: netplan.main()
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/core.py", line 50, in main
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self.run_command()
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/utils.py", line 315, in run_command
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self.func()
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 81, in run
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self.run_command()
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/utils.py", line 315, in run_command
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self.func()
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 113, in command_try
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self.revert()
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 143, in revert
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: NetplanApply().command_apply(run_generate=False, sync=True, exit_on_error=False, state_dir=tempdir)
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/share/netplan/netplan/cli/commands/apply.py", line 272, in command_apply
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: if b'\nconnected' in subprocess.check_output(cmd, env=env):
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 505, in run
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: with Popen(*popenargs, **kwargs) as process:
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 951, in __init__
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: self._execute_child(args, executable, preexec_fn, close_fds,
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: File "/usr/lib/python3.9/subprocess.py", line 1821, in _execute_child
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: raise child_exception_type(errno_num, err_msg, err_filename)
Jan 31 10:46:05 ubuntu io.netplan.Netplan[1763]: FileNotFoundError: [Errno 2] No such file or directory: 'nmcli'
Jan 31 10:46:10 ubuntu io.netplan.Netplan[884]: 'netplan try' exited with status: 0
Jan 31 10:46:10 ubuntu snapd[605]: taskrunner.go:271: [change 13 "Run configure hook of \"core\" snap" task] failed: run hook "configure": cannot try netplan config: no specific reason returned from netplan and cannot cancel netplan config: Unknown object '/io/netplan/Netplan/config/LX32G1'.
```

The full journal log is attached.

I guess it's a bit the question if this is a netplan or a nm-snap bug (it might need to provide an nmcli alias?). But in any case the crash and losing network is worth fixing regardless I think.

Fwiw, I also suspect this is the issue that prevents my spread tests in https://github.com/snapcore/snapd/compare/master...mvo5:netplan-read-write-nm?expand=1 from working.

Revision history for this message
Michael Vogt (mvo) wrote :
description: updated
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

FTR, there is an alias registered in the store for network-mananger.nmcli

Revision history for this message
Lukas Märdian (slyon) wrote :

There seems to be a patch in place (for a long time) to handle the fallback to network-manager.nmcli. I wonder why it does not work (anymore)?

https://github.com/canonical/netplan/commit/443039b5bd71152b9848c6df096300097e343466

@alfonsosanchezbeato do you think it would be an option to expose the nmcli command from the NM snap?

tags: added: fr-2041
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in netplan.io (Ubuntu):
status: New → Confirmed
Revision history for this message
Isaac True (itrue) wrote :

Hi all,

We have a customer running into this same issue. Is a fix for this on the radar at all?

In the meantime, I've suggested that they just use `netplan set` directly as a workaround.

Revision history for this message
Lukas Märdian (slyon) wrote :

I do not yet fully understand what's going on here.

The 'nmcli' command is exported from the network-manager snap and can be called from the shell without a problem. So I have the impression that for some reason the call stack/execution environment is different here.

AFAIU "snap set" drives netplan, using its DBus API, so is calling "io.netplan.Netplan.Try/Apply" eventually. This will automatically start the "netplan-dbus" process, which will spawn the "netplan apply" command.

The "netplan apply" command has some special case logic if execute inside a snap (detected by reading the "SNAP" environment variable), if inside a snap, it will re-execute itself, using the o.netplan.Netplan.Apply DBus API, in order to "break" out of the snap confinement and be executed in the Core20/22 root system.

=> See we might have an infinite loop here, if the SNAP environment variable is not detected/passed correctly.

When the "netplan apply" command is excuted outside a snap in the Core20/22 base system, it will apply its changes and restart systemd-networkd.service and NetworkManager.service (or the respecitive service that is provided by the network-manager snap) and call into "nmcli" to wait for it to be ready.

For some reason it seems to be unable to find the "nmcli" binary in its PATH, so my assumption is that it is not able to break out of the snap, but rather is executed within the snapd snap's confinement.

This needs more investigation to fully understand what's going on.

Revision history for this message
Lukas Märdian (slyon) wrote :

After some more investigation in snappy land, I think we have two stacked problems here:

1) The netplan-dbus daemon doesn't have PATH set in its environment, thus not finding the `nmcli` or `network-manager.nmlci` binary:

slyon@ubuntu:~$ ps faux | grep netplan
slyon 938 0.0 0.0 5188 720 pts/0 S+ 16:55 0:00 \_ grep --color=auto netplan
root 830 0.0 0.2 11200 4440 ? S 16:54 0:00 /lib/netplan/netplan-dbus
slyon@ubuntu:~$ sudo cat /proc/830/environ
DBUS_STARTER_ADDRESS=unix:path=/var/run/dbus/system_bus_socketDBUS_STARTER_BUS_TYPE=system

2) Ubuntu Core being slow (probably due to the repeated 'run configure hook of "core" snap' action). When first calling into nmcli, the NM service is not yet up and running, thus crashing the subprocess.check_output(nmcli...) command. When patched to handle nmcli's "not running" return code (8) gracefully, giving some more time generally and adding some debug output, I can see the following output:

```diff
             utils.systemctl_network_manager('start', sync=sync)
             if sync:
                 # wait up to 2 sec for 'STATE=connected (site/local-only)' or
                 # 'STATE=connected' to appear in 'nmcli general' STATE
                 env = dict(os.environ, LC_ALL='C')
                 cmd = ['nmcli', 'general', 'status']
                 for _ in range(20):
- if b'\nconnected' in subprocess.check_output(cmd, env=env):
+ sys.stderr.write("ITER\n")
+ out = subprocess.run(cmd, capture_output=True, universal_newlines=True, env=env)
+ sys.stderr.write(str(out.returncode)+": "+str(out.stdout)+"\n"+str(out.stderr)+"\n")
+ sys.stderr.flush()
+ if out.returncode == 8:
+ time.sleep(1)
+ continue
+ if '\nconnected' in str(out.stdout):
                         break
- time.sleep(0.1)
+ time.sleep(0.5)
```

OUTPUT:

slyon@ubuntu:~$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=false
Run configure hook of "core" snap \
ITER
Run configure hook of "core" snap |
8:
Error: NetworkManager is not running.

Run configure hook of "core" snap –
ITER
Run configure hook of "core" snap /
0: STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
disconnected none enabled enabled enabled enabled

Run configure hook of "core" snap –
ITER
Run configure hook of "core" snap \
0: STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
connected full enabled enabled enabled enabled

PS: launched `netplan-dbus` manually (to make the PATH & environment from my shell available) and patched the apply.py command to add debug output in a running core20 snap, by using `sudo mount -o bind apply.py /usr/share/netplan/netplan/cli/commands/apply.py`

Revision history for this message
Lukas Märdian (slyon) wrote :
Changed in netplan.io (Ubuntu):
status: Confirmed → In Progress
status: In Progress → Confirmed
Changed in netplan:
status: New → In Progress
assignee: nobody → Lukas Märdian (slyon)
Changed in netplan.io (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
Lukas Märdian (slyon) wrote :

The fix from PR#336 seems to be working generally.

There's still a brief interruption of the network connectivity, while restarting the "snap.network-manager.networkmanager.service" daemon (obviously), but the SSH connection is recovered after a few seconds.

I've built a core22 base snap, using https://launchpad.net/~slyon/+archive/ubuntu/lp1959570 and a UC22 image out of this to run this test (all executed over an SSH connection):

slyon@ubuntu:~$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=true
slyon@ubuntu:~$ sudo netplan get
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp0s2:
      dhcp4: true
  bridges:
    br54:
      dhcp4: true
slyon@ubuntu:~$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=false
slyon@ubuntu:~$ sudo netplan get
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp0s2:
      dhcp4: true
  bridges:
    br54:
      dhcp4: false

Lukas Märdian (slyon)
Changed in netplan:
status: In Progress → Fix Committed
Revision history for this message
Lukas Märdian (slyon) wrote :

Fixed upstream and uploaded into Lunar as 0.106-0ubuntu3.

Not relevant for Kinetic, due to affecting Ubuntu Core (based on LTS releases). Supposed to be backported into Jammy via Netplan's 0.106 SRU.

Changed in netplan.io (Ubuntu Lunar):
status: Triaged → Fix Committed
Changed in netplan.io (Ubuntu Kinetic):
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netplan.io - 0.106-0ubuntu3

---------------
netplan.io (0.106-0ubuntu3) lunar; urgency=medium

  * Cherry-pick upstream commit fc12872 (PR#336) to fix crash in 'snapd set'
    (LP: #1959570)

 -- Lukas Märdian <email address hidden> Mon, 03 Apr 2023 16:29:22 +0200

Changed in netplan.io (Ubuntu Lunar):
status: Fix Committed → Fix Released
Lukas Märdian (slyon)
Changed in netplan:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in netplan.io (Ubuntu Focal):
status: New → Confirmed
Changed in netplan.io (Ubuntu Jammy):
status: New → Confirmed
Lukas Märdian (slyon)
tags: added: sru-next
Lukas Märdian (slyon)
tags: added: foundations-todo
Revision history for this message
Lukas Märdian (slyon) wrote :

Jammy is addressed via the 0.106.1 backport in bug #2025519

Changed in netplan.io (Ubuntu Jammy):
status: Confirmed → Won't Fix
Revision history for this message
Lukas Märdian (slyon) wrote :

I've prepared a Focal upload in https://launchpad.net/~slyon/+archive/ubuntu/lp1959570/+packages, which seems to be working fine, after building a core20 base snap + UC20 image from it.

$ snap install network-manager --channel=20/stable
$ nmcli
ens3: connected to netplan-ens3
        "ens3"
        ethernet (virtio_net), 52:54:00:12:34:56, hw, mtu 1500
        ip4 default
        inet4 10.0.2.15/24
        route4 0.0.0.0/0
        route4 10.0.2.0/24
        inet6 fe80::5054:ff:fe12:3456/64
        route6 fe80::/64

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 10.0.2.3
        interface: ens3
$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=true
==============================
 Network connection will be interrupted briefly, but reconnect after some seconds.
==============================
$ netplan get
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    ens3:
      dhcp4: true
  bridges:
    br54:
      dhcp4: true
$ sudo journalctl | grep FileNotFound # EMPTY
$ nmcli
ens3: connected to netplan-ens3
        "ens3"
        ethernet (virtio_net), 52:54:00:12:34:56, hw, mtu 1500
        ip4 default, ip6 default
        inet4 10.0.2.15/24
        route4 0.0.0.0/0
        route4 10.0.2.0/24
        inet6 fec0::5054:ff:fe12:3456/64
        inet6 fe80::5054:ff:fe12:3456/64
        route6 fe80::/64
        route6 ::/0
        route6 fec0::/64

br54: connecting (getting IP configuration) to netplan-br54
        "br54"
        bridge, 12:E6:74:FA:8A:75, sw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 10.0.2.3
        interface: ens3

Revision history for this message
Lukas Märdian (slyon) wrote :
description: updated
description: updated
description: updated
Changed in netplan.io (Ubuntu Focal):
status: Confirmed → In Progress
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Would it be possible to have a special test case for this as part of the unit-testing/integration-testing suite? Also, I'd feel a bit better if as part of the validation we did some smoke testing of the CLI on a non-core related system.

Lukas Märdian (slyon)
description: updated
Lukas Märdian (slyon)
description: updated
Lukas Märdian (slyon)
description: updated
description: updated
Lukas Märdian (slyon)
description: updated
description: updated
Revision history for this message
Lukas Märdian (slyon) wrote (last edit ):

Thank you for the SRU review in comment #17

I addressed your comments by adding an additional SRU test case to the bug description ("[ Test Plan 2 "Classic" ]")

And also adding a corresponding autopkgtest in my 0.104-0ubuntu2~20.04.4 upload:
- https://git.launchpad.net/~ubuntu-core-dev/netplan/+git/ubuntu/log/?h=ubuntu-focal
- https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=netplan

The new autopkgtest was also staged for upstream inclusion:
- https://github.com/canonical/netplan/pull/419

Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Michael, or anyone else affected,

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

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

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

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

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

Changed in netplan.io (Ubuntu Focal):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-focal
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (netplan.io/0.104-0ubuntu2~20.04.4)

All autopkgtests for the newly accepted netplan.io (0.104-0ubuntu2~20.04.4) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

netplan.io/unknown (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#netplan.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Lukas Märdian (slyon) wrote :
Download full text (4.5 KiB)

I tested netplan.io 0.104-0ubuntu2~20.04.4 from focal-proposed, TestCase2 "Classic". Everything worked as expected, no crashes observed. Also the new "test_try_accept_lp1959570" autopkgtest PASSed on all architectures.

root@ff-sru:~# dpkg -l | grep netplan
ii libnetplan0:amd64 0.104-0ubuntu2~20.04.4 amd64
ii netplan.io 0.104-0ubuntu2~20.04.4 amd64

root@ff-sru:~# apt install network-manager
root@ff-sru:~# mv /usr/bin/nmcli /snap/bin/nmcli
root@ff-sru:~# netplan get [16/358]
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
root@ff-sru:~# netplan set network.renderer=NetworkManager # change global renderer to NM
root@ff-sru:~# netplan set network.bridges.br54.addresses=[10.0.0.20/24]
root@ff-sru:~# netplan get
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eth0:
      dhcp4: true
  bridges:
    br54:
      addresses:
      - "10.0.0.20/24"
root@ff-sru:~# env -u PATH /usr/sbin/netplan try # Try-Apply the configuration
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 115 seconds
Configuration accepted.
root@ff-sru:~# /snap/bin/nmcli d show br54
GENERAL.DEVICE: br54
GENERAL....

Read more...

Revision history for this message
Lukas Märdian (slyon) wrote :

I tested netplan.io 0.104-0ubuntu2~20.04.4 from ppa:slyon/lp1959570 (which is the same upload as in focal-proposed), TestCase 1 (building a core20 snap & Ubuntu Core image from that PPA). Everything worked as expected, no crashes observed.

# This change is only available in the latest upload from focal-proposed:
slyon@ubuntu:~$ cat /usr/share/netplan/netplan/cli/core.py | grep "snap/bin"
FALLBACK_PATH = '/usr/bin:/snap/bin'

slyon@ubuntu:~$ snap install network-manager --channel=20/stable
network-manager (20/stable) 1.22.10-22 from Canonical✓ installed
slyon@ubuntu:~$ nmcli # VERIFY br54 is not there
ens3: connected to netplan-ens3
        "ens3"
        ethernet (virtio_net), 52:54:00:12:34:56, hw, mtu 1500
        ip4 default
        inet4 10.0.2.15/24
        route4 0.0.0.0/0
        route4 10.0.2.0/24
        inet6 fe80::5054:ff:fe12:3456/64
        route6 fe80::/64

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 10.0.2.3
        interface: ens3

Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.

Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details.
slyon@ubuntu:~$ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=true
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$
slyon@ubuntu:~$ netplan get # VERIFY br54 is there
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    ens3:
      dhcp4: true
  bridges:
    br54:
      dhcp4: true
slyon@ubuntu:~$ sudo journalctl | grep FileNotFound # EMPTY => no errors
slyon@ubuntu:~$ nmcli # VERIFY br54 is there
ens3: connected to netplan-ens3
        "ens3"
        ethernet (virtio_net), 52:54:00:12:34:56, hw, mtu 1500
        ip4 default
        inet4 10.0.2.15/24
        route4 0.0.0.0/0
        route4 10.0.2.0/24
        inet6 fe80::5054:ff:fe12:3456/64
        route6 fe80::/64

br54: connecting (getting IP configuration) to netplan-br54
        "br54"
        bridge, 96:B7:B7:F3:2A:FB, sw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 10.0.2.3
        interface: ens3

Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.

Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details.

tags: added: verification-done-focal
removed: verification-needed-focal
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netplan.io - 0.104-0ubuntu2~20.04.4

---------------
netplan.io (0.104-0ubuntu2~20.04.4) focal; urgency=medium

  * Cherry-pick upstream commit fc12872 (PR#336) to fix crash in 'snapd set'
    (LP: #1959570)
  * Add autopkgtest for LP#1959570

 -- Lukas Märdian <email address hidden> Thu, 26 Oct 2023 15:59:19 +0200

Changed in netplan.io (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for netplan.io has completed successfully and the package is now being 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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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