[Touch-packages] [Bug 2077159] Re: i40e interfaces renamed after upgrade from hwe-6.5

[Lukas Märdian]

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2077159

Title:
  i40e interfaces renamed after upgrade from hwe-6.5

Status in linux package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Server running Ubuntu 22.04.4 LTS

  Interface names with linux-image-6.5.0-21-generic 6.5.0-21.21~22.04.1:

  3: eno1:  mtu 9100 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
  altname enp102s0f0
  4: eno5:  mtu 1500 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
  altname enp183s0f0
  6: eno2:  mtu 1500 qdisc mq master mgmt 
state UP mode DEFAULT group default qlen 1000
  altname enp102s0f1
  7: eno6:  mtu 1500 qdisc mq master mgmt 
state DOWN mode DEFAULT group default qlen 1000
  altname enp183s0f1
  8: eno3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f2
  9: eno7:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp183s0f2
  10: eno4:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f3
  11: eno8:  mtu 1500 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
  altname enp183s0f3

  Interface names with linux-image-6.8.0-40-generic 6.8.0-40.40~22.04.3:

  3: eno5np0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000 
  altname enp183s0f0np0 

 
  4: eno1:  mtu 9100 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
 
  altname enp102s0f0

 
  5: enp101s0f1np1:  mtu 9100 qdisc mq state 
DOWN mode DEFAULT group default qlen 1000
  6: eno2:  mtu 1500 qdisc mq master mgmt 
state UP mode DEFAULT group default qlen 1000
  altname enp102s0f1

 
  7: eno6np1:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp183s0f1np1 

 
  8: eno3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f2
 
  9: eno7np2:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp183s0f2np2 
 
  10: eno4:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f3
 
  11: eno8np3:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000
  altname enp183s0f3np3

  Expected result: Static network configuration via netplan keeps
  working after the upgrade.

  Actual result: Static network configuration is no longer applied for the 
interface that changed their name.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Aug 16 09:40 seq
   crw-rw 1 root audio 116, 33 Aug 16 09:40 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.6
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CRDA: N/A
  CasperMD5json:
   {
 "result": "skip"
   }
  CloudArchitecture: x86_64
  CloudID: none
  CloudName: none
  CloudPlatform: none
  CloudSubPlatform: config
  DistroRelease: Ubuntu 22.04
  InstallationDate: Installed on 2023-12-04 (260 days ago)
  InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release 
amd64 (20230217.1)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  MachineType: Supermicro SYS-5019D-FN8TP
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 astdrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.5.0-21-generic 
root=/dev/mapper/system-root ro
  ProcVersionSignature: Ubuntu 6.5.0-21.21~22.04.1-generic 6.5.8
  RebootRequiredPkgs: Error: path contained symli

[Touch-packages] [Bug 2080489] Re: Network Manager stops functioning on Ubuntu 24.04

[Lukas Märdian]

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/2080489

Title:
  Network Manager stops functioning on Ubuntu 24.04

Status in linux package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  I installed Ubuntu 24.04 about a month ago on a Asus Vivobook. Soon
  after the NetworkManager started misbehaving, with all connections to
  the internet becoming idle now and then. When this event happens the
  only way to restore internet access is to reboot the system. If
  initially these events were occasional, they now take place 3 or 4
  times per day, often after signing in from the lock screen.

  So far I was not able to verify whether NetworkManager is actually
  crashing, the Settings programme reports "NetworkManager not running"
  (see attached image). However, in the command line `systemctl` reports
  an active service:

  ```
  $ systemctl status NetworkManager
  ● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled>
   Active: active (running) since Sun 2024-08-27 18:21:44 WEST; 2h 18min a>
     Docs: man:NetworkManager(8)
     Main PID: 1149 (NetworkManager)
    Tasks: 4 (limit: 18646)
   Memory: 12.2M (peak: 28.6M)
  CPU: 836ms
   CGroup: /system.slice/NetworkManager.service
   └─1149 /usr/sbin/NetworkManager --no-daemon

  ago 27 19:34:08 Symbolic NetworkManager[1149]:   [1724006048.8961] man>
  ago 27 19:34:08 Symbolic NetworkManager[1149]:   [1724006048.8965] dev>
  ago 27 19:34:09 Symbolic NetworkManager[1149]:   [1724006049.1482] dev>
  ago 27 19:34:09 Symbolic NetworkManager[1149]:   [1724006049.1484] dev>
  ago 27 19:34:09 Symbolic NetworkManager[1149]:   [1724006049.1488] dhc>
  ago 27 19:34:09 Symbolic NetworkManager[1149]:   [1724006049.1488] dhc>
  ago 27 19:34:09 Symbolic NetworkManager[1149]:   [1724006049.1489] dhc>
  ago 27 19:34:09 Symbolic NetworkManager[1149]:   [1724006049.2049] dev>
  ago 27 20:33:50 Symbolic NetworkManager[1149]:   [1724009630.5340] man>
  ago 27 20:33:50 Symbolic NetworkManager[1149]:   [1724009630.5344] dev>
  ```

  But if I try to restart the service, the command line just hangs up:

  ```
  $ ping 1.1.1.1
  ping: connect: Network is unreachable

  $ sudo systemctl restart NetworkManager

  ```

  Also from `ifconfig` there is no response:

  ```
  $ ifconfig -a

  ```

  Please let me know if there is further useful information I can
  report.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2080489/+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

[Touch-packages] [Bug 2077159] Re: i40e interfaces renamed after upgrade from hwe-6.5

[Lukas Märdian]

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: rls-jj-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2077159

Title:
  i40e interfaces renamed after upgrade from hwe-6.5

Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Server running Ubuntu 22.04.4 LTS

  Interface names with linux-image-6.5.0-21-generic 6.5.0-21.21~22.04.1:

  3: eno1:  mtu 9100 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
  altname enp102s0f0
  4: eno5:  mtu 1500 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
  altname enp183s0f0
  6: eno2:  mtu 1500 qdisc mq master mgmt 
state UP mode DEFAULT group default qlen 1000
  altname enp102s0f1
  7: eno6:  mtu 1500 qdisc mq master mgmt 
state DOWN mode DEFAULT group default qlen 1000
  altname enp183s0f1
  8: eno3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f2
  9: eno7:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp183s0f2
  10: eno4:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f3
  11: eno8:  mtu 1500 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
  altname enp183s0f3

  Interface names with linux-image-6.8.0-40-generic 6.8.0-40.40~22.04.3:

  3: eno5np0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000 
  altname enp183s0f0np0 

 
  4: eno1:  mtu 9100 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
 
  altname enp102s0f0

 
  5: enp101s0f1np1:  mtu 9100 qdisc mq state 
DOWN mode DEFAULT group default qlen 1000
  6: eno2:  mtu 1500 qdisc mq master mgmt 
state UP mode DEFAULT group default qlen 1000
  altname enp102s0f1

 
  7: eno6np1:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp183s0f1np1 

 
  8: eno3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f2
 
  9: eno7np2:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp183s0f2np2 
 
  10: eno4:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  altname enp102s0f3
 
  11: eno8np3:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000
  altname enp183s0f3np3

  Expected result: Static network configuration via netplan keeps
  working after the upgrade.

  Actual result: Static network configuration is no longer applied for the 
interface that changed their name.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Aug 16 09:40 seq
   crw-rw 1 root audio 116, 33 Aug 16 09:40 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.6
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CRDA: N/A
  CasperMD5json:
   {
 "result": "skip"
   }
  CloudArchitecture: x86_64
  CloudID: none
  CloudName: none
  CloudPlatform: none
  CloudSubPlatform: config
  DistroRelease: Ubuntu 22.04
  InstallationDate: Installed on 2023-12-04 (260 days ago)
  InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release 
amd64 (20230217.1)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  MachineType: Supermicro SYS-5019D-FN8TP
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 astdrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.5.0-21-generic 
root=/dev/mapper/system-root ro
  ProcVersionSignature: Ubuntu 6.5.0-21.21~22.04.1-generic 6.5.8
  RebootRequiredPkgs: Error: path contained symlinks.
  

[Touch-packages] [Bug 2033259] Re: netplan.script crashed with AttributeError in __getitem__(): /usr/bin/python3: undefined symbol: netplan_get_id_from_nm_filename

[Lukas Märdian]

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: foundations-todo

** Changed in: network-manager (Ubuntu Oracular)
   Status: New => Triaged

** Changed in: network-manager (Ubuntu Oracular)
   Importance: Undecided => Medium

-- 
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/2033259

Title:
  netplan.script crashed with AttributeError in __getitem__():
  /usr/bin/python3: undefined symbol: netplan_get_id_from_nm_filename

Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Triaged
Status in netplan.io source package in Noble:
  Confirmed
Status in network-manager source package in Noble:
  New
Status in netplan.io source package in Oracular:
  Confirmed
Status in network-manager source package in Oracular:
  Triaged

Bug description:
  ubuntu desktop (mantic) live test on dell optiplex 780
  - dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 
5000/6000/7350/8350)

  exploring the /var/crash/ directory I noticed this report; nothing had
  appeared on screen, so just filed it with `ubuntu-bug`.

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: netplan.io 0.106.1-8
  Uname: Linux 6.3.0-7-generic x86_64
  Architecture: amd64
  Date: Mon Aug 28 08:12:32 2023
  ExecutablePath: /usr/share/netplan/netplan.script
  ExecutableTimestamp: 1684343476
  InterpreterPath: /usr/bin/python3.11
  ProcCmdline: /usr/bin/python3 /usr/sbin/netplan generate
  ProcCwd: /
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
  PythonArgs: ['/usr/sbin/netplan', 'generate']
  SourcePackage: netplan.io
  UserGroups: N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2033259/+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

[Touch-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

[Lukas Märdian]

** Tags removed: foundations-todo

-- 
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/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  Fix Released
Status in cloud-init package in Ubuntu:
  Invalid
Status in cruft package in Ubuntu:
  Won't Fix
Status in cruft-ng package in Ubuntu:
  Fix Released
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  Invalid
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  Invalid
Status in ubiquity package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections&literal=1&perpkg=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+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

[Touch-packages] [Bug 2032824] Re: Veth pairs fail activation on Jammy

[Lukas Märdian]

** Changed in: network-manager (Ubuntu)
   Importance: Undecided => Low

-- 
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/2032824

Title:
  Veth pairs fail activation on Jammy

Status in network-manager package in Ubuntu:
  Triaged
Status in network-manager source package in Jammy:
  Triaged

Bug description:
  Network Manager 1.36 has a bug that prevents it to activate veth
  pairs. The problem was found in the Netplan's CI with the new support
  for veths in Netplan (because we run the tests on Jammy).

  How to reproduce the problem:

  1) Launch a Jammy VM and install network-manager

  lxc launch  ubuntu:jammy jammy --vm
  lxc shell jammy
  apt -y install network-manager

  2) Set the default Netplan's renderer to NetworkManager so NM can
  manage interfaces (it will make Netplan create the file
  /var/run/NetworkManager/conf.d/10-globally-managed-devices.conf)

  netplan set --origin-hint=50-cloud-init network.renderer=NetworkManager
  netplan apply

  3) Create the veth pair

  nmcli con add type veth ifname veth0 peer veth1 ipv4.method disabled 
ipv6.method disabled
  nmcli con add type veth ifname veth1 peer veth0 ipv4.method disabled 
ipv6.method disabled

  4) Reboot

  5) Check with "nmcli con show" that the new connections were not
  activated, even though both interfaces were created in the system.
  Also, check the systemd journal and you should see this error message:

   [1692805758.9025] manager: (veth-veth0) couldn't create the
  device: Failed to create veth interface 'veth0' for 'veth-veth0':
  exists

  
  Try the very same steps on Lunar and you'll see that the connections will be 
activated just fine.

  
  This issue appears to be fixed by this commit 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/4655b7c308461ae1f86d592ea6d45e00a2820423

  I created a PPA with the fix here
  https://launchpad.net/~danilogondolfo/+archive/ubuntu/network-manager

  If you run the same steps again on Jammy with this PPA you'll see it
  fixes this issue. In fact, Netplan's integration tests will work on
  Jammy using the PPA.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2032824/+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

[Touch-packages] [Bug 2032824] Re: Veth pairs fail activation on Jammy

[Lukas Märdian]

** Changed in: network-manager (Ubuntu)
   Status: New => Triaged

** Changed in: network-manager (Ubuntu Jammy)
   Status: New => Triaged

-- 
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/2032824

Title:
  Veth pairs fail activation on Jammy

Status in network-manager package in Ubuntu:
  Triaged
Status in network-manager source package in Jammy:
  Triaged

Bug description:
  Network Manager 1.36 has a bug that prevents it to activate veth
  pairs. The problem was found in the Netplan's CI with the new support
  for veths in Netplan (because we run the tests on Jammy).

  How to reproduce the problem:

  1) Launch a Jammy VM and install network-manager

  lxc launch  ubuntu:jammy jammy --vm
  lxc shell jammy
  apt -y install network-manager

  2) Set the default Netplan's renderer to NetworkManager so NM can
  manage interfaces (it will make Netplan create the file
  /var/run/NetworkManager/conf.d/10-globally-managed-devices.conf)

  netplan set --origin-hint=50-cloud-init network.renderer=NetworkManager
  netplan apply

  3) Create the veth pair

  nmcli con add type veth ifname veth0 peer veth1 ipv4.method disabled 
ipv6.method disabled
  nmcli con add type veth ifname veth1 peer veth0 ipv4.method disabled 
ipv6.method disabled

  4) Reboot

  5) Check with "nmcli con show" that the new connections were not
  activated, even though both interfaces were created in the system.
  Also, check the systemd journal and you should see this error message:

   [1692805758.9025] manager: (veth-veth0) couldn't create the
  device: Failed to create veth interface 'veth0' for 'veth-veth0':
  exists

  
  Try the very same steps on Lunar and you'll see that the connections will be 
activated just fine.

  
  This issue appears to be fixed by this commit 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/4655b7c308461ae1f86d592ea6d45e00a2820423

  I created a PPA with the fix here
  https://launchpad.net/~danilogondolfo/+archive/ubuntu/network-manager

  If you run the same steps again on Jammy with this PPA you'll see it
  fixes this issue. In fact, Netplan's integration tests will work on
  Jammy using the PPA.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2032824/+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

[Touch-packages] [Bug 2032824] Re: Veth pairs fail activation on Jammy

[Lukas Märdian]

** Tags added: foundations-todo

-- 
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/2032824

Title:
  Veth pairs fail activation on Jammy

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Jammy:
  New

Bug description:
  Network Manager 1.36 has a bug that prevents it to activate veth
  pairs. The problem was found in the Netplan's CI with the new support
  for veths in Netplan (because we run the tests on Jammy).

  How to reproduce the problem:

  1) Launch a Jammy VM and install network-manager

  lxc launch  ubuntu:jammy jammy --vm
  lxc shell jammy
  apt -y install network-manager

  2) Set the default Netplan's renderer to NetworkManager so NM can
  manage interfaces (it will make Netplan create the file
  /var/run/NetworkManager/conf.d/10-globally-managed-devices.conf)

  netplan set --origin-hint=50-cloud-init network.renderer=NetworkManager
  netplan apply

  3) Create the veth pair

  nmcli con add type veth ifname veth0 peer veth1 ipv4.method disabled 
ipv6.method disabled
  nmcli con add type veth ifname veth1 peer veth0 ipv4.method disabled 
ipv6.method disabled

  4) Reboot

  5) Check with "nmcli con show" that the new connections were not
  activated, even though both interfaces were created in the system.
  Also, check the systemd journal and you should see this error message:

   [1692805758.9025] manager: (veth-veth0) couldn't create the
  device: Failed to create veth interface 'veth0' for 'veth-veth0':
  exists

  
  Try the very same steps on Lunar and you'll see that the connections will be 
activated just fine.

  
  This issue appears to be fixed by this commit 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/4655b7c308461ae1f86d592ea6d45e00a2820423

  I created a PPA with the fix here
  https://launchpad.net/~danilogondolfo/+archive/ubuntu/network-manager

  If you run the same steps again on Jammy with this PPA you'll see it
  fixes this issue. In fact, Netplan's integration tests will work on
  Jammy using the PPA.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2032824/+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

[Touch-packages] [Bug 2032824] Re: Veth pairs fail activation on Jammy

[Lukas Märdian]

** Tags added: fr-8841

-- 
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/2032824

Title:
  Veth pairs fail activation on Jammy

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Jammy:
  New

Bug description:
  Network Manager 1.36 has a bug that prevents it to activate veth
  pairs. The problem was found in the Netplan's CI with the new support
  for veths in Netplan (because we run the tests on Jammy).

  How to reproduce the problem:

  1) Launch a Jammy VM and install network-manager

  lxc launch  ubuntu:jammy jammy --vm
  lxc shell jammy
  apt -y install network-manager

  2) Set the default Netplan's renderer to NetworkManager so NM can
  manage interfaces (it will make Netplan create the file
  /var/run/NetworkManager/conf.d/10-globally-managed-devices.conf)

  netplan set --origin-hint=50-cloud-init network.renderer=NetworkManager
  netplan apply

  3) Create the veth pair

  nmcli con add type veth ifname veth0 peer veth1 ipv4.method disabled 
ipv6.method disabled
  nmcli con add type veth ifname veth1 peer veth0 ipv4.method disabled 
ipv6.method disabled

  4) Reboot

  5) Check with "nmcli con show" that the new connections were not
  activated, even though both interfaces were created in the system.
  Also, check the systemd journal and you should see this error message:

   [1692805758.9025] manager: (veth-veth0) couldn't create the
  device: Failed to create veth interface 'veth0' for 'veth-veth0':
  exists

  
  Try the very same steps on Lunar and you'll see that the connections will be 
activated just fine.

  
  This issue appears to be fixed by this commit 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/4655b7c308461ae1f86d592ea6d45e00a2820423

  I created a PPA with the fix here
  https://launchpad.net/~danilogondolfo/+archive/ubuntu/network-manager

  If you run the same steps again on Jammy with this PPA you'll see it
  fixes this issue. In fact, Netplan's integration tests will work on
  Jammy using the PPA.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2032824/+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

[Touch-packages] [Bug 2078759] Re: debsums: changed file /lib/netplan/00-network-manager-all.yaml (from ubuntu-settings package)

[Lukas Märdian]

I wonder if Netplan should modify files in /usr/lib/netplan/ at all?
Yes, it needs to read those files, to get a full view of the
configuration. But writing should probably be limited to /run/ and
/etc/netplan/ ...

** Also affects: ubuntu-settings (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: foundations-todo

** Changed in: netplan.io (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu.
https://bugs.launchpad.net/bugs/2078759

Title:
  debsums: changed file /lib/netplan/00-network-manager-all.yaml (from
  ubuntu-settings package)

Status in OEM Priority Project:
  New
Status in netplan.io package in Ubuntu:
  Triaged
Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  On ubuntu desktop 24.04 image, run the operations below

  1. $ nmcli d wifi connect  password 
  2. $ nmcli c delete 
  3. $ sudo debsums -s

  Then the error is happened debsums: changed file
  /lib/netplan/00-network-manager-all.yaml (from ubuntu-settings
  package)

  it seems the netplan update the file belonged to ubuntu-settings that cause 
the debsums failed.
  --- 
  ProblemType: Bug
  ApportVersion: 2.28.1-0ubuntu3.1
  Architecture: amd64
  CasperMD5CheckMismatches: ./casper/initrd ./casper/vmlinuz 
./casper/minimal.standard.live.hotfix.squashfs 
./casper/minimal.standard.hotfix.squashfs ./casper/minimal.hotfix.squashfs 
./boot/grub/grub.cfg
  CasperMD5CheckResult: fail
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for Ubuntu 24.04 for Dell
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-noble-oem-24.04a-next-20240902-67
  DistroRelease: Ubuntu 24.04
  InstallationDate: Installed on 2024-09-02 (1 days ago)
  InstallationMedia: Ubuntu OEM 24.04.1 LTS "Noble Numbat" - Release amd64 
(20240829)
  Package: netplan.io 1.0.1-1ubuntu2~24.04.1
  PackageArchitecture: amd64
  ProcVersionSignature: User Name 6.8.0-1012.12-oem 6.8.12
  Tags: noble
  Uname: Linux 6.8.0-1012-oem x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lxd sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/2078759/+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

[Touch-packages] [Bug 2073869] Re: systemd-networkd refuses to apply route with gateway out of the NIC's subnet

[Lukas Märdian]

This sounds like it needs a backported feature for systemd-networkd in
Focal, i.e. something that got fixed in networkd.

Did you try adding the "on-link: true" setting to your static routes in
the Netplan configuration? That might be able to work around the issue.

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2073869

Title:
  systemd-networkd refuses to apply route with gateway out of the NIC's
  subnet

Status in cloud-init package in Ubuntu:
  Invalid
Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New
Status in cloud-init source package in Focal:
  New
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  New

Bug description:
  The version of systemd-networkd on Ubuntu Focal refuses to configure a
  route due to the fact that the address of the gateway is outside of
  the subnet of the NIC. The onlink option is required. This does not
  happen on Jammy and Noble.

  Steps to reproduce:

  ```
  # ip a
  2: ens2:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether de:00:00:62:c5:e9 brd ff:ff:ff:ff:ff:ff
  inet 212.47.xxx.xxx/32 scope global dynamic ens2
 valid_lft 800sec preferred_lft 800sec
  inet6 2001:xxx:xxx:::xx::c5e9/64 scope global
 valid_lft forever preferred_lft forever
  inet6 fe80::dc00:ff:fe62:c5e9/64 scope link
 valid_lft forever preferred_lft forever

  # cat /etc/netplan/50-cloud-init.yaml
  version: 2
  ethernets:
  ens2:
  addresses:
  - 2001:xxx:xxx:::xx::c5e9/64
  dhcp4: true
  routes:
  -   to: 169.254.42.42/32
  via: 62.210.0.1
  -   to: ::/0
  via: fe80::dc00:ff:fe62:c5ea

  # netplan apply

  # journalctl -b -u systemd-networkd
  ...
  Jul 18 10:05:59 focal systemd-networkd[668]: ens2: Could not set route: 
Nexthop has invalid gateway. Network is unreachable
  ...
  ```

  Is this something that netplan fixes and presents it in a better way
  to networkd in newer versions? Or is this something that networkd
  improves in newer versions?

  cloud-init's upstream bug: https://github.com/canonical/cloud-
  init/issues/5523

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2073869/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

You can put your trunk (enp3s0) as "optional: true" and it will still
wait for the vlans to be up. We might consider marking interfaces with
empty configuration (like "enp3s0: {}") to be "optional: true" by
default...

** Changed in: netplan
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  Fix Released
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2064093] Re: if-up.d files do not have effect on ubuntu 24.04 LTS

[Lukas Märdian]

You filed the bug report against NetworkManager. But the "up.d" hook is
called differently in NM, see https://netplan.io/faq#use-pre-up-post-up-
etc-hook-scripts

If this is about /etc/network/if-up.d then it should be targeted towards
the "ifupdown" package. I'm adding a corresponding bug task.

** Also affects: ifupdown (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/2064093

Title:
  if-up.d files do not have effect on ubuntu 24.04 LTS

Status in ifupdown package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Some time ago I wrote a detailed answer to fix an error for lowering
  MTU size for a cisco-compatible VPN
  (here:https://unix.stackexchange.com/questions/768757/unable-to-ssh-
  into-remote-machine-but-able-to-ping-vpnc/768758#768758)

  After upgrading to Ubuntu 24.04 LTS, I'm unable with the same steps to
  lower the MTU size.

  In particular, if I run the following command from the terminal

  sudo ifconfig your_tunnel_name mtu 1370 up

  it seems to lower the MTU size.

  However, the script under /etc/network/if-up.d is not automatically
  triggered.

  Does something change with the newer Ubuntu version?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/2064093/+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

[Touch-packages] [Bug 2063443] Re: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

Let me mark it as invalid as I also already opened a bug ticket at the
debian bug tracker as we have the same results there as well. Probably
doesn't make sense to double track bugtickets then in this case, thanks!

** Changed in: krb5 (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/2063443

Title:
  krb5.conf seems to ignore rdns = false

Status in krb5 package in Ubuntu:
  Invalid

Bug description:
  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
  consistent and lead to wrongly requested SPNs otherwise (see
  https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-
  dns-mismatches)

  Therefore we have set "rdns = false" in /etc/krb5.conf as follows:

  # cat /etc/krb5.conf

  [libdefaults]
  udp_preference_limit = 0
  default_realm = EMEA.EXAMPLE.COM
  rdns = false

  However this setting seems to get ignored for some reason. I tried to
  do some debugging and comparisons as we don't have the same issue for
  example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.

  On those RHEL machines the setting seems to do exactly what it's
  supposed to, in fact I can reproduce the issue we have on Ubuntu on
  RHEL as well if I remove the "rdns = false" line from the
  configuration.

  Kerberos authentication (in our test we use a simple ldapsearch with
  GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due
  to using a wrong PTR for canonicalization.

  On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3)
  however the setting does not seem to have any effect. I then re-did
  the same test with Debian oldstable, stable and sid as well, all with
  the exact same result.

  I actually ran a tcpdump while trying to do a Kerberos auth with the
  "rdns = false" setting in place and I can still see the reverse lookup
  being performed in the tcpdump (I anonymized some things so don't get
  confused about the IPs):

  10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
  10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] ? 
domaincontroller01.emea.example.com. (55)
  10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
  10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
5.6.7.8 (602)
  10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
8.7.6.5.in-addr.arpa. (55)
  10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)

  As you see there it does the PTR lookup and retrieves two entries
  (emea.example.com and DOMAINCONTROLLER.emea.example.com)

  If I do the same test on the RHEL8 machine I can actually see in
  tcpdump that with the "rdns = false" setting the reverse lookup is
  correctly NOT performed.

  I am a bit puzzled why this is the case as I have not seen other
  people reporting it (maybe everyone else has their reverse DNS under
  control ;)) even though as said in a quick test I was also able to get
  the same wrong result with multiple Debian releases and the mentioned
  Ubuntu release.

  The only thing I've found in the past where this exact issue was
  mentioned was many years ago:
  https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html

  However this has been fixed ever since. I have not done yet any actual
  code comparison with the version that RHEL uses, also I'm not sure if
  the issue actually really exists in libkrb5 itself or if it might be a
  sideeffect from some other lib.

  How to reproduce on your own:
  Even if you don't have erroneous reverse DNS entries you could still try to 
reproduce it by just looking at tcpdump and checking if you see reverse lookups 
performed with and without the option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/2063443/+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

[Touch-packages] [Bug 2063443] Re: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

** Description changed:

  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
  consistent and lead to wrongly requested SPNs otherwise (see
  https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-
  dns-mismatches)
  
- Therfore we have set "rdns = false" in /etc/krb5.conf as follows:
+ Therefore we have set "rdns = false" in /etc/krb5.conf as follows:
  
  # cat /etc/krb5.conf
  
  [libdefaults]
  udp_preference_limit = 0
  default_realm = EMEA.EXAMPLE.COM
  rdns = false
  
  However this setting seems to get ignored for some reason. I tried to do
- some debugging and comparison as we don't have the same issue for
+ some debugging and comparisons as we don't have the same issue for
  example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.
  
  On those RHEL machines the setting seems to do exactly what it's
  supposed to, in fact I can reproduce the issue we have on Ubuntu on RHEL
  as well if I remove the "rdns = false" line from the configuration.
  
  Kerberos authentication (in our test we use a simple ldapsearch with
  GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due to
  using a wrong PTR for canonicalization.
  
  On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3) however
- the setting does not seem to have any effect.
+ the setting does not seem to have any effect. I then re-did the same
+ test with Debian oldstable, stable and sid as well, all with the exact
+ same result.
  
- I actually run a tcpdump while trying to do a Kerberos auth with the
+ I actually ran a tcpdump while trying to do a Kerberos auth with the
  "rdns = false" setting in place and I can still see the reverse lookup
- being performed in the tcpdump (anonymized some things so don't get
+ being performed in the tcpdump (I anonymized some things so don't get
  confused about the IPs):
  
  10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
  10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] ? 
domaincontroller01.emea.example.com. (55)
  10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
- 10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
10.145.214.16 (602)
- 10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
16.214.145.10.in-addr.arpa. (55)
+ 10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
5.6.7.8 (602)
+ 10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
8.7.6.5.in-addr.arpa. (55)
  10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)
  
  As you see there it does the PTR lookup and retrieves two entries
  (emea.example.com and DOMAINCONTROLLER.emea.example.com)
  
  If I do the same test on the RHEL8 machine I can actually see in tcpdump
  that with the "rdns = false" setting the reverse lookup is correctly NOT
  performed.
  
  I am a bit puzzled why this is the case as I have not seen other people
- reporting it even though in a quick test I was also able to get the same
- wrong result with Debian stable.
+ reporting it (maybe everyone else has their reverse DNS under control
+ ;)) even though as said in a quick test I was also able to get the same
+ wrong result with multiple Debian releases and the mentioned Ubuntu
+ release.
  
  The only thing I've found in the past where this exact issue was
- mentioned as many years ago:
+ mentioned was many years ago:
  https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html
  
  However this has been fixed ever since. I have not done yet any actual
  code comparison with the version that RHEL uses, also I'm not sure if
- the issue is even there or (as in that recent bug linked above) might
- come from some glibc issue?
+ the issue actually really exists in libkrb5 itself or if it might be a
+ sideeffect from some other lib.
  
  How to reproduce on your own:
  Even if you don't have erroneous reverse DNS entries you could still try to 
reproduce it by just looking at tcpdump and checking if you see reverse lookups 
performed with and without the option.
- 
- I attached the apport for libkrb5 but let me know if something else is
- needed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/2063443

Title:
  krb5.conf seems to ignore rdns = false

Status in krb5 package in Ubuntu:
  New

Bug description:
  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
  consistent and lead to wrongly requested SPNs otherwise (see
  https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-
  dns-mismatches)

  Therefore we have set "rdns = false" in 

[Touch-packages] [Bug 2063443] Re: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

** No longer affects: kerberos

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/2063443

Title:
  krb5.conf seems to ignore rdns = false

Status in krb5 package in Ubuntu:
  New

Bug description:
  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
  consistent and lead to wrongly requested SPNs otherwise (see
  https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-
  dns-mismatches)

  Therfore we have set "rdns = false" in /etc/krb5.conf as follows:

  # cat /etc/krb5.conf

  [libdefaults]
  udp_preference_limit = 0
  default_realm = EMEA.EXAMPLE.COM
  rdns = false

  However this setting seems to get ignored for some reason. I tried to
  do some debugging and comparison as we don't have the same issue for
  example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.

  On those RHEL machines the setting seems to do exactly what it's
  supposed to, in fact I can reproduce the issue we have on Ubuntu on
  RHEL as well if I remove the "rdns = false" line from the
  configuration.

  Kerberos authentication (in our test we use a simple ldapsearch with
  GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due
  to using a wrong PTR for canonicalization.

  On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3)
  however the setting does not seem to have any effect.

  I actually run a tcpdump while trying to do a Kerberos auth with the
  "rdns = false" setting in place and I can still see the reverse lookup
  being performed in the tcpdump (anonymized some things so don't get
  confused about the IPs):

  10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
  10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] ? 
domaincontroller01.emea.example.com. (55)
  10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
  10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
10.145.214.16 (602)
  10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
16.214.145.10.in-addr.arpa. (55)
  10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)

  As you see there it does the PTR lookup and retrieves two entries
  (emea.example.com and DOMAINCONTROLLER.emea.example.com)

  If I do the same test on the RHEL8 machine I can actually see in
  tcpdump that with the "rdns = false" setting the reverse lookup is
  correctly NOT performed.

  I am a bit puzzled why this is the case as I have not seen other
  people reporting it even though in a quick test I was also able to get
  the same wrong result with Debian stable.

  The only thing I've found in the past where this exact issue was
  mentioned as many years ago:
  https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html

  However this has been fixed ever since. I have not done yet any actual
  code comparison with the version that RHEL uses, also I'm not sure if
  the issue is even there or (as in that recent bug linked above) might
  come from some glibc issue?

  How to reproduce on your own:
  Even if you don't have erroneous reverse DNS entries you could still try to 
reproduce it by just looking at tcpdump and checking if you see reverse lookups 
performed with and without the option.

  I attached the apport for libkrb5 but let me know if something else is
  needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/2063443/+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

[Touch-packages] [Bug 2063443] Re: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

** Description changed:

  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
- consistent and lead to wrongly requested SPNs otherwise.
+ consistent and lead to wrongly requested SPNs otherwise (see
+ https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-
+ dns-mismatches)
  
  Therfore we have set "rdns = false" in /etc/krb5.conf as follows:
  
  # cat /etc/krb5.conf
  
  [libdefaults]
  udp_preference_limit = 0
  default_realm = EMEA.EXAMPLE.COM
  rdns = false
  
  However this setting seems to get ignored for some reason. I tried to do
  some debugging and comparison as we don't have the same issue for
  example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.
  
  On those RHEL machines the setting seems to do exactly what it's
  supposed to, in fact I can reproduce the issue we have on Ubuntu on RHEL
  as well if I remove the "rdns = false" line from the configuration.
  
  Kerberos authentication (in our test we use a simple ldapsearch with
  GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due to
  using a wrong PTR for canonicalization.
  
  On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3) however
  the setting does not seem to have any effect.
  
  I actually run a tcpdump while trying to do a Kerberos auth with the
  "rdns = false" setting in place and I can still see the reverse lookup
  being performed in the tcpdump (anonymized some things so don't get
  confused about the IPs):
  
  10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
  10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] ? 
domaincontroller01.emea.example.com. (55)
  10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
  10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
10.145.214.16 (602)
  10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
16.214.145.10.in-addr.arpa. (55)
  10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)
  
- 
- As you see there it does the PTR lookup and retrieves two entries 
(emea.example.com and DOMAINCONTROLLER.emea.example.com)
+ As you see there it does the PTR lookup and retrieves two entries
+ (emea.example.com and DOMAINCONTROLLER.emea.example.com)
  
  If I do the same test on the RHEL8 machine I can actually see in tcpdump
  that with the "rdns = false" setting the reverse lookup is correctly NOT
  performed.
  
  I am a bit puzzled why this is the case as I have not seen other people
  reporting it even though in a quick test I was also able to get the same
  wrong result with Debian stable.
  
  The only thing I've found in the past where this exact issue was
  mentioned as many years ago:
  https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html
  
  However this has been fixed ever since. I have not done yet any actual
  code comparison with the version that RHEL uses, also I'm not sure if
  the issue is even there or (as in that recent bug linked above) might
  come from some glibc issue?
  
  How to reproduce on your own:
  Even if you don't have erroneous reverse DNS entries you could still try to 
reproduce it by just looking at tcpdump and checking if you see reverse lookups 
performed with and without the option.
  
  I attached the apport for libkrb5 but let me know if something else is
  needed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/2063443

Title:
  krb5.conf seems to ignore rdns = false

Status in Kerberos:
  New
Status in krb5 package in Ubuntu:
  New

Bug description:
  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
  consistent and lead to wrongly requested SPNs otherwise (see
  https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-
  dns-mismatches)

  Therfore we have set "rdns = false" in /etc/krb5.conf as follows:

  # cat /etc/krb5.conf

  [libdefaults]
  udp_preference_limit = 0
  default_realm = EMEA.EXAMPLE.COM
  rdns = false

  However this setting seems to get ignored for some reason. I tried to
  do some debugging and comparison as we don't have the same issue for
  example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.

  On those RHEL machines the setting seems to do exactly what it's
  supposed to, in fact I can reproduce the issue we have on Ubuntu on
  RHEL as well if I remove the "rdns = false" line from the
  configuration.

  Kerberos authentication (in our test we use a simple ldapsearch with
  GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due
  to using a wrong PTR for canonicalization.

  On our Ubuntu 22.

[Touch-packages] [Bug 2063443] Re: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

** Project changed: launchpad => kerberos

** Also affects: krb5 (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/2063443

Title:
  krb5.conf seems to ignore rdns = false

Status in Kerberos:
  New
Status in krb5 package in Ubuntu:
  New

Bug description:
  We have a scenario where we need to disable reverse lookups for
  canonicalization in Kerberos as the customer's PTR records are not
  consistent and lead to wrongly requested SPNs otherwise.

  Therfore we have set "rdns = false" in /etc/krb5.conf as follows:

  # cat /etc/krb5.conf

  [libdefaults]
  udp_preference_limit = 0
  default_realm = EMEA.EXAMPLE.COM
  rdns = false

  However this setting seems to get ignored for some reason. I tried to
  do some debugging and comparison as we don't have the same issue for
  example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.

  On those RHEL machines the setting seems to do exactly what it's
  supposed to, in fact I can reproduce the issue we have on Ubuntu on
  RHEL as well if I remove the "rdns = false" line from the
  configuration.

  Kerberos authentication (in our test we use a simple ldapsearch with
  GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due
  to using a wrong PTR for canonicalization.

  On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3)
  however the setting does not seem to have any effect.

  I actually run a tcpdump while trying to do a Kerberos auth with the
  "rdns = false" setting in place and I can still see the reverse lookup
  being performed in the tcpdump (anonymized some things so don't get
  confused about the IPs):

  10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
  10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] ? 
domaincontroller01.emea.example.com. (55)
  10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
  10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
10.145.214.16 (602)
  10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
16.214.145.10.in-addr.arpa. (55)
  10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)

  
  As you see there it does the PTR lookup and retrieves two entries 
(emea.example.com and DOMAINCONTROLLER.emea.example.com)

  If I do the same test on the RHEL8 machine I can actually see in
  tcpdump that with the "rdns = false" setting the reverse lookup is
  correctly NOT performed.

  I am a bit puzzled why this is the case as I have not seen other
  people reporting it even though in a quick test I was also able to get
  the same wrong result with Debian stable.

  The only thing I've found in the past where this exact issue was
  mentioned as many years ago:
  https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html

  However this has been fixed ever since. I have not done yet any actual
  code comparison with the version that RHEL uses, also I'm not sure if
  the issue is even there or (as in that recent bug linked above) might
  come from some glibc issue?

  How to reproduce on your own:
  Even if you don't have erroneous reverse DNS entries you could still try to 
reproduce it by just looking at tcpdump and checking if you see reverse lookups 
performed with and without the option.

  I attached the apport for libkrb5 but let me know if something else is
  needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kerberos/+bug/2063443/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

** Changed in: netplan
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  Fix Committed
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  Fix Released
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2063204] Re: Desktop-Live ships /etc/netplan/01-network-manager-all.yaml in addition to /usr/lib/netplan/00-network-manager-all.yaml

[Lukas Märdian]

Arguably, the "/usr/lib/netplan/00-network-manager-all.yaml" should be
shipped by the network-manager package, instead of ubuntu-settings...

The community flavors using Calamares, might be covered by this PR:
https://github.com/calamares/calamares/pull/2284

** Also affects: ubuntu-settings (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu.
https://bugs.launchpad.net/bugs/2063204

Title:
  Desktop-Live ships /etc/netplan/01-network-manager-all.yaml in
  addition to /usr/lib/netplan/00-network-manager-all.yaml

Status in livecd-rootfs package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New
Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  The /etc/netplan/01-network-manager-all.yaml, generated by livecd-rootfs, 
shouldn't exist any more IIUC.
  That functionality was moved into src:ubuntu-settings and shipped as 
/usr/lib/netplan/00-network-manager-all.yaml

  This is according to https://launchpad.net/ubuntu/+source/ubuntu-
  settings/23.10.1

  The duplicated "renderer: NetworkManager" doesn't cause any harm in
  the live-session, AFAICT.

  The /etc/netplan/01-network-manager-all.yaml file is carried over into
  the installed system (target).

  After "apt install --reinstall ubuntu-settings" the file gets deleted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2063204/+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

[Touch-packages] [Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs

[Lukas Märdian]

** Also affects: e2fsprogs (Ubuntu Noble)
   Importance: Critical
 Assignee: Matthew Ruffell (mruffell)
   Status: In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  Won't Fix
Status in e2fsprogs source package in Xenial:
  Won't Fix
Status in e2fsprogs source package in Bionic:
  Won't Fix
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  Won't Fix
Status in e2fsprogs source package in Mantic:
  In Progress
Status in e2fsprogs source package in Noble:
  In Progress

Bug description:
  [Impact]

  This is a long running bug plaguing cloud-images, where on a rare
  occasion resize2fs would fail and the image would not resize to fit
  the entire disk.

  Online resizes would fail due to a superblock checksum mismatch, where
  the superblock in memory differs from what is currently on disk due to
  changes made to the image.

  $ resize2fs /dev/nvme1n1p1
  resize2fs 1.47.0 (5-Feb-2023)
  resize2fs: Superblock checksum does not match superblock while trying to open 
/dev/nvme1n1p1
  Couldn't find valid filesystem superblock.

  Changing the read of the superblock to Direct I/O solves the issue.

  [Testcase]

  Start an c5.large instance on AWS, and attach a 60gb gp3 volume for
  use as a scratch disk.

  Run the following script, courtesy of Krister Johansen and his team:

     #!/usr/bin/bash
     set -euxo pipefail

     while true
     do
     parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
     sleep .5
     mkfs.ext4 /dev/nvme1n1p1
     mount -t ext4 /dev/nvme1n1p1 /mnt
     stress-ng --temp-path /mnt -D 4 &
     STRESS_PID=$!
     sleep 1
     growpart /dev/nvme1n1 1
     resize2fs /dev/nvme1n1p1
     kill $STRESS_PID
     wait $STRESS_PID
     umount /mnt
     wipefs -a /dev/nvme1n1p1
     wipefs -a /dev/nvme1n1
     done

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test

  If you install the test packages, the race no longer occurs.

  [Where problems could occur]

  We are changing how resize2fs reads the superblock from underlying
  disks.

  If a regression were to occur, resize2fs could fail to resize offline
  or online volumes. As all cloud-images are online resized during their
  initial boot, this could have a large impact to public and private
  clouds should a regression occur.

  [Other info]

  Upstream mailing list discussion:
  https://lore.kernel.org/linux-ext4/20230605225221.ga5...@templeofstupid.com/
  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This was fixed in the below commit upstream:

  commit 43a498e938887956f393b5e45ea6ac79cc5f4b84
  Author: Theodore Ts'o 
  Date: Thu, 15 Jun 2023 00:17:01 -0400
  Subject: resize2fs: use Direct I/O when reading the superblock for
   online resizes
  Link: 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  The commit has not been tagged to any release. All supported Ubuntu
  releases require this fix, and need to be published in standard non-
  ESM archives to be picked up in cloud images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+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

[Touch-packages] [Bug 2055012] Re: When I upgraded from 22.04 to 24.04, DNS resolution went wrong.

[Lukas Märdian]

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2055012

Title:
  When I upgraded from 22.04 to 24.04, DNS resolution went wrong.

Status in network-manager package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  I was an unpatient idiot, and I upgraded from 22.04 to 24.04. Near to
  the end of the upgrade, I got an „Oh, no! Something has gone wrong and
  the system cannot recover. Call the system administrator” message
  after a red FAILED in the terminal. The system administrator is
  myself, because my computer is a personal one. Hard reset, same error,
  Ctrl+Alt+F3, sudo apt reinstall gdm3. Obviously. I needed to finish
  the update with dpkg. While dpkg was upgrading, it printed an error
  message for every WiFi connection:

  „[Failed] Failed to migrate [I do not remember, something with
  /etc/netplan]”

  It took at least one and a half hour to find the solution on Ask
  Ubuntu. The problem was: /etc/resolv.conf became a broken link, along
  with systemd-resolve.service. I needed to remove both of them and
  write a new resolv.conf to fix the error.

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: network-manager 1.45.90-1ubuntu1
  ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
  Uname: Linux 6.6.0-14-generic x86_64
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 08:21:02 2024
  InstallationDate: Installed on 2023-07-05 (236 days ago)
  InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316)
  IpRoute:
   default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.100 metric 600
   192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.100 metric 
600
   192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 
linkdown
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  RfKill:
   0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to noble on 2024-02-24 (2 days ago)
  modified.conffile..etc.init.d.apport: [modified]
  mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.45.90  connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2055012/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

** Changed in: network-manager (Ubuntu)
   Status: New => Invalid

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in Netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2060778] Re: netplan, multiple dhcp route with metric failure

[Lukas Märdian]

Thanks for the additional details!

In this case the output of "resolvectl" after "netplan apply" and after
resume (no "netplan apply") might be useful. In addition to debug-logs
of your systemd-resolved


$ sudo systemctl edit systemd-resolved

Adding:
```
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
```

$ sudo systemctl daemon-reload
$ sudo systemctl restart systemd-resolved # (or reboot)

Afterwards:
$ journalctl -u systemd-resolved # (for a full "netplan apply", suspend, resume 
cycle)

** Changed in: netplan
   Status: Incomplete => Invalid

** Summary changed:

- netplan, multiple dhcp route with metric failure
+ systemd-resolved switches primary interface for name resolution after 
suspend/resume cycle

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060778

Title:
  systemd-resolved switches primary interface for name resolution after
  suspend/resume cycle

Status in Netplan:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  Hardware/network: PC with single NIC, multiple vlans:
   - untagged: default LAN, should be used by the host
   - vlan 15: VM network, should only be used by the VM(s) running on the host

  Netplan config:

  network:
version: 2
renderer: networkd
ethernets:
  lan:
match:
  macaddress: "XX:XX:XX:XX:XX:XX"
set-name: lan
mtu: 9000
dhcp4: yes
dhcp6: yes
ipv6-privacy: true
bridges:
  vm-br0:
dhcp4: yes
interfaces: [vm]
dhcp4-overrides:
  route-metric: 200
vlans:
  vm:
id: 15
link: lan

  (Using networkd as the renderer some apps [App Store, Settings/Online 
Accounts,...] thinks I'm offline in ubuntu.)
  The main problem is with this setup is that after resume the route metrics 
get mixed up, and the host tries to use the VM network as its default route.
  Adding a 'dhcp4-overrides: {route-metric: 10}' stanza to LAN - as the netplan 
documentation suggests - results in the interfaces not coming up. (Issuing 
'netplan try' results in 'Warning: The unit file, source configuration file or 
drop-ins of netplan-ovs-cleanup.service changed on disk. Run 'systemctl 
daemon-reload' to reload units.'.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060778/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

I didn't hear about any blocker and in the "Foundation Leadership Sync"
meeting people were overall positive about the change. I'm dropping the
"block-proposed" tag.

** Tags removed: block-proposed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  Fix Committed
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

** Changed in: netplan.io (Ubuntu Noble)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  Fix Committed
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

Extensive testing, from different teams and individuals, has happened in
this bug report and especially in the upstream PR
https://github.com/canonical/netplan/pull/456. This is in addition to
the newly added build-time tests and autopkgtests.

This change affects the "systemd-networkd-wait-online" behavior via 
"/run/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf" 
and should not affect core-networking. If anything goes wrong the change can 
easily be disabled (at runtime):
$ mkdir -p /etc/systemd/system/systemd-networkd-wait-online.service.d
$ ln -s /dev/null 
/etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf


I went ahead and uploaded this as 
https://launchpad.net/ubuntu/+source/netplan.io/1.0-2ubuntu1

This bug is still "block-proposed", to give a last chance to anybody who
feels like there is still a blocker in this upload.

** Changed in: netplan.io (Ubuntu Noble)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  In Progress
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

** Changed in: systemd (Ubuntu Noble)
   Status: Confirmed => Invalid

** Tags removed: foundations-todo
** Tags added: block-proposed update-excuse

** Changed in: netplan.io (Ubuntu Noble)
   Status: Confirmed => In Progress

** Changed in: netplan.io (Ubuntu Noble)
 Assignee: (unassigned) => Lukas Märdian (slyon)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Invalid
Status in netplan.io source package in Noble:
  In Progress
Status in systemd source package in Noble:
  Invalid

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

> In the past it was okay to NOT have "optional: true" set for both: encc000 
> and encc000.2653 (and I found that logical, since both interfaces are needed 
> in a VLAN context).
> 
> Knowing now what's missing, I could live with that (even if it's a change in 
> behavior).

Interesting.. I suspect some infrastructure changes here. The default
for systemd-networkd-wait-online is to wait on the "degraded"
operational state, i.e. having a link-local address assigned to the
interface.

If there is SLAAC or IPv6 RA enabled on the other side of "encc000", the
interface might come online without "optional: true". But lacking such
setup, it would be stuck in the "configuring" state, as it waits for an
(IPv6) link-locaL address, putting it as "optional: true" helps in that
case with our recent changes.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  Confirmed
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

With version ~ppa5 we're now skipping the activation of systemd-
networkd-wait-online.service in case all Netplan interfaces are defined
to be "optional: true", using "ConditionPathIsSymbolicLink=" on
Netplan's s-n-wait-online.service enablement link, that's only set when
we have non-optional interfaces.

All the magic happens in /run/systemd/system/systemd-networkd-wait-
online.service.d/10-netplan.conf override under the generic "systemd-
networkd-wait-online.service" umbrella.

Code is up-to-date in https://github.com/canonical/netplan/pull/456
Test buidls in PPA: 
https://launchpad.net/~slyon/+archive/ubuntu/lp2060311/+packages

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  Confirmed
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

Thanks for testing! There is a failure in your 
systemd-networkd-wait-online.service logs:
> systemd-networkd-wait-online.service: Main process exited, code=exited, 
> status=1/FAILURE

I fixed this failure in the ~ppa4 version. Could you confirm the failure
is gone with that newer version and still no delay?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  Confirmed
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

New attempt, that should be transparent to cloud-init, as we're just
creating a /run/systemd/systemd-networkd-wait-
online.service.d/10-netplan.conf override config, specifiying non-
optional interfaces as "/lib/systemd/systemd-networkd-wait-online -i
eth0 -i eth2 -i ..", but keeping the overall service in place.

https://github.com/canonical/netplan/pull/456

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  Confirmed
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

cloud-init seems to order After=sytemd-networkd-wait-online.service AND
Before=network-online.target. So the proposed solution is a no-go.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  Confirmed
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060778] Re: netplan, multiple dhcp route with metric failure

[Lukas Märdian]

Are you using NetworkManager in parallel here? Could you please provide
the output of `nmcli dev`? The applications you mention (App Store,
Settings/Online Accounts,...) seem to be Desktop centric and might rely
on NetworkManager functionality for the connectivity checker, which
systemd-networkd might not be able to provide.

** Changed in: netplan
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060778

Title:
  netplan, multiple dhcp route with metric failure

Status in Netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  Hardware/network: PC with single NIC, multiple vlans:
   - untagged: default LAN, should be used by the host
   - vlan 15: VM network, should only be used by the VM(s) running on the host

  Netplan config:

  network:
version: 2
renderer: networkd
ethernets:
  lan:
match:
  macaddress: "XX:XX:XX:XX:XX:XX"
set-name: lan
mtu: 9000
dhcp4: yes
dhcp6: yes
ipv6-privacy: true
bridges:
  vm-br0:
dhcp4: yes
interfaces: [vm]
dhcp4-overrides:
  route-metric: 200
vlans:
  vm:
id: 15
link: lan

  (Using networkd as the renderer some apps [App Store, Settings/Online 
Accounts,...] thinks I'm offline in ubuntu.)
  The main problem is with this setup is that after resume the route metrics 
get mixed up, and the host tries to use the VM network as its default route.
  Adding a 'dhcp4-overrides: {route-metric: 10}' stanza to LAN - as the netplan 
documentation suggests - results in the interfaces not coming up. (Issuing 
'netplan try' results in 'Warning: The unit file, source configuration file or 
drop-ins of netplan-ovs-cleanup.service changed on disk. Run 'systemctl 
daemon-reload' to reload units.'.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060778/+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

[Touch-packages] [Bug 2060778] Re: netplan, multiple dhcp route with metric failure

[Lukas Märdian]

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060778

Title:
  netplan, multiple dhcp route with metric failure

Status in Netplan:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hardware/network: PC with single NIC, multiple vlans:
   - untagged: default LAN, should be used by the host
   - vlan 15: VM network, should only be used by the VM(s) running on the host

  Netplan config:

  network:
version: 2
renderer: networkd
ethernets:
  lan:
match:
  macaddress: "XX:XX:XX:XX:XX:XX"
set-name: lan
mtu: 9000
dhcp4: yes
dhcp6: yes
ipv6-privacy: true
bridges:
  vm-br0:
dhcp4: yes
interfaces: [vm]
dhcp4-overrides:
  route-metric: 200
vlans:
  vm:
id: 15
link: lan

  (Using networkd as the renderer some apps [App Store, Settings/Online 
Accounts,...] thinks I'm offline in ubuntu.)
  The main problem is with this setup is that after resume the route metrics 
get mixed up, and the host tries to use the VM network as its default route.
  Adding a 'dhcp4-overrides: {route-metric: 10}' stanza to LAN - as the netplan 
documentation suggests - results in the interfaces not coming up. (Issuing 
'netplan try' results in 'Warning: The unit file, source configuration file or 
drop-ins of netplan-ovs-cleanup.service changed on disk. Run 'systemctl 
daemon-reload' to reload units.'.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060778/+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

[Touch-packages] [Bug 2055333] Re: netplan.io 0.106.1-7ubuntu0.22.04.2 fails to manage additional loopback addresses on Ubuntu 2204 Jammy

[Lukas Märdian]

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2055333

Title:
  netplan.io 0.106.1-7ubuntu0.22.04.2 fails to manage additional
  loopback addresses on Ubuntu 2204 Jammy

Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Attempting to add additional loopback addresses to 22.04 jammy fails
  with the latest netplan.io package. Previous versions (.104) work
  correctly as well as newer versions (0.107) in 23.10 mantic.  Behavior
  does not change if default loopback addresses are or are not present
  in the address list (127.0.0.1/8 and ::1/128).

  Netplan is configured via cloudinit in our environment but for
  simplicity I'll provide output from a manual configuration on a test
  vm in virtual box.

  
  root@ubuntu-jammy-test:~# cat /etc/netplan/10-loopback.yaml 
  network:
  version: 2
  ethernets:
  lo:
  addresses:
  - 10.10.10.10/32
  match:
  macaddress: 00:00:00:00:00:00
  set-name: lo
  root@ubuntu-jammy-test:~# netplan apply 
  WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.
  root@ubuntu-jammy-test:~# ip addr show lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  root@ubuntu-jammy-test:~# networkctl list
  IDX LINK   TYPE OPERATIONAL SETUP 
1 lo loopback carrier unmanaged
2 enp0s3 etherroutableconfigured

  2 links listed.
  root@ubuntu-jammy-test:~# apt-get install -y --allow-downgrades 
netplan.io=0.104-0ubuntu2 libnetplan0=0.104-0ubuntu2
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Suggested packages:
network-manager | wpasupplicant openvswitch-switch
  The following packages will be DOWNGRADED:
libnetplan0 netplan.io
  0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 0 not upgraded.
  Need to get 0 B/181 kB of archives.
  After this operation, 163 kB disk space will be freed.
  dpkg: warning: downgrading netplan.io from 0.106.1-7ubuntu0.22.04.2 to 
0.104-0ubuntu2
  (Reading database ... 69845 files and directories currently installed.)
  Preparing to unpack .../netplan.io_0.104-0ubuntu2_amd64.deb ...
  Unpacking netplan.io (0.104-0ubuntu2) over (0.106.1-7ubuntu0.22.04.2) ...
  dpkg: warning: downgrading libnetplan0:amd64 from 0.106.1-7ubuntu0.22.04.2 to 
0.104-0ubuntu2
  Preparing to unpack .../libnetplan0_0.104-0ubuntu2_amd64.deb ...
  Unpacking libnetplan0:amd64 (0.104-0ubuntu2) over (0.106.1-7ubuntu0.22.04.2) 
...
  Setting up libnetplan0:amd64 (0.104-0ubuntu2) ...
  Setting up netplan.io (0.104-0ubuntu2) ...
  Processing triggers for libc-bin (2.35-0ubuntu3.6) ...
  Processing triggers for man-db (2.10.2-1) ...
  Processing triggers for dbus (1.12.20-2ubuntu4.1) ...
  Scanning processes... 

 
  Scanning linux images...  

 

  Running kernel seems to be up-to-date.

  No services need to be restarted.

  No containers need to be restarted.

  No user sessions are running outdated binaries.

  No VM guests are running outdated hypervisor (qemu) binaries on this host.
  root@ubuntu-jammy-test:~# netplan apply 
  root@ubuntu-jammy-test:~# ip addr show lo
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet 10.10.10.10/32 scope global lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  root@ubuntu-jammy-test:~# networkctl list
  IDX LINK   TYPE OPERATIONAL SETUP 
1 lo loopback routableconfigured
2 enp0s3 etherroutableconfigured

  2 links listed.


  root@ubuntu-jammy-test:~# apt-get upgrade -y 
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Calculating upgrade... Done
  The following packages will be upgraded:
libnetplan0 netplan.io
  2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B/215 kB of

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

Thanks for testing!

Heinrich confirmed offline, that the IPv4 address will come online
asynchronously, as expected for an "optional: true" definition.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  New
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

Can somebody please confirm that Netplan from this PPA fixes the
problem?
https://launchpad.net/~slyon/+archive/ubuntu/lp2060311/+packages

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in netplan.io source package in Noble:
  New
Status in systemd source package in Noble:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

I started some work to help with this here:
https://github.com/canonical/netplan/pull/455

** Changed in: netplan
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

** Changed in: netplan
 Assignee: (unassigned) => Lukas Märdian (slyon)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  In Progress
Status in Ubuntu on IBM z Systems:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2058976] Re: Configuration files for networkd are created when NetworkManager is the default renderer

[Lukas Märdian]

Here I produced some networkd debug logs on a UC22 system.

** Attachment added: "networkd-debug.log"
   
https://bugs.launchpad.net/netplan/+bug/2058976/+attachment/5762821/+files/networkd-debug.log

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2058976

Title:
  Configuration files for networkd are created when NetworkManager is
  the default renderer

Status in Netplan:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is happening in a UC image created with a gadget that disables
  console-conf:

  $ ubuntu-image snap --snap=network-manager=22 --snap pc_22.snap

  The snaps are:

  $ snap list
  Name Version RevTracking Publisher   Notes
  core22   202403211344   latest/edge  canonical✓  base
  network-manager  1.36.6-987622/stablecanonical✓  -
  pc   22-0.3  x1 --   
gadget
  pc-kernel5.15.0-102.112.1+1  1731   22/beta  canonical✓  
kernel
  snapd2.62+git2017.g1afc063e  21490  latest/edge  canonical✓  snapd

  On first boot, the content in /etc/netplan is:

  ubuntu@ubuntu:~$ cat /etc/netplan/00-default-nm-renderer.yaml 
  network:
renderer: NetworkManager
  ubuntu@ubuntu:~$ cat /etc/netplan/50-cloud-init.yaml 
  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: '52:54:00:12:34:56'
  set-name: ens3
  version: 2

  
  But we have a configuration file for systemd-networkd that should not be 
there:

  ubuntu@ubuntu:~$ cat /run/systemd/network/10-netplan-ens3.link 
  [Match]
  PermanentMACAddress=52:54:00:12:34:56

  [Link]
  Name=ens3
  WakeOnLan=off

  ubuntu@ubuntu:~$ networkctl 
  IDX LINK TYPE OPERATIONAL SETUP 
1 lo   loopback carrier unmanaged
2 ens3 etherroutableconfigured

  While having to:

  ubuntu@ubuntu:~$ sudo cat 
/run/NetworkManager/system-connections/netplan-ens3.nmconnection
  [connection]
  id=netplan-ens3
  type=ethernet
  interface-name=ens3

  [ethernet]
  wake-on-lan=0

  [ipv4]
  method=auto

  [ipv6]
  method=ignore

  ubuntu@ubuntu:~$ nmcli c
  NAME  UUID  TYPE  DEVICE 
  netplan-ens3  bec3d02a-c9e5-3283-92ab-ee43a4246c85  ethernet  ens3   

  ubuntu@ubuntu:~$ nmcli d
  DEVICE  TYPE  STATE  CONNECTION   
  ens3ethernet  connected  netplan-ens3 
  lo  loopback  unmanaged  --

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2058976/+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

[Touch-packages] [Bug 2058976] Re: Configuration files for networkd are created when NetworkManager is the default renderer

[Lukas Märdian]

I think I can reporudce this on classic...

lxc launch --vm ubuntu-daily:jammy nd-reload
lxc shell nd-reload
root@nd-reload:~# netplan get
network:
  version: 2
  ethernets:
enp5s0:
  dhcp4: true
root@nd-reload:~# networkctl 
IDX LINK   TYPE OPERATIONAL SETUP 
  1 lo loopback carrier unmanaged
  2 enp5s0 etherroutableconfigured

2 links listed.
root@nd-reload:~# snap install network-manager --channel=22/stable
root@nd-reload:~# networkctl 
IDX LINK   TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 enp5s0 etherroutableunmanaged

2 links listed.
root@nd-reload:~# udevadm trigger
root@nd-reload:~# networkctl 
IDX LINK   TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 enp5s0 etherroutablefailed   
root@nd-reload:~# networkctl reload
root@nd-reload:~# networkctl reconfigure enp5s0
root@nd-reload:~# networkctl 
IDX LINK   TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 enp5s0 ethercarrier unmanaged

2 links listed.
root@nd-reload:~# udevadm trigger
root@nd-reload:~# networkctl 
IDX LINK   TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 enp5s0 ethercarrier failed   

2 links listed.

After calling "systemctl restart systemd-networkd.service" once, the
issue seems to be gone.

I do not yet fully understand what the failure condition is, though?
"networkctl" show a "failed" link. But NetworkManager is managing it fine and 
the network is reachable.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2058976

Title:
  Configuration files for networkd are created when NetworkManager is
  the default renderer

Status in Netplan:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is happening in a UC image created with a gadget that disables
  console-conf:

  $ ubuntu-image snap --snap=network-manager=22 --snap pc_22.snap

  The snaps are:

  $ snap list
  Name Version RevTracking Publisher   Notes
  core22   202403211344   latest/edge  canonical✓  base
  network-manager  1.36.6-987622/stablecanonical✓  -
  pc   22-0.3  x1 --   
gadget
  pc-kernel5.15.0-102.112.1+1  1731   22/beta  canonical✓  
kernel
  snapd2.62+git2017.g1afc063e  21490  latest/edge  canonical✓  snapd

  On first boot, the content in /etc/netplan is:

  ubuntu@ubuntu:~$ cat /etc/netplan/00-default-nm-renderer.yaml 
  network:
renderer: NetworkManager
  ubuntu@ubuntu:~$ cat /etc/netplan/50-cloud-init.yaml 
  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: '52:54:00:12:34:56'
  set-name: ens3
  version: 2

  
  But we have a configuration file for systemd-networkd that should not be 
there:

  ubuntu@ubuntu:~$ cat /run/systemd/network/10-netplan-ens3.link 
  [Match]
  PermanentMACAddress=52:54:00:12:34:56

  [Link]
  Name=ens3
  WakeOnLan=off

  ubuntu@ubuntu:~$ networkctl 
  IDX LINK TYPE OPERATIONAL SETUP 
1 lo   loopback carrier unmanaged
2 ens3 etherroutableconfigured

  While having to:

  ubuntu@ubuntu:~$ sudo cat 
/run/NetworkManager/system-connections/netplan-ens3.nmconnection
  [connection]
  id=netplan-ens3
  type=ethernet
  interface-name=ens3

  [ethernet]
  wake-on-lan=0

  [ipv4]
  method=auto

  [ipv6]
  method=ignore

  ubuntu@ubuntu:~$ nmcli c
  NAME  UUID  TYPE  DEVICE 
  netplan-ens3  bec3d02a-c9e5-3283-92ab-ee43a4246c85  ethernet  ens3   

  ubuntu@ubuntu:~$ nmcli d
  DEVICE  TYPE  STATE  CONNECTION   
  ens3ethernet  connected  netplan-ens3 
  lo  loopback  unmanaged  --

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2058976/+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

[Touch-packages] [Bug 2058976] Re: Configuration files for networkd are created when NetworkManager is the default renderer

[Lukas Märdian]

Alfonso, do you have any debug-logs for sytemd-networkd and udev to see
what happens when the interface enters the "failed" state?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2058976

Title:
  Configuration files for networkd are created when NetworkManager is
  the default renderer

Status in Netplan:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is happening in a UC image created with a gadget that disables
  console-conf:

  $ ubuntu-image snap --snap=network-manager=22 --snap pc_22.snap

  The snaps are:

  $ snap list
  Name Version RevTracking Publisher   Notes
  core22   202403211344   latest/edge  canonical✓  base
  network-manager  1.36.6-987622/stablecanonical✓  -
  pc   22-0.3  x1 --   
gadget
  pc-kernel5.15.0-102.112.1+1  1731   22/beta  canonical✓  
kernel
  snapd2.62+git2017.g1afc063e  21490  latest/edge  canonical✓  snapd

  On first boot, the content in /etc/netplan is:

  ubuntu@ubuntu:~$ cat /etc/netplan/00-default-nm-renderer.yaml 
  network:
renderer: NetworkManager
  ubuntu@ubuntu:~$ cat /etc/netplan/50-cloud-init.yaml 
  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: '52:54:00:12:34:56'
  set-name: ens3
  version: 2

  
  But we have a configuration file for systemd-networkd that should not be 
there:

  ubuntu@ubuntu:~$ cat /run/systemd/network/10-netplan-ens3.link 
  [Match]
  PermanentMACAddress=52:54:00:12:34:56

  [Link]
  Name=ens3
  WakeOnLan=off

  ubuntu@ubuntu:~$ networkctl 
  IDX LINK TYPE OPERATIONAL SETUP 
1 lo   loopback carrier unmanaged
2 ens3 etherroutableconfigured

  While having to:

  ubuntu@ubuntu:~$ sudo cat 
/run/NetworkManager/system-connections/netplan-ens3.nmconnection
  [connection]
  id=netplan-ens3
  type=ethernet
  interface-name=ens3

  [ethernet]
  wake-on-lan=0

  [ipv4]
  method=auto

  [ipv6]
  method=ignore

  ubuntu@ubuntu:~$ nmcli c
  NAME  UUID  TYPE  DEVICE 
  netplan-ens3  bec3d02a-c9e5-3283-92ab-ee43a4246c85  ethernet  ens3   

  ubuntu@ubuntu:~$ nmcli d
  DEVICE  TYPE  STATE  CONNECTION   
  ens3ethernet  connected  netplan-ens3 
  lo  loopback  unmanaged  --

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2058976/+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

[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image

[Lukas Märdian]

Also see bug #2036358

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311

Title:
  Setting "optional: true" to overcome he timeout "Job systemd-networkd-
  wait-online" does no longer work with latest noble image

Status in Netplan:
  New
Status in Ubuntu on IBM z Systems:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Especially on s390x (but not limited to s390x) it's often the case that a 
system has network devices that are not necessarily connected during boot-up 
and one gets such a 2 min timeout:
  "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"

  In the past I could avoid that by setting "optional: true" post-install (no 
perfect, but worked),
  but this does no longer seem to work using the latest noble ISO image (Apr 
5th).

  Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
  this for me:

  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  enP1p0s0:
  optional: true
  dhcp4: true
  enP1p0s0d1:
  optional: true
  dhcp4: true
  enP2p0s0:
  optional: true
  dhcp4: true
  enP2p0s0d1:
  optional: true
  dhcp4: true
  encc000: {}
  version: 2
  vlans:
  encc000.2653:
  addresses:
  - 10.11.12.15/24
  gateway4: 10.11.12.1
  id: 2653
  link: encc000
  nameservers:
  addresses:
  - 10.11.12.1

  ... can be set fine (also --dry-run does not moan, except about
  dhcp4).

  This worked in the past on noble, but also on older Ubuntu releases
  like jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+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

[Touch-packages] [Bug 2058930] Re: Missing in i386 Packages index

[Lukas Märdian]

** Tags removed: rls-nn-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libvpx in Ubuntu.
https://bugs.launchpad.net/bugs/2058930

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  Fix Released

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+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

[Touch-packages] [Bug 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

[Lukas Märdian]

https://github.com/canonical/netplan/pull/447

** Changed in: netplan
   Status: Triaged => Fix Committed

-- 
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/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in Netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2055148/+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

[Touch-packages] [Bug 2058976] Re: Configuration files for networkd are created when NetworkManager is the defauilt renderer

[Lukas Märdian]

> alfonsosanchezbeato: to be clear, the networkctl reload/reconfigure commands 
> seem to work, but after 6-8 minutes the state goes back to the one expressed 
> by the old .network files
> alfonsosanchezbeato: you can even force the revert to happen sooner with sudo 
> udevadm trigger, with that it tries to get control back too

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Summary changed:

- Configuration files for networkd are created when NetworkManager is the 
defauilt renderer
+ Configuration files for networkd are created when NetworkManager is the 
default renderer

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2058976

Title:
  Configuration files for networkd are created when NetworkManager is
  the default renderer

Status in Netplan:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is happening in a UC image created with a gadget that disables
  console-conf:

  $ ubuntu-image snap --snap=network-manager=22 --snap pc_22.snap

  The snaps are:

  $ snap list
  Name Version RevTracking Publisher   Notes
  core22   202403211344   latest/edge  canonical✓  base
  network-manager  1.36.6-987622/stablecanonical✓  -
  pc   22-0.3  x1 --   
gadget
  pc-kernel5.15.0-102.112.1+1  1731   22/beta  canonical✓  
kernel
  snapd2.62+git2017.g1afc063e  21490  latest/edge  canonical✓  snapd

  On first boot, the content in /etc/netplan is:

  ubuntu@ubuntu:~$ cat /etc/netplan/00-default-nm-renderer.yaml 
  network:
renderer: NetworkManager
  ubuntu@ubuntu:~$ cat /etc/netplan/50-cloud-init.yaml 
  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: '52:54:00:12:34:56'
  set-name: ens3
  version: 2

  
  But we have a configuration file for systemd-networkd that should not be 
there:

  ubuntu@ubuntu:~$ cat /run/systemd/network/10-netplan-ens3.link 
  [Match]
  PermanentMACAddress=52:54:00:12:34:56

  [Link]
  Name=ens3
  WakeOnLan=off

  ubuntu@ubuntu:~$ networkctl 
  IDX LINK TYPE OPERATIONAL SETUP 
1 lo   loopback carrier unmanaged
2 ens3 etherroutableconfigured

  While having to:

  ubuntu@ubuntu:~$ sudo cat 
/run/NetworkManager/system-connections/netplan-ens3.nmconnection
  [connection]
  id=netplan-ens3
  type=ethernet
  interface-name=ens3

  [ethernet]
  wake-on-lan=0

  [ipv4]
  method=auto

  [ipv6]
  method=ignore

  ubuntu@ubuntu:~$ nmcli c
  NAME  UUID  TYPE  DEVICE 
  netplan-ens3  bec3d02a-c9e5-3283-92ab-ee43a4246c85  ethernet  ens3   

  ubuntu@ubuntu:~$ nmcli d
  DEVICE  TYPE  STATE  CONNECTION   
  ens3ethernet  connected  netplan-ens3 
  lo  loopback  unmanaged  --

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2058976/+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

[Touch-packages] [Bug 2058930] Re: Missing in i386 Packages index

[Lukas Märdian]

A fix was deployed (cowboyed) to the autopkgtest-cloud today.

** Changed in: libvpx (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libvpx in Ubuntu.
https://bugs.launchpad.net/bugs/2058930

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  Fix Committed

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+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

[Touch-packages] [Bug 2058930] Re: Missing in i386 Packages index

[Lukas Märdian]

Actually, this seems to be an issue of the source package not being
pulled from -proposed, as I can install the binaries just fine in a LXD
container:

root@nn:~# dpkg --add-architecture i386
root@nn:~# apt update
[...]
root@nn:~# apt install libvpx9:i386
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libnsl-dev libtirpc-dev
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  gcc-14-base:i386 libc-bin libc-dev-bin libc-devtools libc6 libc6:i386 
libc6-dev libgcc-s1:i386 libidn2-0:i386
  libunistring5:i386 locales
Suggested packages:
  glibc-doc glibc-doc:i386 locales:i386 libnss-nis:i386 libnss-nisplus:i386
The following NEW packages will be installed:
  gcc-14-base:i386 libc6:i386 libgcc-s1:i386 libidn2-0:i386 libunistring5:i386 
libvpx9:i386
The following packages will be upgraded:
  libc-bin libc-dev-bin libc-devtools libc6 libc6-dev locales
6 upgraded, 6 newly installed, 0 to remove and 7 not upgraded.
Need to get 15.3 MB of archives.
After this operation, 18.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
[...]
Get:12 http://archive.ubuntu.com/ubuntu noble-proposed/main i386 libvpx9 i386 
1.14.0-1ubuntu1 [1129 kB]


0


root@nn:~# apt-get source libvpx
Reading package lists... Done
NOTICE: 'libvpx' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/multimedia-team/libvpx.git
Please use:
git clone https://salsa.debian.org/multimedia-team/libvpx.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 4332 kB of source archives.
Get:1 http://archive.ubuntu.com/ubuntu noble/main libvpx 1.13.1-2ubuntu1 (dsc) 
[2366 B]
Get:2 http://archive.ubuntu.com/ubuntu noble/main libvpx 1.13.1-2ubuntu1 (tar) 
[4316 kB]
Get:3 http://archive.ubuntu.com/ubuntu noble/main libvpx 1.13.1-2ubuntu1 (diff) 
[13.6 kB]
Fetched 4332 kB in 1s (8427 kB/s)
dpkg-source: info: extracting libvpx in libvpx-1.13.1
dpkg-source: info: unpacking libvpx_1.13.1.orig.tar.xz
dpkg-source: info: unpacking libvpx_1.13.1-2ubuntu1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Relax-ABI-check.patch
dpkg-source: info: applying 0002-Do-not-undefine-_FORTIFY_SOURCE.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libvpx in Ubuntu.
https://bugs.launchpad.net/bugs/2058930

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  New

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+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

[Touch-packages] [Bug 2058930] Re: Missing in i386 Packages index

[Lukas Märdian]

** Description changed:

- The new version of libvpx 1.14 seems to be missing in
- http://archive.ubuntu.com/ubuntu/dists/noble-
- proposed/main/binary-i386/Packages.xz, while it's still available in
- http://archive.ubuntu.com/ubuntu/dists/noble-
- proposed/main/binary-i386/Packages.gz.
- 
- Grep for "Source: libvpx".
+ The new version of libvpx 1.14 seems not to be published to
+ http://ftpmaster.internal on i386 only.
  
  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libvpx in Ubuntu.
https://bugs.launchpad.net/bugs/2058930

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  New

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+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

[Touch-packages] [Bug 2058930] [NEW] Missing in i386 Packages index

[Lukas Märdian]

Public bug reported:

The new version of libvpx 1.14 seems not to be published to
http://ftpmaster.internal on i386 only.

This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having any 
effect on i386:
https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

** Affects: libvpx (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: rls-nn-incoming update-excuse

** Tags added: rls-nn-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libvpx in Ubuntu.
https://bugs.launchpad.net/bugs/2058930

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  New

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+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

[Touch-packages] [Bug 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

[Lukas Märdian]

** Tags added: fr-7190

-- 
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/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in Netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2055148/+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

[Touch-packages] [Bug 2058743] Re: systemd local DNS tests failing with timeout

[Lukas Märdian]

Could you please provide journalctl debug logs from systemd-resolved, so
we can get more details of what's going on?


e.g. put this into the systemd-resolved override.conf

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

$ sudo systemctl edit systemd-resolved
$ sudo systemctl restart systemd-resolved

And maybe also provide dnsmasq logs.

** Tags added: rls-jj-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2058743

Title:
  systemd local DNS tests failing with timeout

Status in dnsmasq package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Investigations done in 22.04/Jammy but may be affecting other series,
  too.

  The dnsmasq package recently was updated from 2.86-1.1ubuntu0.5 to
  2.90-0ubuntu0.22.04.1. This seems to have brought back the same issue
  reported in bug #1957086. Sounds like both have interaction issues.

  To reproduce:

  $ pull-lp-source systemd jammy
  # Install test deps
  $ sudo apt install systemd udev libpam-systemd libnss-systemd acl locales 
evemu-tools python3 pkg-config cryptsetup-bin systemd-sysv policykit-1 
dnsmasq-base
  $ cd systemd-249.11/test/
  $ sudo ./networkd-test.py

  ==
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/home/ubuntu/systemd-249.11/test/./networkd-test.py", line 678, in 
test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.10/subprocess.py", line 421, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.10/subprocess.py", line 526, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.

  --
  Ran 35 tests in 252.167s

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2058743/+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

[Touch-packages] [Bug 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

[Lukas Märdian]

We should land a fix keeping the full string in
networkmanager.passthrough and additionaly work on a proper upstream
solution, as suggested by Danilo in comment #4, introducing new settings
as a longer term solution.

** Changed in: netplan
   Status: New => Triaged

** Changed in: netplan
   Importance: Undecided => High

-- 
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/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2055148/+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

[Touch-packages] [Bug 2055397] Re: netplan/systemd-networkd: route metric not applied to routes to the local subnet

[Lukas Märdian]

Thanks for the heads-up for Netplan! IIUC this will be fixed by a
systemd SRU, so closing it as "Invalid" for Netplan. Please re-open if
you feel there is something to do on our side.

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2055397

Title:
  netplan/systemd-networkd: route metric not applied to routes to the
  local subnet

Status in cloud-init package in Ubuntu:
  Invalid
Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  New

Bug description:
  Cloud-init introduced a feature to configure policy routing on AWS EC2 
instances with multiple NICs in
  
https://github.com/canonical/cloud-init/commit/0ca5f31043e2d98eab31a43d9dde9bdaef1435cb
 targeting v24.1.

  Cloud-init generates the following netplan config:

  ```
  $ cat /etc/netplan/50-cloud-init.yaml
  network:
  ethernets:
  ens5:
  dhcp4: true
  dhcp4-overrides: &id001
  route-metric: 100
  dhcp6: true
  dhcp6-overrides: *id001
  match:
  macaddress: 0a:c8:ab:90:c2:fb
  set-name: ens5
  ens6:
  dhcp4: true
  dhcp4-overrides:
  route-metric: 200
  use-routes: true
  dhcp6: false
  match:
  macaddress: 0a:c6:55:a1:dc:3b
  routes:
  -   table: 101
  to: 0.0.0.0/0
  via: 192.168.0.1
  -   table: 101
  to: 192.168.0.0/20
  routing-policy:
  -   from: 192.168.10.212
  table: 101
  set-name: ens6
  version: 2
  ```

  Which renders the following systemd-networkd config files:

  ```
  $ cat 10-netplan-ens5.link
  [Match]
  MACAddress=0a:c8:ab:90:c2:fb

  [Link]
  Name=ens5
  WakeOnLan=off

  
  $ cat 10-netplan-ens5.network
  [Match]
  MACAddress=0a:c8:ab:90:c2:fb
  Name=ens5

  [Network]
  DHCP=yes
  LinkLocalAddressing=ipv6

  [DHCP]
  RouteMetric=100
  UseMTU=true

  
  $ cat 10-netplan-ens6.link
  [Match]
  MACAddress=0a:c6:55:a1:dc:3b

  [Link]
  Name=ens6
  WakeOnLan=off

  
  $ cat 10-netplan-ens6.network
  [Match]
  MACAddress=0a:c6:55:a1:dc:3b
  Name=ens6

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6

  [Route]
  Destination=0.0.0.0/0
  Gateway=192.168.0.1
  Table=101

  [Route]
  Destination=192.168.0.0/20
  Scope=link
  Table=101

  [RoutingPolicyRule]
  From=192.168.10.212
  Table=101

  [DHCP]
  RouteMetric=200
  UseMTU=true
  ```

  Which configures the instance with the following state in Ubuntu
  Focal:

  ```
  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
  2: ens5:  mtu 9001 qdisc mq state UP group 
default qlen 1000
  link/ether 0a:c8:ab:90:c2:fb brd ff:ff:ff:ff:ff:ff
  inet 192.168.12.94/20 brd 192.168.15.255 scope global dynamic ens5
 valid_lft 2087sec preferred_lft 2087sec
  inet6 2a05:d012:ea0:c500:6d12:2b20:5fef:a502/128 scope global dynamic 
noprefixroute
 valid_lft 440sec preferred_lft 130sec
  inet6 fe80::8c8:abff:fe90:c2fb/64 scope link
 valid_lft forever preferred_lft forever
  3: ens6:  mtu 9001 qdisc mq state UP group 
default qlen 1000
  link/ether 0a:c6:55:a1:dc:3b brd ff:ff:ff:ff:ff:ff
  inet 192.168.10.212/20 brd 192.168.15.255 scope global dynamic ens6
 valid_lft 2083sec preferred_lft 2083sec
  inet6 fe80::8c6:55ff:fea1:dc3b/64 scope link
 valid_lft forever preferred_lft forever

  
  $ ip route show
  default via 192.168.0.1 dev ens5 proto dhcp src 192.168.12.94 metric 100
  default via 192.168.0.1 dev ens6 proto dhcp src 192.168.10.212 metric 200
  192.168.0.0/20 dev ens5 proto kernel scope link src 192.168.12.94
  192.168.0.0/20 dev ens6 proto kernel scope link src 192.168.10.212
  192.168.0.1 dev ens5 proto dhcp scope link src 192.168.12.94 metric 100
  192.168.0.1 dev ens6 proto dhcp scope link src 192.168.10.212 metric 200

  $ ip rule show
  0:  from all lookup local
  0:  from 192.168.10.212 lookup 101
  32766:  from all lookup main
  32767:  from all lookup default

  
  $ ip route show table 101
  default via 192.168.0.1 dev ens6 proto static onlink
  192.168.0.0/20 dev ens6 proto static scope link
  ```

  The issue here is that the instance is not reachable from the same subnet via 
the private ipv4 of the primary NIC,
  packets are routed to egress via ens6 and dropped.

  The cause is that interface metrics are not applied to loca

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

This will be part of 1.0-1

** Changed in: netplan.io (Ubuntu)
   Status: New => Fix Committed

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  Fix Committed
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2058231] [NEW] Fallback to IPv4-LL when DHCP is failing

[Lukas Märdian]

Public bug reported:

The intention of the previous avahi-autoipd integration was that on a
connection that does have dhcp configured, it will fall back to IPV4LL
if dhcp is unavailable.

This integration was recently dropped (and I think it never worked as intended 
in the first place):
https://code.launchpad.net/~vorlon/ubuntu-seeds/+git/ubuntu/+merge/460785

We want to implement this functionality in Ubuntu/NetworkManager and there's 
some upstream work tracking this too:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/966

See FR-4142

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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/2058231

Title:
  Fallback to IPv4-LL when DHCP is failing

Status in network-manager package in Ubuntu:
  New

Bug description:
  The intention of the previous avahi-autoipd integration was that on a
  connection that does have dhcp configured, it will fall back to IPV4LL
  if dhcp is unavailable.

  This integration was recently dropped (and I think it never worked as 
intended in the first place):
  https://code.launchpad.net/~vorlon/ubuntu-seeds/+git/ubuntu/+merge/460785

  We want to implement this functionality in Ubuntu/NetworkManager and there's 
some upstream work tracking this too:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/966

  See FR-4142

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2058231/+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

[Touch-packages] [Bug 2057768] [NEW] Unit and its Alias appear to be separate entities when enabling the unit by filepath

[Lukas Schreiber]

Public bug reported:

### systemd version the issue has been seen with

245

### Used distribution

Linux Mint 20.1 and Ubuntu 20.04

### Linux kernel version used

5.4.0-135-generic

### CPU architectures issue was seen on

None

### Component

systemctl

### Expected behaviour you didn't see

When including an alias in a unit file that is enabled by referring to
its filepath, its alias should refer to the unit - the two should refer
to the exact same service. This is the case when the unit file is
enabled inside one of the systemd directories. I expect alias and unit
to refer to one identical service also when enabling via filepath.

In particular, the output of  `systemctl status ...` should be identical
for a Unit and its Alias.

### Unexpected behaviour you saw

After passing a systemd unit including an alias to `systemctl enable
PATH...` by path, systemctl treated the unit and its alias as separate
units.

Specifically, `systemctl status` reports different results
(running/inactive, PID if applicable) for the unit name and its alias.
When I start the unit by its original name, only the status of the unit
is reported as running while the status of the alias remains inactive,
and vice versa. After starting the Alias too, two services with
different PIDs are running.

(When copying the unit into /etc/systemd/system/ and running `systemctl
enable UNIT...` this issue does not occur and alias and unit behave the
same.)

### Steps to reproduce the problem

```
~$ cat dummy.service
[Service]
ExecStart=tail -f /dev/null

[Install]
Alias=dumb.service
~$ sudo systemctl enable ~/dummy.service
Created symlink /etc/systemd/system/dumb.service →
/home/lukas/dummy.service.
Created symlink /etc/systemd/system/dummy.service →
/home/lukas/dummy.service.
~$ sudo systemctl start dummy
~$ systemctl status dummy
● dummy.service
 Loaded: loaded (/etc/systemd/system/dummy.service; enabled; vendor
preset:>
 Active: active (running) since Tue 2024-03-12 15:36:58 CET; 8s ago
   Main PID: 159809 (tail)
  Tasks: 1 (limit: 76978)
 Memory: 160.0K
 CGroup: /system.slice/dummy.service
 └─159809 /usr/bin/tail -f /dev/null

Mär 12 15:36:58 MyMachine systemd[1]: Started dummy.service.
~$ systemctl status dumb
● dumb.service
 Loaded: loaded (/etc/systemd/system/dumb.service; enabled; vendor
preset: >
 Active: inactive (dead)

Mär 12 15:30:53 MyMachine systemd[1]: Started dumb.service.
Mär 12 15:31:16 MyMachine systemd[1]: Stopping dumb.service...
Mär 12 15:31:16 MyMachine systemd[1]: dumb.service: Succeeded.
Mär 12 15:31:16 MyMachine systemd[1]: Stopped dumb.service.
~$
```

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2057768

Title:
  Unit and its Alias appear to be separate entities when enabling the
  unit by filepath

Status in systemd package in Ubuntu:
  New

Bug description:
  ### systemd version the issue has been seen with

  245

  ### Used distribution

  Linux Mint 20.1 and Ubuntu 20.04

  ### Linux kernel version used

  5.4.0-135-generic

  ### CPU architectures issue was seen on

  None

  ### Component

  systemctl

  ### Expected behaviour you didn't see

  When including an alias in a unit file that is enabled by referring to
  its filepath, its alias should refer to the unit - the two should refer
  to the exact same service. This is the case when the unit file is
  enabled inside one of the systemd directories. I expect alias and unit
  to refer to one identical service also when enabling via filepath.

  In particular, the output of  `systemctl status ...` should be identical
  for a Unit and its Alias.

  ### Unexpected behaviour you saw

  After passing a systemd unit including an alias to `systemctl enable
  PATH...` by path, systemctl treated the unit and its alias as separate
  units.

  Specifically, `systemctl status` reports different results
  (running/inactive, PID if applicable) for the unit name and its alias.
  When I start the unit by its original name, only the status of the unit
  is reported as running while the status of the alias remains inactive,
  and vice versa. After starting the Alias too, two services with
  different PIDs are running.

  (When copying the unit into /etc/systemd/system/ and running `systemctl
  enable UNIT...` this issue does not occur and alias and unit behave the
  same.)

  ### Steps to reproduce the problem

  ```
  ~$ cat dummy.service
  [Service]
  ExecStart=tail -f /dev/null

  [Install]
  Alias=dumb.service
  ~$ sudo systemctl enable ~/dummy.service
  Created symlink /etc/systemd/system/dumb.service →
  /home/lukas/dummy.service.
  Created symlink /etc/systemd/system/dummy.service →
  /home/lukas/dummy.service.
  ~$ sudo systemctl start dummy
  ~$ systemctl status dummy
  ● dummy.service
   Loaded: load

[Touch-packages] [Bug 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile

[Lukas Märdian]

I confirmed the patch matches the upstream changes and builds find. I
see the bug description ([Test] section) was updated to mention pairing
of 7 audio and 2 non-audio devices. That pairing test needs to be re-run
with the final binaries, once they are build in the archive, as per the
usual SRU process.

Sponsoring for Mantic & Jammy, unsubscribing sponsors. The status is
already set to "In Progress".

https://launchpad.net/ubuntu/mantic/+queue?queue_state=1&queue_text=pulseaudio
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=pulseaudio

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/2051895

Title:
  Lenovo XT99 BT headset can't work in HFP profile

Status in HWE Next:
  New
Status in pulseaudio package in Ubuntu:
  Fix Committed
Status in pulseaudio source package in Jammy:
  In Progress
Status in pulseaudio source package in Mantic:
  In Progress
Status in pulseaudio source package in Noble:
  Fix Committed

Bug description:
  [Summary]
  When use the ThinkPluse xt99 bluetooth head set to run the test 
com.canonical.certification::bluetooth/audio_record_playback, it cannot record 
the sound and playback.
  It seems this device cannot switch to Hand free mode in this platform.

  [Steps to reproduce]
  Connect the ThinkPluse xt99, use the Handfree mode, then try to record some 
voice.

  [Expected result]
  The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound.

  [Actual result]
  The bluetooth headset xt99 cannot work in the Handfree mode.

  [Failure rate]
  100%

  [Impact]
  With the current Ubuntu 22.04 oem image, we try to connect the LENOVO
  XT99 bt headset and let it work in HFP mode, we select HFP profile
  from gnome sound-setting, but the microphone will not auto change to
  bt microphone and the bt output could not work too. So this BT headset
  could only work in A2DP mode with the current 22.04 OEM image.

  And we tried ubuntu 22.04 generic image, mantic image and noble image,
  none of them could make the headset work in HFP mode.

  [Fix]
  Cherry-pick a pulseaudio commit from upstream.

  [Test]
  I installed ubuntu 22.04 and 23.10 on 2 different Thinkpad laptops, then 
upgraded the pulseaudio from my ppa (ppa:hui.wang/pa-testing), in theory my 
change only affects bluetooth audio devices, it will not bring any impact to 
non-audio bluetooth devices, here I did the test with 7 bluetooth audio devices 
and 2 non-audio devices:

  BT audio devices (pairing, connection, re-connection, playback and capture 
all worked well):
  PLT_BBTGO2 (headset)
  Xiaomi Air3 SE (headset)
  Crusher Wireless (headset)
  SOAIY S18 (sound box)
  HK Soho Wireless (headset)
  Thinkplus XT99 (headset)
  Wl-1000X (headset)

  BT non-audio devices (pairing, connection, re-connection, key input all 
worked well):
  BT3.0 Keyboard
  The Pinao 2 keyboard

  
  [Where problems could occur]
  This change will impact bt headset negotiation process in the pulseaudio,
  so the possiblity of regression is limited to bt headset, it could make
  the bt headset fail to connect, but this possibility is very low, we tested
  the patch with different bt headset and bt speaker, all worked well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2051895/+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

[Touch-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

[Lukas Märdian]

This patch seems to resolve the situation locally.

For now I'll only go with the changes to tests/integration/base.py,
though. As that should be enough to avoid test failures, while the
service units shouldn't change (besides being re-generated 1:1).

I want to better understand what's going on exactly and why the units
are re-generated multiple times, before applying changes to
netplan_cli/cli/commands/apply.py

** Patch added: 
"0001-tests-integration-Be-less-strict-about-systemctl-dae.patch"
   
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2048388/+attachment/5750250/+files/0001-tests-integration-Be-less-strict-about-systemctl-dae.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/2048388

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2048388/+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

[Touch-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

[Lukas Märdian]

This is related:
https://github.com/canonical/netplan/commit/da6f776dd7e33050124fe2990b715db92c1ddee3

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/2048388

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2048388/+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

[Touch-packages] [Bug 2055148] [NEW] NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

[Lukas Märdian]

Public bug reported:

From: https://discourse.ubuntu.com/t/blog-netplan-developer-
diaries/35932/11

Hi all,

NetworkManager connections with an explicit DoT (DNS over TLS)
configuration are not supported with Netplan, but NetworkManager does
feed back the DoT DNS info with server address and Server Name
Indication (SNI) in the form server_address#SNI, e.g.
1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a result,
subsequent Netplan config applications fail because DNS servers don’t
have the expected dotted decimal (IPv4) or colon’ed hex (IPv6) form.

```
nmcli> describe ipv4.dns

=== [dns] ===
[NM property description]
Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
```

** Affects: netplan
 Importance: Undecided
 Status: New

** Affects: netplan.io (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: netplan-everywhere

** Also affects: netplan
   Importance: Undecided
   Status: New

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in netplan:
  New
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2055148/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

** Changed in: netplan
   Status: In Progress => Fix Committed

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2052951] Re: ncurses/i386 autopkgtest failure

[Lukas Märdian]

https://launchpad.net/ubuntu/+source/ncurses/6.4+20240113-1ubuntu1

Unsubscribing ~ubuntu-sponsors

** Changed in: ncurses (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ncurses in Ubuntu.
https://bugs.launchpad.net/bugs/2052951

Title:
  ncurses/i386 autopkgtest failure

Status in ncurses package in Ubuntu:
  Fix Committed

Bug description:
  ncurses fails to pass its autopkgtests on i386:
  
https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-
  noble/noble/i386/n/ncurses/20240212_101858_8f6ad@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ncurses/+bug/2052951/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

** Changed in: netplan
   Status: Triaged => In Progress

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  In Progress
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2052959] Re: FTBFS when rebuilding 1.44 with glib2-2.79.1

[Lukas Märdian]

Upstream fix landed in:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/7f2a32fa11d580ee65a0458f438018de12b6ae84

** Summary changed:

- FTBFS when rebuilding 1.44 with GCC-14
+ FTBFS when rebuilding 1.44 with glib2-2.79.1

-- 
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/2052959

Title:
  FTBFS when rebuilding 1.44 with glib2-2.79.1

Status in network-manager package in Ubuntu:
  Fix Committed

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+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

[Touch-packages] [Bug 2052959] Re: FTBFS when rebuilding 1.44 with GCC-14

[Lukas Märdian]

Fixed in https://launchpad.net/ubuntu/+source/network-
manager/1.45.90-1ubuntu1

** Changed in: network-manager (Ubuntu)
   Status: New => Fix Committed

-- 
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/2052959

Title:
  FTBFS when rebuilding 1.44 with glib2-2.79.1

Status in network-manager package in Ubuntu:
  Fix Committed

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+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

[Touch-packages] [Bug 2052959] Re: FTBFS when rebuilding 1.44 with GCC-14

[Lukas Märdian]

** Summary changed:

- FTBFS when rebuilding 1.44
+ FTBFS when rebuilding 1.44 with GCC-14

-- 
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/2052959

Title:
  FTBFS when rebuilding 1.44 with GCC-14

Status in network-manager package in Ubuntu:
  New

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+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

[Touch-packages] [Bug 2052959] [NEW] FTBFS when rebuilding 1.44

[Lukas Märdian]

Public bug reported:

FTBFS due to test failure after an unrelated autopkgtest change was
uploaded (https://launchpad.net/ubuntu/+source/network-
manager/1.44.2-7ubuntu2).


ok 7 /config/warnings
PASS: src/core/tests/config/test-config 7 /config/warnings
# (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
exec "./src/core/tests/config/test-config" failed with exit code 133
ERROR: src/core/tests/config/test-config - too few tests run (expected 14, got 
7)
ERROR: src/core/tests/config/test-config - exited with status 5

See upstream bug report:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse

-- 
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/2052959

Title:
  FTBFS when rebuilding 1.44

Status in network-manager package in Ubuntu:
  New

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+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

[Touch-packages] [Bug 2052137] Re: bonded link goes down on reconfigure

[Lukas Märdian]

Looks like this has been fixed in upstream systemd, so there's probably
not a lot that we can do on the Netplan side.

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2052137

Title:
  bonded link goes down on reconfigure

Status in systemd:
  Fix Released
Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-networkd brings down member interfaces of a bond when they get
  reconfigured

  Jan 31 15:43:46 unique-slug systemd-networkd[2430]: pn1: Bringing link
  down

  This has a result that a server has complete downtime for a few
  seconds, this has also been reported upstream
  https://github.com/systemd/systemd/issues/31165.

  A pull request has been opened to fix this
  https://github.com/systemd/systemd/pull/31172

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/2052137/+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

[Touch-packages] [Bug 1958019]

[lukas]

(In reply to Jacob Garby from comment #816)
> (In reply to Lukas from comment #814)
> > (In reply to Jacob Garby from comment #813)
> > > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of
> nowhere,
> > > the speaker started working. I have no idea how -- I did not change
> > anything
> > > manually. I suspect it's a new kernel version that did it.
> > > 
> > > I'm on Arch Linux, and I can't remember which kernel version I have
> > > installed (but I can update when I get home later today).
> > > 
> > > Anyway, good news!
> > 
> > Amazing
> > 
> > I would like to reproduce this. You can find out your current kernel
> version
> > with the command "uname -r". The installed sound packages/libs would also
> be
> > interesting. What I know of would be to look at the alsa version. 
> > Someone else surely has more information on what to specificly look for and
> > how.
> 
> Okay, so my kernel version is 6.7.2-arch1-1
> 
> These are some (maybe all) of the audio related packages I have installed:
> kpipewire 5.27.10-1
> libpipewire 1:1.0.1-2
> pipewire 1:1.0.1-2
> pipewire-alsa 1:1.0.1-2
> pipewire-audio 1:1.0.1-2
> pipewire-jack 1:1.0.1-2
> pipewire-pulse 1:1.0.1-2
> libpulse 17.0-3
> pipewire-pulse 1:1.0.1-2
> projectm-pulseaudio 3.1.12-4
> 
> But I can verify that my speaker did also work _before_ I switched from
> Pulseaudio to Pipewire, seems both should work.
> 
> The result of running alsa-info is here:
> http://alsa-project.org/db/?f=07a1fdaf34a424adc27dbb6be3f417995df6994f
> 
> Good luck!

atm i did not get it to work. i habe all the same packages or newer
installed. hoping newer verions did not brick it again this means it
would have to be the kernel. fedora 39 stabe only gets access to 6.6.13.
tests for 6.7 are beeing done.

i even tired to switch to pulse and back. no changes.

will provide mor info when new kernel is here. maybe someone can provide
info on weather fedora and arch kernel are vastly different as yours
specificly says arch in the version. mine does not

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1958019

Title:
  [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No
  sound at all

Status in sound-2.6 (alsa-kernel):
  Confirmed
Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by
  internal speakers, but it work by headphones connected to standard
  jack aux.

  uname -r
  5.11.0-44-generic

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-44-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jan 15 15:10:53 2022
  InstallationDate: Installed on 2021-10-11 (96 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
  Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio 
Generic
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  Symptom_Jack: Speaker, Internal
  Symptom_Type: No sound at all
  Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.49
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GKCN49WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R32862 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Legion 7 16ACHg6
  dmi.ec.firmware.release: 1.49
  dmi.modalias: 
dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:

[Touch-packages] [Bug 1958019]

[lukas]

(In reply to Jacob Garby from comment #813)
> I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere,
> the speaker started working. I have no idea how -- I did not change anything
> manually. I suspect it's a new kernel version that did it.
> 
> I'm on Arch Linux, and I can't remember which kernel version I have
> installed (but I can update when I get home later today).
> 
> Anyway, good news!

Amazing

I would like to reproduce this. You can find out your current kernel version 
with the command "uname -r". The installed sound packages/libs would also be 
interesting. What I know of would be to look at the alsa version. 
Someone else surely has more information on what to specificly look for and how.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1958019

Title:
  [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No
  sound at all

Status in sound-2.6 (alsa-kernel):
  Confirmed
Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by
  internal speakers, but it work by headphones connected to standard
  jack aux.

  uname -r
  5.11.0-44-generic

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-44-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jan 15 15:10:53 2022
  InstallationDate: Installed on 2021-10-11 (96 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
  Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio 
Generic
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  Symptom_Jack: Speaker, Internal
  Symptom_Type: No sound at all
  Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.49
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GKCN49WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R32862 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Legion 7 16ACHg6
  dmi.ec.firmware.release: 1.49
  dmi.modalias: 
dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
  dmi.product.family: Legion 7 16ACHg6
  dmi.product.name: 82N6
  dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6
  dmi.product.version: Legion 7 16ACHg6
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/sound-2.6/+bug/1958019/+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

[Touch-packages] [Bug 1768088] Re: can't activate 2 independent reachable interface

[Lukas Märdian]

Please reopen if this is still an issue

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1768088

Title:
  can't activate 2 independent reachable interface

Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  ubuntu: 18.04
  systemd:   
  Installed: 237-3ubuntu10
  Candidate: 237-3ubuntu10
  netplan.io:
Installed: 0.36.1
Candidate: 0.36.1

  network:
    version: 2
    renderer: networkd
    ethernets:
  ens3:
    addresses: [192.168.3.30/25]
    dhcp4: no
    routes:
     - to: 0.0.0.0/0
   via: 192.168.3.1
   metric: 100
   table: 101

    routing-policy:
     - from: 192.168.3.0/25
   table: 101

  ens7:
    addresses: [192.168.5.24/25]
    dhcp4: no
    gateway4: 192.168.5.1
    nameservers:
  addresses: [1.1.1.1]

  this doesn't activate a proper rule for table 101:
  0:  from all lookup local
  32766:  from all lookup main
  32767:  from all lookup default

  in place of
  0:  from all lookup local
  32765:  from 192.168.3.0/25 lookup 101
  32766:  from all lookup main
  32767:  from all lookup default

  the file in /etc/systemd/network contains the correct information:
  [Match]
  Name=ens3

  [Network]
  Address=192.168.3.30/25

  [Route]
  Destination=0.0.0.0/0
  Gateway=192.168.3.1
  Metric=100
  Table=101

  [RoutingPolicyRule]
  From=192.168.3.0/25
  Table=101

  the ens3 is reachable from 3.0 but not from anywhere else

  with ifupdown on another system both interfaces would be reachable from 
everywhere on the private subnets.
  up ip route add default table 101 dev enp8s0 via 192.168.3.1
  up ip rule add from 192.168.3.0/25 lookup 101
  down ip rule del from 192.168.3.0/25
  down ip route del default table 101 via 192.168.3.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1768088/+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

[Touch-packages] [Bug 1958019]

[lukas]

Hey, I have a Lenovo Yoga 7 16IAP7 with Fedora Workstation 39 installed.

Kernel Verion: Linux 6.6.11-200.fc39.x86_64
alsa-lib version: alsa-lib-1.2.10-3.fc39.x86_64

I installed alsa-tools and went into hdajackretask to see what is going
on. Then I noticed that my System is telling me that I have an ALC287
installed but actually it is a ALC3306. Sound is horrible and several
fixes with ALC 287 for Legion Models did nit work. In the Settings I can
see as well, that only 2 of the 4 integrated speakers are getting
noticed.

I have had this Problem for a while now.

Comment #806 said that this should have worked till 6.6 and then it
broke again. I had a fresh install of Fedora 38 back then with the
Kernel 6.4.6-200.fc38.x86_64. It did not work form me with this Kernel
either.

Are there any news or is there hope of fixes?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1958019

Title:
  [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No
  sound at all

Status in sound-2.6 (alsa-kernel):
  Confirmed
Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by
  internal speakers, but it work by headphones connected to standard
  jack aux.

  uname -r
  5.11.0-44-generic

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-44-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jan 15 15:10:53 2022
  InstallationDate: Installed on 2021-10-11 (96 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
  Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio 
Generic
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  Symptom_Jack: Speaker, Internal
  Symptom_Type: No sound at all
  Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.49
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GKCN49WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R32862 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Legion 7 16ACHg6
  dmi.ec.firmware.release: 1.49
  dmi.modalias: 
dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
  dmi.product.family: Legion 7 16ACHg6
  dmi.product.name: 82N6
  dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6
  dmi.product.version: Legion 7 16ACHg6
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/sound-2.6/+bug/1958019/+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

[Touch-packages] [Bug 2037667] Re: Regression on Jammy's kernel 5.15 when creating ip6gre and vti6 tunnels

[Lukas Märdian]

Actually, we can further reduce the patch to the removal of
`.generate_mac = true`. This already fixes the issue we observe here.

** Patch added: "lp2037667.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037667/+attachment/5741632/+files/lp2037667.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2037667

Title:
  Regression on Jammy's kernel 5.15 when creating ip6gre and vti6
  tunnels

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Jammy:
  Triaged
Status in systemd source package in Jammy:
  New

Bug description:
  We noticed that some of Netplan's integration tests started to fail on
  Jammy. These tests will try to create ip6gre and vti6 virtual
  interfaces and systemd-networkd is failing to create them starting on
  kernel 5.15.0-83.92. As far as I can tell, kernel 5.15.0-82.91 is the
  last revision where it works. So, some change between 5.15.0-82.91 and
  5.15.0-83.92 is causing this regression.

  How to reproduce the issue:

  # Launch a jammy cloud VM:

  lxc launch images:ubuntu/jammy/cloud jammy --vm
  lxc shell jammy

  # Create a netplan file that creates 2 tunnels:
   
  cat > /etc/netplan/10-tun.yaml 2' && reboot

  # Check with "ip link" again that both tun0 and tun1 were created

  # Reboot again to go back to the most recent kernel and check with "ip link" 
that both tun0 and tun1 were not created.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Sep 29 12:52 seq
   crw-rw 1 root audio 116, 33 Sep 29 12:52 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser'
  CRDA: N/A
  CasperMD5CheckResult: unknown
  CloudArchitecture: x86_64
  CloudID: lxd
  CloudName: lxd
  CloudPlatform: lxd
  CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock)
  DistroRelease: Ubuntu 22.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lspci: Error: [Errno 2] No such file or directory: 'lspci'
  Lspci-vt: Error: [Errno 2] No such file or directory: 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-t: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-v: Error: [Errno 2] No such file or directory: 'lsusb'
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 virtio_gpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-84-generic root=/dev/sda2 
ro quiet splash console=tty1 console=ttyS0 vt.handoff=7
  ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116
  RelatedPackageVersions:
   linux-restricted-modules-5.15.0-84-generic N/A
   linux-backports-modules-5.15.0-84-generic  N/A
   linux-firmware N/A
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  Tags:  jammy uec-images
  Uname: Linux 5.15.0-84-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: True
  dmi.bios.date: 2/2/2022
  dmi.bios.release: 0.0
  dmi.bios.vendor: EDK II
  dmi.bios.version: unknown
  dmi.board.name: LXD
  dmi.board.vendor: Canonical Ltd.
  dmi.board.version: pc-q35-8.0
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-q35-8.0
  dmi.modalias: 
dmi:bvnEDKII:bvrunknown:bd2/2/2022:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-8.0:rvnCanonicalLtd.:rnLXD:rvrpc-q35-8.0:cvnQEMU:ct1:cvrpc-q35-8.0:sku:
  dmi.product.name: Standard PC (Q35 + ICH9, 2009)
  dmi.product.version: pc-q35-8.0
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037667/+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

[Touch-packages] [Bug 2037667] Re: Regression on Jammy's kernel 5.15 when creating ip6gre and vti6 tunnels

[Lukas Märdian]

This seems to do the trick using the following Netplan config as a
testcase.

All 3 interfaces (tun[0-2]) are correctly created with their local &
remote properties set:

root@jj-abi:~/systemd# ip link show dev tun0
19: tun0@NONE:  mtu 1448 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/gre6 fe80::1 brd 2001:dead:beef::2 permaddr e262:75ae:2aa0::
root@jj-abi:~/systemd# ip link show dev tun1
20: tun1@NONE:  mtu 1332 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/tunnel6 fe80::2 brd 2001:dead:beef::3 permaddr c2aa:7446:cc29::
root@jj-abi:~/systemd# ip link show dev tun2
21: tun2@NONE:  mtu 1444 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/gre6 fe80::3 brd 2001:dead:beef::4 permaddr 3ef2:274c:a921::


Netplan test config:
```
network:
  version: 2
  tunnels:
tun0:
  mode: ip6gre
  local: fe80::1
  remote: 2001:dead:beef::2
tun1:
  mode: vti6
  local: fe80::2
  remote: 2001:dead:beef::3
tun2:
  mode: ip6gre
  key: 1234
  local: fe80::3
  remote: 2001:dead:beef::4
```

** Patch added: "network-netdev-introduce-.iftype-to-netdev-vtable.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037667/+attachment/5741625/+files/network-netdev-introduce-.iftype-to-netdev-vtable.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2037667

Title:
  Regression on Jammy's kernel 5.15 when creating ip6gre and vti6
  tunnels

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Jammy:
  Triaged
Status in systemd source package in Jammy:
  New

Bug description:
  We noticed that some of Netplan's integration tests started to fail on
  Jammy. These tests will try to create ip6gre and vti6 virtual
  interfaces and systemd-networkd is failing to create them starting on
  kernel 5.15.0-83.92. As far as I can tell, kernel 5.15.0-82.91 is the
  last revision where it works. So, some change between 5.15.0-82.91 and
  5.15.0-83.92 is causing this regression.

  How to reproduce the issue:

  # Launch a jammy cloud VM:

  lxc launch images:ubuntu/jammy/cloud jammy --vm
  lxc shell jammy

  # Create a netplan file that creates 2 tunnels:
   
  cat > /etc/netplan/10-tun.yaml 2' && reboot

  # Check with "ip link" again that both tun0 and tun1 were created

  # Reboot again to go back to the most recent kernel and check with "ip link" 
that both tun0 and tun1 were not created.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Sep 29 12:52 seq
   crw-rw 1 root audio 116, 33 Sep 29 12:52 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser'
  CRDA: N/A
  CasperMD5CheckResult: unknown
  CloudArchitecture: x86_64
  CloudID: lxd
  CloudName: lxd
  CloudPlatform: lxd
  CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock)
  DistroRelease: Ubuntu 22.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lspci: Error: [Errno 2] No such file or directory: 'lspci'
  Lspci-vt: Error: [Errno 2] No such file or directory: 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-t: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-v: Error: [Errno 2] No such file or directory: 'lsusb'
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 virtio_gpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-84-generic root=/dev/sda2 
ro quiet splash console=tty1 console=ttyS0 vt.handoff=7
  ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116
  RelatedPackageVersions:
   linux-restricted-modules-5.15.0-84-generic N/A
   linux-backports-modules-5.15.0-84-generic  N/A
   linux-firmware N/A
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  Tags:  jammy uec-images
  Uname: Linux 5.15.0-84-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: True
  dmi.bios.date: 2/2/2022
  dmi.bios.release: 0.0
  dmi.bios.vendor: EDK II
  dmi.bios.version: unknown
  dmi.board.name: LXD
  dmi.board.vendor: Canonical Ltd.
  dmi.board.version: pc-q35-8.0
  dmi.chassis.typ

[Touch-packages] [Bug 2037667] Re: Regression on Jammy's kernel 5.15 when creating ip6gre and vti6 tunnels

[Lukas Märdian]

So after bisecting systemd (v249..v251) on Jammy, this seems to be the
commit that changed behavior for the better:

https://github.com/systemd/systemd/commit/9f0cf80dd007491698978dbfe38158d74c1c9526

It probably needs some backporting for v249.11.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2037667

Title:
  Regression on Jammy's kernel 5.15 when creating ip6gre and vti6
  tunnels

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Jammy:
  Triaged
Status in systemd source package in Jammy:
  New

Bug description:
  We noticed that some of Netplan's integration tests started to fail on
  Jammy. These tests will try to create ip6gre and vti6 virtual
  interfaces and systemd-networkd is failing to create them starting on
  kernel 5.15.0-83.92. As far as I can tell, kernel 5.15.0-82.91 is the
  last revision where it works. So, some change between 5.15.0-82.91 and
  5.15.0-83.92 is causing this regression.

  How to reproduce the issue:

  # Launch a jammy cloud VM:

  lxc launch images:ubuntu/jammy/cloud jammy --vm
  lxc shell jammy

  # Create a netplan file that creates 2 tunnels:
   
  cat > /etc/netplan/10-tun.yaml 2' && reboot

  # Check with "ip link" again that both tun0 and tun1 were created

  # Reboot again to go back to the most recent kernel and check with "ip link" 
that both tun0 and tun1 were not created.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Sep 29 12:52 seq
   crw-rw 1 root audio 116, 33 Sep 29 12:52 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser'
  CRDA: N/A
  CasperMD5CheckResult: unknown
  CloudArchitecture: x86_64
  CloudID: lxd
  CloudName: lxd
  CloudPlatform: lxd
  CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock)
  DistroRelease: Ubuntu 22.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lspci: Error: [Errno 2] No such file or directory: 'lspci'
  Lspci-vt: Error: [Errno 2] No such file or directory: 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-t: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-v: Error: [Errno 2] No such file or directory: 'lsusb'
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 virtio_gpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-84-generic root=/dev/sda2 
ro quiet splash console=tty1 console=ttyS0 vt.handoff=7
  ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116
  RelatedPackageVersions:
   linux-restricted-modules-5.15.0-84-generic N/A
   linux-backports-modules-5.15.0-84-generic  N/A
   linux-firmware N/A
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  Tags:  jammy uec-images
  Uname: Linux 5.15.0-84-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: True
  dmi.bios.date: 2/2/2022
  dmi.bios.release: 0.0
  dmi.bios.vendor: EDK II
  dmi.bios.version: unknown
  dmi.board.name: LXD
  dmi.board.vendor: Canonical Ltd.
  dmi.board.version: pc-q35-8.0
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-q35-8.0
  dmi.modalias: 
dmi:bvnEDKII:bvrunknown:bd2/2/2022:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-8.0:rvnCanonicalLtd.:rnLXD:rvrpc-q35-8.0:cvnQEMU:ct1:cvrpc-q35-8.0:sku:
  dmi.product.name: Standard PC (Q35 + ICH9, 2009)
  dmi.product.version: pc-q35-8.0
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037667/+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

[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

[Lukas Märdian]

** Changed in: systemd (Ubuntu Bionic)
 Assignee: Lukas Märdian (slyon) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1949089

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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

[Touch-packages] [Bug 2037667] Re: Regression on Jammy's kernel 5.15 when creating ip6gre and vti6 tunnels

[Lukas Märdian]

We talked to our systemd maintainer inside foundations and also reached
out to upstream system [1], which didn't lead anywhere. We shouldn't
need to bisect systemd-networkd and do a high impact systemd SRU to fix
a regression in a kernel update, where we can pinpoint the exact (small)
git commit.

We'd like to ask to have the kernel commit b0ad3c179059 reverted in the
Jammy kernels, to mitigate this regression.


[1] 
https://lists.freedesktop.org/archives/systemd-devel/2023-November/049693.html

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2037667

Title:
  Regression on Jammy's kernel 5.15 when creating ip6gre and vti6
  tunnels

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Jammy:
  Triaged
Status in systemd source package in Jammy:
  New

Bug description:
  We noticed that some of Netplan's integration tests started to fail on
  Jammy. These tests will try to create ip6gre and vti6 virtual
  interfaces and systemd-networkd is failing to create them starting on
  kernel 5.15.0-83.92. As far as I can tell, kernel 5.15.0-82.91 is the
  last revision where it works. So, some change between 5.15.0-82.91 and
  5.15.0-83.92 is causing this regression.

  How to reproduce the issue:

  # Launch a jammy cloud VM:

  lxc launch images:ubuntu/jammy/cloud jammy --vm
  lxc shell jammy

  # Create a netplan file that creates 2 tunnels:
   
  cat > /etc/netplan/10-tun.yaml 2' && reboot

  # Check with "ip link" again that both tun0 and tun1 were created

  # Reboot again to go back to the most recent kernel and check with "ip link" 
that both tun0 and tun1 were not created.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Sep 29 12:52 seq
   crw-rw 1 root audio 116, 33 Sep 29 12:52 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser'
  CRDA: N/A
  CasperMD5CheckResult: unknown
  CloudArchitecture: x86_64
  CloudID: lxd
  CloudName: lxd
  CloudPlatform: lxd
  CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock)
  DistroRelease: Ubuntu 22.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lspci: Error: [Errno 2] No such file or directory: 'lspci'
  Lspci-vt: Error: [Errno 2] No such file or directory: 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-t: Error: [Errno 2] No such file or directory: 'lsusb'
  Lsusb-v: Error: [Errno 2] No such file or directory: 'lsusb'
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 virtio_gpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-84-generic root=/dev/sda2 
ro quiet splash console=tty1 console=ttyS0 vt.handoff=7
  ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116
  RelatedPackageVersions:
   linux-restricted-modules-5.15.0-84-generic N/A
   linux-backports-modules-5.15.0-84-generic  N/A
   linux-firmware N/A
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  Tags:  jammy uec-images
  Uname: Linux 5.15.0-84-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: True
  dmi.bios.date: 2/2/2022
  dmi.bios.release: 0.0
  dmi.bios.vendor: EDK II
  dmi.bios.version: unknown
  dmi.board.name: LXD
  dmi.board.vendor: Canonical Ltd.
  dmi.board.version: pc-q35-8.0
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-q35-8.0
  dmi.modalias: 
dmi:bvnEDKII:bvrunknown:bd2/2/2022:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-8.0:rvnCanonicalLtd.:rnLXD:rvrpc-q35-8.0:cvnQEMU:ct1:cvrpc-q35-8.0:sku:
  dmi.product.name: Standard PC (Q35 + ICH9, 2009)
  dmi.product.version: pc-q35-8.0
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037667/+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

[Touch-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

[Lukas Märdian]

IMO the wpasupplicant trigger is a red herring, as we see the same
failure on a trigger=system/255... test case:

https://autopkgtest.ubuntu.com/results/autopkgtest-
noble/noble/s390x/n/netplan.io/20240104_111341_511f7@/log.gz

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/2048388

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2048388/+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

[Touch-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

[Lukas Märdian]

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/2048388

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2048388/+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

[Touch-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

[Lukas Märdian]

Another option/idea I'd like to provide here is the migration script
used by NetworkManager [1], to transfer NM keyfiles from
/etc/NetworkManager/system-conncetions/ into /etc/netplan. This script
is automatically run on package upgrade of NetworkManager. I understand
this does not exactly fit the usecase described by alkisg, as you'd go
from debian-box:/etc/NetworkManager/system-connections -> ubuntu-
box:/etc/NetworkManager/system-connections -> migrate.sh -> ubuntu-
box:/run/NetworkManager/system-connections

Running "./migrate.sh configure" would transfer your copied original NM
keyfiles from a different box into Netplan and re-generate them in
/run/NetworkManager/system-connections:

```bash
# Run "Netplan Everywhere" migration after debhelper (re-)started
# NetworkManager.service for us. On every package upgrade.
DIR="/etc/NetworkManager/system-connections"
if [ "$1" = "configure" ] && [ -d "$DIR" ]; then
mkdir -p /run/netplan/nm-migrate
for CON in /etc/NetworkManager/system-connections/*; do
TYPE=$(file -bi "$CON" | cut -s -d ";" -f 1)
[ "$TYPE" = "text/plain" ] || continue # skip non-keyfiles
UUID=$(grep "^uuid=" "$CON" | cut -c 6-)
if [ -n "$UUID" ]
then
# Wait for NetworkManager startup to complete,
# so we can safely use nmcli. Wait in every interation to handle
# a crashed NetworkManager in the previous migraiton step.
if ! nm-online -qs; then
echo "SKIP: NetworkManager is not ready ..." 1>&2
continue
fi
BACKUP="/run/netplan/nm-migrate/"$(basename "$CON")
ORIG_NAME=$(nmcli --get-values connection.id con show "$UUID") || \
{ echo "SKIP: $(basename "$CON") ($UUID) unknown to 
NetworkManager." 1>&2 && \
  continue; }
cp "$CON" "$BACKUP"
echo "Migrating $ORIG_NAME ($UUID) to /etc/netplan" 1>&2
# Touch the connection's ID (con-name) to trigger its migration.
# The Netplan integration will translate the original NM keyfile 
from
# /etc/NetworkManager/system-connections/* to a YAML file located in
# /etc/netplan/90-NM-*.yaml and re-generate a corresponding keyfile 
in
# /run/NetworkManager/system-connections/netplan-NM-*.nmconnection
nmcli con mod "$UUID" con-name "$ORIG_NAME" || \
(echo "FAILED. Restoring backup ..." 1>&2 && mv "$BACKUP" 
"$CON" && \
 rm -f "/etc/netplan/90-NM-$UUID"*.yaml)
rm -f "$BACKUP" # clear backup (if it still exists)
   fi
done
rm -rf /run/netplan/nm-migrate # cleanup after ourselves
(nm-online -qs && nmcli con reload) || echo "WARNING: NetworkManager could 
not reload connections ..." 1>&2
fi
```

[1] https://git.launchpad.net/network-manager/tree/debian/network-
manager.postinst#n62

-- 
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/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://

[Touch-packages] [Bug 2045033] Re: Merge rsyslog 8.2312.0-2 from Debian

[Lukas Märdian]

https://launchpad.net/ubuntu/+source/rsyslog/8.2312.0-2ubuntu1

** Changed in: rsyslog (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/2045033

Title:
  Merge rsyslog 8.2312.0-2 from Debian

Status in rsyslog package in Ubuntu:
  In Progress

Bug description:
  Debian has released rsyslog 8.2310.0-4. Merge it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2045033/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

Reducing to "Medium", as I don't think we can hit this situation through
the Netplan-everywhere integration, but manual steps (wrong YAML config)
must be involved in reaching this state.

We're working on a fix here:
https://github.com/canonical/netplan/pull/427

** Changed in: netplan
   Importance: High => Medium

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

@vanillaoerba How did you end up in that situation? Did you modify
/etc/netplan/90-NM-X.yaml manually?

Those special values for the MAC address should have been handled by the
networkmanager.passthrough.cloned-mac-address=random setting for you..

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

[Lukas Märdian]

** Changed in: netplan.io (Ubuntu)
   Status: Confirmed => Fix Committed

-- 
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/2046158

Title:
  Updating wireguard-peer.allowed-ips gets wrong default netmask for
  IPv6 addresses

Status in netplan.io package in Ubuntu:
  Fix Committed
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  In https://cockpit-project.org/ we have an integration test for
  NM+wireguard integration. That test starts with an IPv4-only
  connection:

  # cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
  network:
    version: 2
    tunnels:
  wg0:
    renderer: NetworkManager
    addresses:
    - "10.0.0.2/24"
    mode: "wireguard"
    port: 51820
    keys:
  private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
    peers:
    - keys:
    public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
  allowed-ips:
  - "10.0.0.1/32"
    networkmanager:
  uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
  name: "con-wg0"
  passthrough:
    ipv6.addr-gen-mode: "default"
    ipv6.method: "disabled"
    ipv6.ip6-privacy: "-1"
    proxy._: ""

  which gets rendered as

  # cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
  [connection]
  id=con-wg0
  type=wireguard
  uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
  interface-name=wg0

  [wireguard]
  private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
  listen-port=51820

  [wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
  allowed-ips=10.0.0.1/32;

  [ipv4]
  method=manual
  address1=10.0.0.2/24

  [ipv6]
  #Netplan: passthrough override
  method=disabled
  #Netplan: passthrough setting
  addr-gen-mode=default

  [proxy]

  Now the UI modifies the "allowed-ips" setting to ["10.0.0.1",
  "2001::1"]. Notably the addresses do *not* have a netmask, neither in
  the original config nor that update. Unfortunately that update cannot
  be done on the CLI:

  # nmcli con modify con-wg0 
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips" 
"2001::1"
  Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not 
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].

  So it has to happen via D-Bus:

  
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
  wg0","t":"s"},"interface-
  
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
  slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
  port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
  key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
  ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
  
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
  
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
  
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
  data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
  data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
  auto-dns":{"v":false,"t":"b"},"ignore-auto-
  routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]

  But this generates a wrong "/32" default netmask in the netplan config
  for the IPv6 address:

  allowed-ips:
  - "10.0.0.1/32"
  - "2001::1/32"

  On Fedora, with NM's default .nmconnection files, such a netmask is
  not added on this call. The netplan backend should do that (not
  second-guessing NM) or at least default to /128 for an IPv6 address.

  Doing this D-Bus call with `busctl` is a nuisance. If you need a
  reproducer at this level, I can spend an hour or so trying to stitch
  it together, but I hope your unit tests make this easier somehow.

  This was fine until 22.10, but with NM's new "netplan by default"
  backend this regressed.

  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2046158/+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

[Touch-packages] [Bug 2045756] Re: systemd-networkd-wait-online.service fails to complete if one of the network interfaces is not physically connected

[Lukas Märdian]

The RequiredForOnline=no flag can be controlled using Netplan's "optional: 
true" setting.
In your specific case (cable not connected) you might also be interested in 
Netplan's "ignore-carrier: true" setting, which brings up the interface 
regardless.

Please check /etc/netplan/ for those settings (or "sudo netplan get").
Those initial settings might have been written by cloud-init or
subiquity or some other means of deployment.

** Changed in: netplan.io (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2045756

Title:
  systemd-networkd-wait-online.service fails to complete if one of the
  network interfaces is not physically connected

Status in netplan.io package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  My StarFive VisionFive 2 board has two network interfaces of which I
  have only connected one to a switch. The systemd-networkd-wait-
  online.service always fails delaying boot by 150 s. The problem does
  not occur if both network interfaces are physically connected.

  It does not make any sense to wait for the initialization of a network
  interface that is not physically connected.

  As described in
  https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  the physical link state can be determined via
  /sys/class/net//carrier.

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: systemd 253.5-1ubuntu7
  ProcVersionSignature: Ubuntu 6.5.0-9.9.1-generic 6.5.3
  Uname: Linux 6.5.0-9-generic riscv64
  ApportVersion: 2.27.0-0ubuntu6
  Architecture: riscv64
  CasperMD5json:
   {
 "result": "skip"
   }
  Date: Wed Dec  6 10:57:52 2023
  InstallationDate: Installed on 2023-12-04 (2 days ago)
  InstallationMedia: Ubuntu-Server 24.04 "Noble Numbat" - Daily riscv64 
(20231204)
  Lspci-vt:
   -[:00]---00.0-[01]00.0  VIA Technologies, Inc. VL805/806 xHCI USB 
3.0 Controller
   -[0001:00]---00.0-[01]00.0  KIOXIA Corporation NVMe SSD Controller BG4 
(DRAM-less)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=vt220
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-9-generic 
root=UUID=2ee109fa-e475-473e-a8da-79f18ec0c1a3 ro
  SourcePackage: systemd
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  acpidump:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2045756/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

** Also affects: netplan.io (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: fr-6121

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

[Lukas Märdian]

** Tags added: netplan-everywhere

** Changed in: netplan
   Status: New => Triaged

** Changed in: netplan
   Importance: Undecided => High

** Tags added: foundations-todo

-- 
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/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2045096/+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

[Touch-packages] [Bug 2026230] Re: libnetplan integration breaks "cloned-mac-address" special values

[Lukas Märdian]

Fixed in v0.107 https://github.com/canonical/netplan/releases/tag/0.107

** Changed in: netplan
   Status: Fix Committed => Fix Released

-- 
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/2026230

Title:
  libnetplan integration breaks "cloned-mac-address" special values

Status in netplan:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I received an error from apport about a programme not working. I
  collected the data to submit. Hope this helps.

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.42.6-2ubuntu1
  Uname: Linux 6.2.0-24-generic x86_64
  Architecture: amd64
  Date: Wed Jul  5 23:11:14 2023
  ExecutablePath: /usr/sbin/NetworkManager
  ExecutableTimestamp: 1687429583
  ProcCmdline: /usr/sbin/NetworkManager --no-daemon
  ProcCwd: /
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
  Signal: 6
  SourcePackage: network-manager
  UserGroups: N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2026230/+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

[Touch-packages] [Bug 2039083] Re: "optional: true" flag introduces problem it's meant to fix in certain circumstances

[Lukas Märdian]

So if I understand correctly, this does not affect Focal or Bionic.
It also does not affect Mantic or Noble.

We're just hitting this issue on Jammy = systemd v249.11 (and probably
Lunar = systemd v252.5).

Netplan's behavior seems to be correct, here. It writes sensible
configuration for systemd-networkd. The issue is in (upstream) systemd,
which blocks on an empty list, which it shouldn't. That behavior is
apparently fixed in systemd v253.

I think we should not try to work around this systemd behaviour in
Netplan, but either live with the upstream behavior for v249 or backport
the fixes from systemd v253 into Jammy.

** Tags added: rls-jj-incoming

** Changed in: netplan
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2039083

Title:
  "optional: true" flag introduces problem it's meant to fix in certain
  circumstances

Status in netplan:
  Invalid
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Hello!

  This bug is in relation to the situation where the "systemd-networkd-
  wait-online.service" hangs for several minutes on boot before
  eventually failing. I guess I don't know if this flag was introduced
  specifically for this situation, but I do know that one of the fixes
  for this issue is to add "optional: true" to any non-critical
  interfaces (as per the docs[1]). While this may be the case, it just
  so happens that adding this flag to an interface when it's the only
  configured interface in netplan can actually INTRODUCE the issue as
  well. Example:

  ---
  :~# grep -Ev "^#" /etc/netplan/50-cloud-init.yaml
  network:
  version: 2
  ethernets:
  enp5s0:
  dhcp4: true
  optional: true
  ---

  The above config will cause the service hang/failure, and the removal
  of the flag will resolve the issue. I primarily opened this bug report
  with the idea that we might update aforementioned documentation to
  include a caveat that you want to avoid adding this flag to the only
  configured interface. However, it was also discussed that we might
  consider having the netplan config parser complain about such a setup
  and consider it invalid, which it kinda is. I believe in a situation
  where you may have a server that should have NO network connectivity,
  you would simply leave netplan unconfigured and/or stop any relevant
  services, rather than try to configure all interfaces as optional.

  My original test was on Jammy, though I tested this also on Focal and
  Bionic, and neither of those appear to be affected by this - setting
  the only interface as optional in either of those does not cause the
  "systemd-networkd-wait-online" service to hang and the system boots
  normally.

  Let me know if you'd like/need any more info from me! Thank you!

  [1] https://netplan.io/faq#prevent-waiting-for-interface

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2039083/+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

[Touch-packages] [Bug 2024661] Re: Unable to configure Wireguard connection at NetworkManager interface

[Lukas Märdian]

This should have been fixed upstream as of
https://github.com/canonical/netplan/pull/371 and should be fixed in
Mantic.

Can you still re-produce this issue today?

** Changed in: netplan.io (Ubuntu)
   Status: In Progress => Fix Released

-- 
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/2024661

Title:
  Unable to configure Wireguard connection at NetworkManager interface

Status in netplan.io package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  Repro steps:

  1) Open NetworkManager GUI.
  2) Click "Add new Connection" and select "Wireguard" connection type.
  3) Then you have to configure new connection. Basic configuration looks like 
that:
  a) Write down connection name,
  b) Write down local private key,
  c) Create new peer and populate peer's parameters: public key of the 
peer, allowed IPs (i.e. 0.0.0.0/0), peer's IP address and port.
  4) Click "OK" and "Save".
  5) Open "Peers" again. Ensure that settings were not stored. All fields are 
empty.

  Found in Kubuntu flavor version 23.10 (development), Plasma Network Manager 
interface.
  netplan.io 0.106.1-2
  network-manager 1.42.4-1ubuntu7

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2024661/+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

[Touch-packages] [Bug 1920933] Re: live desktop system booted with ip=dhcp has the right lease, hostname not set at all

[Lukas Märdian]

Netplan is not involved with setting the hostname at all. Marking
invalid for that package.

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1920933

Title:
  live desktop system booted with ip=dhcp has the right lease, hostname
  not set at all

Status in initramfs-tools package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  Here the cmdline:

  vmlinuz initrd=initrd rootfstype=nfs netboot=nfs
  nfsroot=162.38.151.26:/exports/focal-desktop boot=casper ip=dhcp
  fsck.mode=skip automatic-ubiquity
  url=http://162.38.151.26/preseed/fds/focal-efi.seed

  File /run/systemd/netif/leases/2:

  # This is private data. Do not parse.
  ADDRESS=162.38.80.32
  NETMASK=255.255.248.0
  ROUTER=162.38.80.1
  SERVER_ADDRESS=162.38.87.254
  NEXT_SERVER=162.38.151.26
  T1=7200
  T2=12600
  LIFETIME=14400
  DNS=162.38.151.23 162.38.151.24
  NTP=193.51.157.3
  DOMAINNAME=fdsetu.infra.domain.fr
  DOMAIN_SEARCH_LIST=infra.domain.fr fdsetu.infra.domain.fr
  HOSTNAME=focal-uefi
  CLIENTID=0152540071e1f2

  But the hostname is still the default one "ubuntu"

  $ hostnamectl
   Static hostname: ubuntu
 Icon name: computer-vm
   Chassis: vm
Machine ID: cbb8d889829d4e2594ab55a53749e7e9
   Boot ID: c93c8cc26fa040f6b010077e676bf7ec
Virtualization: kvm
  Operating System: Ubuntu 20.04.2 LTS
Kernel: Linux 5.8.0-43-generic
  Architecture: x86-64

  It should be "focal-uefi".
  I had the same issue with ubuntu server autoinstall

  See https://bugs.launchpad.net/subiquity/+bug/1905932

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.4
  ProcVersionSignature: Ubuntu 5.8.0-43.49~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-43-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperVersion: 1.445.1
  Date: Tue Mar 23 15:30:42 2021
  LiveMediaBuild: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  Lsusb:
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Lsusb-t:
   /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
   |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 
480M
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  ProcEnviron:
   TERM=linux
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: vmlinuz initrd=initrd rootfstype=nfs netboot=nfs 
nfsroot=162.38.151.26:/exports/focal-desktop boot=casper ip=dhcp fsck.mode=skip 
automatic-ubiquity url=http://162.38.151.26/preseed/fds/focal-efi.seed
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/06/2015
  dmi.bios.release: 0.0
  dmi.bios.vendor: EFI Development Kit II / OVMF
  dmi.bios.version: 0.0.0
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-q35-3.1
  dmi.modalias: 
dmi:bvnEFIDevelopmentKitII/OVMF:bvr0.0.0:bd02/06/2015:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-3.1:cvnQEMU:ct1:cvrpc-q35-3.1:
  dmi.product.name: Standard PC (Q35 + ICH9, 2009)
  dmi.product.version: pc-q35-3.1
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1920933/+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

[Touch-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

[Lukas Märdian]

** Changed in: netplan.io (Ubuntu)
   Status: Triaged => Invalid

-- 
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:
  Invalid
Status in network-manager package in Ubuntu:
  Fix Released
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 notificati

[Touch-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

[Lukas Märdian]

** Tags removed: rls-nn-incoming

-- 
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/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+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

[Touch-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

[Lukas Märdian]

Thank you for your thoughtful report!

This change was not just made to be useful in cloud environments, but
also is about unification of network configuration across the different
variants of Ubuntu (Desktop/Server/Core/Cloud/..), to improve the UX for
Ubuntu users. I understand this impacts the cross-distro compatibility
of our NetworkManager packaging.

If you want to manage your NM connection profiles manually, you could
place the keyfiles in /usr/lib/NetworkManager/system-connections/ and NM
will pick them up as before. But those connections would no be visible
to Netplan and any modifications through the NetworKManager tooling
(GUI, nmtui, nmcli, ...) would write the modifications to /etc/netplan/
instead of /etc/NetworkManager/system-connections/

-- 
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/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+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

[Touch-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

[Lukas Märdian]

** Also affects: netplan.io (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: netplan-everywhere

** Tags added: rls-nn-incoming

-- 
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/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+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

[Touch-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

[Lukas Märdian]

** Tags removed: foundations-todo

-- 
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 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://bu

[Touch-packages] [Bug 2023183] Re: network-manager autokpgtest failure (nm.py)

[Lukas Märdian]

** Changed in: network-manager (Ubuntu Noble)
   Status: Confirmed => In Progress

** Changed in: network-manager (Ubuntu Noble)
 Assignee: (unassigned) => Lukas Märdian (slyon)

-- 
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/2023183

Title:
  network-manager autokpgtest failure (nm.py)

Status in network-manager package in Ubuntu:
  In Progress
Status in network-manager source package in Lunar:
  Confirmed
Status in network-manager source package in Mantic:
  Confirmed
Status in network-manager source package in Noble:
  In Progress

Bug description:
  This fails only on arm64.

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  lunar/lunar/arm64/n/network-manager/20230522_141200_71ac4@/log.gz

  To be determined if there is a bug in the package or linux kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2023183/+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

[Touch-packages] [Bug 2023183] Re: network-manager autokpgtest failure (nm.py)

[Lukas Märdian]

Thank you for your investigation. This sounds very related to this
systemd/udev quirk:

https://github.com/canonical/netplan/commit/1413f0e7b8f4d068f817a009d998656de3224370

-- 
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/2023183

Title:
  network-manager autokpgtest failure (nm.py)

Status in network-manager package in Ubuntu:
  In Progress
Status in network-manager source package in Lunar:
  Confirmed
Status in network-manager source package in Mantic:
  Confirmed
Status in network-manager source package in Noble:
  In Progress

Bug description:
  This fails only on arm64.

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  lunar/lunar/arm64/n/network-manager/20230522_141200_71ac4@/log.gz

  To be determined if there is a bug in the package or linux kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2023183/+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