I can confirm this fixes the issue for me, too, using network-manager
1.44.2-1ubuntu1.2 from mantic-proposed.


$ sudo apt install -t mantic-proposed network-manager
[...]
$ LC_ALL=C apt list -i network-manager
Listing... Done
network-manager/mantic-proposed,now 1.44.2-1ubuntu1.2 amd64 [installed]


$ nmcli con add type dummy connection.interface-name dummy0
$ sudo cat /etc/netplan/90-NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b.yaml 
network:
  version: 2
  dummy-devices:
    NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b:
      renderer: NetworkManager
      networkmanager:
        uuid: "4189c63a-ecee-4a39-90f3-fffad2b96d0b"
        name: "dummy-dummy0"
        passthrough:
          connection.interface-name: "dummy0"
          dummy._: ""
          ipv4.method: "disabled"
          ipv6.addr-gen-mode: "default"
          ipv6.method: "disabled"
          ipv6.ip6-privacy: "-1"
          proxy._: ""
$ nmcli d show dummy0
GENERAL.DEVICE:                         dummy0
GENERAL.TYPE:                           dummy
GENERAL.HWADDR:                         32:89:DC:E0:74:2F
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (verbunden)
GENERAL.CONNECTION:                     dummy-dummy0
GENERAL.CON-PATH:                       
/org/freedesktop/NetworkManager/ActiveConnection/10
IP4.GATEWAY:                            --
IP6.GATEWAY:                            --

$ nmcli con del dummy-dummy0
$ LC_ALL=C nmcli d show dummy0
Error: Device 'dummy0' not found.
$ sudo LC_ALL=C cat 
/etc/netplan/90-NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b.yaml 
cat: /etc/netplan/90-NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b.yaml: No such file 
or directory
$ journalctl -u NetworkManager -e # I cannot spot any errors in here

** Tags removed: verification-needed-mantic
** Tags added: verification-done-mantic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded 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 Committed

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/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to