Code review comment for ~alfonsosanchezbeato/network-manager:call-netplan-apply

Revision history for this message
Tony Espy (awe) wrote :

I just re-ran the scenario with a fresh multipass VM, and it still fails the first time. Here are my steps to reproduce:

$ multipass launch core18
[wait for kernel and core snap refresh/reboots]
$ multipass transfer network-manager*.snap <vm-name>
$ multipass shell <vm-name>
---

$ sudo snap install network-manager_1.10.6-3-dev-20191217+ffc6a971_amd64.snap --dangerous
network-manager 1.10.6-3-dev-20191217+ffc6a971 installed
$ sudo snap connect network-manager:firewall-control
$ sudo snap connect network-manager:hardware-observe
$ sudo snap connect network-manager:network-setup-control
$ sudo snap connect network-manager:network-setup-observe
$ snap connections | grep network-manager
firewall-control network-manager:firewall-control :firewall-control manual
hardware-observe network-manager:hardware-observe :hardware-observe manual
network network-manager:network :network -
network-setup-control network-manager:network-setup-control :network-setup-control manual
network-setup-observe network-manager:network-setup-observe :network-setup-observe manual

$ sudo snap set network-manager defaultrenderer=true
$ sudo networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 eth0 ether routable configured

I still see a single AppArmor denial for the dbus-send call.

Now, if I run the set command and change defaultrenderer=false, and then back to true, everything seems to work OK, so my guess is that this is a bug in the snap-config.sh script.

« Back to merge proposal