This bug was fixed in the package network-manager - 1.44.2-1ubuntu1.2
---------------
network-manager (1.44.2-1ubuntu1.2) mantic; urgency=medium
* debian/tests/nm_netplan.py:
Start Network Manager via systemd. The .service unit file sets
ProtectSystem to true and we want to run the Netplan tests with this
restriction enabled.
* d/p/netplan/0003-Allow-the-NetworkManager-daemon-to-write-to-lib-netp.patch:
Allow-list /usr/lib/netplan so libnetplan can open files from that
directory with writing permission. See LP: #2040153
* debian/tests/control.
Add all the dependencies required by the nm_netplan.py tests.
-- Danilo Egea Gondolfo <[email protected]> Mon, 23
Oct 2023 16:29:46 +0100
** Changed in: network-manager (Ubuntu Mantic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153
Title:
Network Manager will not remove Netplan YAMLs when connections are
deleted
Status in netplan.io package in Ubuntu:
Triaged
Status in network-manager package in Ubuntu:
In Progress
Status in netplan.io source package in Mantic:
Invalid
Status in network-manager source package in Mantic:
Fix Released
Bug description:
[ Impact ]
Desktop users, or any users with YAML files in /usr/lib/netplan, can't delete
Network Manager connections persistently. That means that, when the
connection is
deliberately deleted by the user, it will re-appear when the system is
rebooted or
netplan apply is executed.
This is happening because the systemd service unit is setting the property
"ProtectSystem"
to true. Because of that, /usr is being presented to the Network Manager
daemon as read-only.
When connections are deleted, libnetplan will try to open its YAML files with
writing permissions
and will fail for files from /usr/lib/netplan. Even if the user hasn't added
any files there manually,
the file /usr/lib/netplan/00-network-manager-all.yaml will be installed by
the package ubuntu-settings.
This issue is fixed by allow-listing /usr/lib/netplan with
ReadWritePaths=/usr/lib/netplan in systemd
so the Network Manager's daemon will be able to write to that directory.
This upload also improves the autopkgtests related to Netplan. Network
Manager will be
started by systemd, which ensures we are testing in the same environment
conditions
used by a desktop installation. It also adds a few more instances of
connections deletions so
we can test a bit more that YAML files are being removed. It also adds all
the dependencies
required by the test script (which sadly was causing the nm_netplan.py tests
to be skipped).
[ Test Plan ]
Launch a new Mantic VM:
$ lxc launch ubuntu:mantic --vm
Install network-manager and ubuntu-settings:
# apt install network-manager ubuntu-settings
Run Netplan
# netplan apply
Create a dummy connection via nmcli:
# nmcli con add type dummy connection.interface-name dummy0
Check a new YAML will be created in /etc/netplan
Delete the connection with nmcli
# nmcli con del dummy-dummy0
Check the YAML WAS NOT removed from /etc/netplan
You will see the error below in the NetworkManager's journal
netplan_delete_connection: Cannot write output state: Read-only file
system
Add the PPA containing the fix and run the same test described above
# add-apt-repository ppa:danilogondolfo/network-manager
# apt update
# apt upgrade
Check that the YAML will be created when the connection is added and
deleted and the connection is removed.
[ Where problems could occur ]
As the only change is a relaxation of the restrictions applied by systemd on
the environment where Network Manager
runs, we are not expecting any regression.
As for the changes in the autopkgtest related to Netplan, they are
passing on all architectures.
Autopkgtests
amd64 -
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/amd64/n/network-manager/20231023_175203_b2798@/log.gz
ppc64 -
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/ppc64el/n/network-manager/20231023_182332_f0497@/log.gz
s390x -
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/s390x/n/network-manager/20231023_190810_ced8d@/log.gz
arm64 -
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/arm64/n/network-manager/20231024_084542_ac017@/log.gz
armhf -
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/armhf/n/network-manager/20231024_083545_ac017@/log.gz
[ Other Info ]
--- Original description ---
When a connection is deleted using any NM facility, libnetplan is
failing to delete the YAML file. Because of that, the connection will
be recreated when "netplan generate" runs again.
This is probably being caused by a combination of two things. First,
the NM's systemd unit has this setting "ProtectSystem=true", which
will mount /usr as read-only for NM. Second, we migrated the default
"00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1].
When libnetplan tries to open this file for writing, the open system
fails with EROFS:
---
22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml",
O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system)
22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76
---
[1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2040153/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
