$ 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.
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 manager* .snap <vm-name>
[wait for kernel and core snap refresh/reboots]
$ multipass transfer network-
$ multipass shell <vm-name>
---
$ sudo snap install network- manager_ 1.10.6- 3-dev-20191217+ ffc6a971_ amd64.snap --dangerous 3-dev-20191217+ ffc6a971 installed manager: firewall- control manager: hardware- observe manager: network- setup-control manager: network- setup-observe manager: firewall- control :firewall-control manual manager: hardware- observe :hardware-observe manual manager: network :network - setup-control network- manager: network- setup-control :network- setup-control manual setup-observe network- manager: network- setup-observe :network- setup-observe manual
network-manager 1.10.6-
$ sudo snap connect network-
$ sudo snap connect network-
$ sudo snap connect network-
$ sudo snap connect network-
$ snap connections | grep network-manager
firewall-control network-
hardware-observe network-
network network-
network-
network-
$ 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.