[Touch-packages] [Bug 1991553] Re: can't add a private PPA

[Dan Streetman]

> Instead, `add-apt-repository` should call `getArchiveSubscriptionURL`
(not `getArchiveSubscriptionURLs`)

this doesn't seem to work correctly.

For example:

In [25]: lp.me.getArchiveSubscriptionURLs()
Out[25]: 
['https://ddstreet:x...@private-ppa.launchpadcontent.net/canonical-support-eng/soscleaner-deletedppa/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/canonical-support-eng/ddstreet-deletedppa/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/jedis/test-deletedppa1/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/jedis/test-deletedppa/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/canonical-support-eng/sf155616-deletedppa/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/canonical-support-eng/sf107001-deletedppa/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/canonical-support-eng/sf99522-deletedppa/ubuntu',
 
'https://ddstreet:x...@private-ppa.launchpadcontent.net/canonical-support-eng/sf94878-deletedppa/ubuntu']

In [26]: jedis = lp.people('jedis')

In [28]: testdeletedppa = jedis.getPPAByName(name='test-deletedppa')

In [29]: lp.me.getArchiveSubscriptionURL(archive=testdeletedppa)
Out[29]: 
{'self_link': 'https://api.launchpad.net/devel/~ddstreet',
 'web_link': 'https://launchpad.net/~ddstreet',
 'resource_type_link': 'https://api.launchpad.net/devel/#person',

...and the rest of my personal object (i.e. lp.me) as a python object.

It's the same result when I try with a non-deleted ppa, which doesn't
show up in getArchiveSubscriptionURLs():

In [37]: lteam = lp.people('launch-lite')

In [38]: lppa = lteam.getPPAByName(name='ppa')

In [39]: lp.me.getArchiveSubscriptionURL(archive=lppa)
Out[39]: 
{'self_link': 'https://api.launchpad.net/devel/~ddstreet',
 'web_link': 'https://launchpad.net/~ddstreet',
 'resource_type_link': 'https://api.launchpad.net/devel/#person',
...

Until that bug is fixed (and that bug isn't in software-properties), I
don't think add-apt-repository can be changed to use
getArchiveSubscriptionURL(). Or at least, if this bug only applies to
me, then I can't make the change in software-properties since I wouldn't
be able to test the change...

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

Title:
  can't add a private PPA

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  As per today's discussion in ~is :

  add-apt-repository has a bug when adding a private PPA. Quoting
  ~cjwatson :

  ===
  It asks Launchpad for all your personal archive subscriptions _that have 
tokens_.  But `Person:+archivesubscriptions` also shows subscriptions without 
tokens - the token is generated when you click on Viewt here for the first time.

  Instead, `add-apt-repository` should call `getArchiveSubscriptionURL` (not 
`getArchiveSubscriptionURLs`) for the archive it's interested in.  That 
generates tokens on-demand.  Either it will get an HTTP 401, or it will get a 
URL which it can parse for the username and password.
  ===

  Thanks !

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1991553/+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 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations

[Dan Streetman]

btw, I no longer work for Canonical, and this bug doesn't personally
affect me, so it's unlikely I will follow up on this; if anyone does
care about this bug, please feel free to take this over

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

Title:
  systemd-logind network access is blocked, and breaks remote
  authentication configurations

Status in systemd:
  Fix Released
Status in nis package in Ubuntu:
  Confirmed
Status in openldap package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in nis package in Debian:
  Fix Released

Bug description:
  [impact]

  starting in focal, systemd-logind runs sandboxed without any network
  access, which breaks any configuration that uses remote servers for
  user data, e.g. ldap, nis, etc

  A more full discussion is available in the upstream bug report as well
  as the debian bug report, see other info section below

  [test case]

  many possible ways to reproduce this; there are reproducers in some of
  the bugs reported before that are caused by this, e.g. bug 1915502 or
  bug 1916235

  [regression potential]

  failure to authenticate when using remote user data, incorrect
  authentication, security issues due to un-sandboxing of systemd-logind

  [scope]

  this is needed in f and later

  before focal, systemd-logind was not sandboxed so this did not apply

  [other info]

  this isn't actually a bug in systemd, this is a by-design security feature; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
  https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
  https://github.com/systemd/systemd/issues/15705#issuecomment-624125354

  this may also can cause systemd-udevd failures in some cases as well.
  https://github.com/systemd/systemd/pull/7343#issuecomment-344800313

  For reference, upstream discussion around the systemd-logind sandboxing 
specifically:
  https://github.com/systemd/systemd/issues/7074
  upstream updated doc PR explaining the upstream position:
  https://github.com/systemd/systemd/pull/7343

  Debian bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625
  Note that while this Debian bug is marked as fix released, I don't think it 
actually fixes the problem, from the final comment it seems like the only 
change was to add Recommends: nscd, which doesn't really solve things if 
someone doesn't use nscd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1934393/+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 1997189] Re: [BPO] elfutils/0.188-1 from Lunar

[Dan Streetman]

we briefly discussed this in the backporters mtg and it looks good to
us, however it's backported from 0.188-1 which is currently in lunar-
proposed, so that needs to migrate to lunar-release before we can accept
this backport; feel free to ping us once that's happened.

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

Title:
   [BPO] elfutils/0.188-1 from Lunar

Status in elfutils package in Ubuntu:
  Fix Released
Status in elfutils source package in Jammy:
  New

Bug description:
  [Impact]

   * elfutils ships many ELF/DWARF related tools that are interesting
  for users and developers of low level code.

   * More specifically, elfutils ships the debuginfod library and
  server. The latest upstream version (0.188) introduces many
  interesting features that should make the life of debuginfod users
  easier; one of those features is the ability to serve sections of
  DWARF, instead of the whole file.  I intend to update Ubuntu's
  debuginfod instance to use this new package in the near future.

  [Scope]

   * I will backport elfutils/0.188 from Lunar.

   * I will backport elfutils/0.188 to Jammy.

  [Other Info]

   * None so far.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/1997189/+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 1991829] [NEW] machinectl read-only does not work

[Dan Streetman]

Public bug reported:

[impact]

machinectl read-only does not work

[test case]

On a system where the systemd machines dir is *not* on a btrfs volume
(e.g. it's on a normal ext4 fs), create an image 'test' and then:

$ sudo machinectl image-status test
test
Type: directory
Path: /var/lib/machines/test
Hostname: ubuntu
  OS: Ubuntu 20.04.5 LTS
  RO: writable
 Created: Wed 2022-10-05 13:41:15 EDT; 34s ago

$ sudo machinectl read-only test
Could not mark image read-only: Access denied

[regression potential]

failure marking images ro or rw

[scope]

this is needed in all releases that include machinectl

this is fixed upstream by 137d162c42ed858613afc3d7493d08d4ae6d5c1b

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

** Affects: systemd (Ubuntu Focal)
 Importance: Low
 Status: New

** Affects: systemd (Ubuntu Jammy)
 Importance: Low
 Status: New

** Affects: systemd (Ubuntu Kinetic)
 Importance: Low
 Status: New

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

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

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

** Changed in: systemd (Ubuntu Kinetic)
   Importance: Undecided => Low

** Changed in: systemd (Ubuntu Jammy)
   Importance: Undecided => Low

** Changed in: systemd (Ubuntu Focal)
   Importance: Undecided => Low

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

Title:
  machinectl read-only does not work

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Jammy:
  New
Status in systemd source package in Kinetic:
  New

Bug description:
  [impact]

  machinectl read-only does not work

  [test case]

  On a system where the systemd machines dir is *not* on a btrfs volume
  (e.g. it's on a normal ext4 fs), create an image 'test' and then:

  $ sudo machinectl image-status test
  test
  Type: directory
  Path: /var/lib/machines/test
  Hostname: ubuntu
OS: Ubuntu 20.04.5 LTS
RO: writable
   Created: Wed 2022-10-05 13:41:15 EDT; 34s ago

  $ sudo machinectl read-only test
  Could not mark image read-only: Access denied

  [regression potential]

  failure marking images ro or rw

  [scope]

  this is needed in all releases that include machinectl

  this is fixed upstream by 137d162c42ed858613afc3d7493d08d4ae6d5c1b

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1991829/+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 1959475] Re: "machinectl shell" connections immediately terminated

[Dan Streetman]

> The patch expands the case where the TERM variable is inherited from
PID 1 when building an execution environment, e.g. for a container. If
problems were to occur, it would be related to the value of TERM in
environments forked off of PID 1.

Eh? That isn't at all what the patch does...

Anyway, that patch only incidentally 'fixes' this, by changing the
caller to use path_equals_ptr which null-checks; while a better commit
is 105396778174a39bb04e9a78281ec7601e252d9f which fixes path_compare()
itself (i.e. for all callers).

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

Title:
  "machinectl shell" connections immediately terminated

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  This bug prevents users on Impish and newer from connecting to Focal
  systemd containers using `machinectl shell`. This limits users ability
  to manage containers spawned with systemd-nspawn.

  [Test Plan]

  On a Jammy host, do the following:

  * Install systemd-container and debootstrap if necessary:

$ sudo apt install debootstrap systemd-container

  * Create a Focal filesystem for the container:

$ sudo debootstrap --arch= focal
  /var/lib/containers/lp1959475/

  * Launch the container:

$ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine
  test-container

  * Inside the container, set a password for root and then exit:

$ passwd # Enter password when prompted
$ exit

  * Re-launch the container with -b option:

$ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine
  test-container -b

  * In a separate terminal window, try to connect to the container:

$ sudo machinectl shell test-container

  * Observe the "Connection to machine test-container terminated" error
  message.

  [Where problems could occur]

  The patch expands the case where the TERM variable is inherited from
  PID 1 when building an execution environment, e.g. for a container. If
  problems were to occur, it would be related to the value of TERM in
  environments forked off of PID 1.

  [Other Info]

  This bug occurs when trying to connect to a Focal container from e.g. a Jammy 
host. For SRU verification, the container
  should be Focal, and the host should be Jammy. The -proposed package should 
be installed in the Focal container.

  [Original Description]

  The command "machinectl shell" does not work in systemd
  249.9-0ubuntu2:

  $ sudo machinectl shell ns-xxx
  Connected to machine ns-xxx. Press ^] three times within 1s to exit session.

  Connection to machine ns-xxx terminated.

  The issue seems to be described here:
  
https://forum.manjaro.org/t/the-machinectl-shell-command-stopped-working-after-systemd-upgrade-to-250-2-1/99899
  https://github.com/systemd/systemd/issues/22234

  and solved here:

  
https://github.com/systemd/systemd/commit/e8cf09b2a2ad0d48e5493050d54251d5f512d9b6

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1959475/+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 1977630] Re: machinectl pull-tar/pull-raw Operation not permitted

[Dan Streetman]

** Description changed:

+ [impact]
+ 
+ machinectl pull-tar does not work, ever
+ 
+ [test case]
+ 
+ see comment 2
+ 
+ [regression potential]
+ 
+ problems/failures during pull-tar operation
+ 
+ [scope]
+ 
+ needed only in j
+ 
+ fixed (indirectly) by upstream commit referenced in original
+ description, which is included in v250, so fixed already in k
+ 
+ pull-tar does not fail on f; no fix needed there
+ 
+ [original description]
+ 
  There is a bug in systemd 249, where one can't pull any images. This was
  fixed in version 250, and never got backported. (FIX:
  
https://github.com/systemd/systemd/commit/c40d82abf7b23803aa7394a7a7e24c40c32af851)
  
  Hopefully this can be addressed.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd-container 249.11-0ubuntu3.1
  ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35
  Uname: Linux 5.15.0-35-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jun  4 04:51:42 2022
  InstallationDate: Installed on 2022-06-01 (2 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220419)
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/1977630

Title:
  machinectl pull-tar/pull-raw Operation not permitted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  New

Bug description:
  [impact]

  machinectl pull-tar does not work, ever

  [test case]

  see comment 2

  [regression potential]

  problems/failures during pull-tar operation

  [scope]

  needed only in j

  fixed (indirectly) by upstream commit referenced in original
  description, which is included in v250, so fixed already in k

  pull-tar does not fail on f; no fix needed there

  [original description]

  There is a bug in systemd 249, where one can't pull any images. This
  was fixed in version 250, and never got backported. (FIX:
  
https://github.com/systemd/systemd/commit/c40d82abf7b23803aa7394a7a7e24c40c32af851)

  Hopefully this can be addressed.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd-container 249.11-0ubuntu3.1
  ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35
  Uname: Linux 5.15.0-35-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jun  4 04:51:42 2022
  InstallationDate: Installed on 2022-06-01 (2 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220419)
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1977630/+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 1961833] Re: openssh 8.8 breaks login to Canonical servers

[Dan Streetman]

Note: this also affects anyone trying to connect to the dev.azure.com
servers (to, for example, git clone g...@ssh.dev.azure.com...)

$ ssh -vv ssh.dev.azure.com
...
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 
diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-rsa
...
Unable to negotiate with 20.41.6.2 port 22: no matching host key type found. 
Their offer: ssh-rsa

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

Title:
  openssh 8.8 breaks login to Canonical servers

Status in openssh package in Ubuntu:
  Won't Fix

Bug description:
  With 8.7p1-4 connecting to wendigo

  debug1: Next authentication method: publickey
  debug1: Offering public key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent
  debug1: Server accepts key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent

  With 8.8p1-1

  debug1: Offering public key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent

 
  debug1: send_pubkey_test: no mutual signature algorithm   

  
  Needs further investigation, but blocks people a bit right now

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1961833/+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 1987356] Re: [BPO] elfutils/0.187-1 from Kinetic

[Dan Streetman]

** Changed in: elfutils (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  [BPO] elfutils/0.187-1 from Kinetic

Status in elfutils package in Ubuntu:
  Fix Released
Status in elfutils source package in Jammy:
  Fix Released

Bug description:
  [Impact]

   * elfutils ships many ELF/DWARF related tools that are interesting
  for users and developers of low level code.

   * More specifically, elfutils ships the debuginfod library and
  server.  Ubuntu is going to have a debuginfod server soon (see
  https://blog.sergiodj.net/2022/08/14/debuginfod-is-coming-to-
  ubuntu.html), and there have been many important changes that impact
  debuginfod's performance on 0.187.

  [Scope]

   * I will backport elfutils/0.187 from Kinetic.

   * I will backport elfutils/0.187 to Jammy.

  [Other Info]
   
   * None so far.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/1987356/+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 1983414] Re: [BPO] dh-python 5.20220403 to focal

[Dan Streetman]

Comments:

1. This adds Suggests: flit, python3-build, python3-tomli,
python3-installer; however, those aren't available in focal.

2. Similiarly, the newly-added package pybuild-plugin-pyproject Depends:
on the python3-{build,installer,tomli} packages, which aren't available
in focal.

3. This adds Breaks: and Replaces: for python2 (<< 2.7.18-2), but in
focal python2 is 2.7.17-2ubuntu4. Either dh_python2 needs to be moved
from python-defaults in focal (or more likely focal-backports) to this
package, or this backport needs to leave out dh_python2 (and it should
be verified that the only reason for the Breaks: is because of moving
the dh_python2 script between packages).


There may be more issues, I didn't look in depth at all the code changes; I can 
do a closer review if the above issues are addressed first, or at least looked 
at to see if those issues are possible/reasonable to fix.

** Changed in: dh-python (Ubuntu Focal)
   Status: New => Incomplete

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

Title:
  [BPO] dh-python 5.20220403 to focal

Status in dh-python package in Ubuntu:
  Fix Released
Status in dh-python source package in Focal:
  Incomplete

Bug description:
  [Impact]

   * This is needed to refresh the yt-dlp package as it has support for 
'environment markers'
   * This version could also be useful for other projects as it adds support 
for pyproject.

  [Scope]

  Backport from:
   * To me it makes sense to backport from jammy (LTS), though the version 
currently is the same as devel.

  Backport to:
   * focal

  
  [Other Info]

   * I have created a test backport in ppa:unit193/staging and have
  already utilized.

  [Testing]

  * focal:
  [x] Package builds without modification
  [x] dh-python installs cleanly and runs
  [?] pybuild-plugin-pyproject installs cleanly and runs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1983414/+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 1940715] Re: systemd-resolved restricts edns0 advertised max size to 512

[Dan Streetman]

** Changed in: systemd (Ubuntu Hirsute)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Focal)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Bionic)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => New

** Changed in: systemd (Ubuntu Bionic)
   Status: In Progress => 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/1940715

Title:
  systemd-resolved restricts edns0 advertised max size to 512

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix

Bug description:
  [impact]

  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of
  the primary benefits of edns0 is to allow using packet sizes larger
  than 512, which is the pre-edns0 max packet size.

  this results in systemd-resolved failing to handle responses larger
  than 512 with udp/edns0, and having to fall back to tcp. This is not
  optimal (since tcp dns imposes significantly higher overhead) and may
  even cause failures, if a firewall allows udp dns but blocks tcp dns
  traffic.

  [test case]

  enable debug logging in systemd-resolved, with 'sudo systemctl edit
  systemd-resolved' and then add:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then save that file and restart systemd-resolved (or reboot).

  Make sure to flush the cache and reset server features before
  reproducing:

  $ sudo resolvectl flush-caches
  $ sudo resolvectl reset-server-features

  Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see
  if it used TCP fallback or not:

  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a 
response at feature level TCP from DNS server 10.202.51.1.
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive 
unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on 
eth0/INET/10.202.51.1

  A correct lookup using larger EDNS0 response size looks like:

  ...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level 
UDP+EDNS0 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 
10.202.51.1 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 
1472 in egress EDNS(0) packet.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 
1500, socket MTU is 0, minimal MTU is 40
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with 
id 43808 of size 49.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing query...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Received dns UDP packet of 
size 689, ifindex=131, ttl=0, fragsize=0
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing incoming packet 
of size 689 on transaction 43808 (rcode=SUCCESS).
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Added positive 
unauthenticated non-confidential cache entry for toomany.ddstreet.org IN A 
1175s on eth0/INET/10.202.51.1
  ...

  [regression potential]

  failure to correctly look up dns records, or other problems while
  performing dns lookups with systemd-resolved

  [scope]

  this is needed in impish and earlier

  this is fixed in jammy at commit
  22545a74c3a24395bc6e894fe6a681deb66d434c

  this is fixed upstream by commit
  526fce97afe130f71dba3bd4646196bbb1188b82 which in included in v250, so
  this is fixed in kinetic and later

  the upstream PR is:
  https://github.com/systemd/systemd/pull/20528

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1940715/+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 1970449] Re: GPG keys are not shown in Software and Updates

[Dan Streetman]

I believe the problem is that 'apt-key' uses only the
/etc/apt/trusted.gpg file, while software-properties now (correctly)
creates individual /etc/apt/trusted.gpg.d/*.gpg files for each key
added.

The software-properties AptAuth.py module should probably be changed to
stop using apt-key, and/or apt-key should be fixed to correctly use all
the 'trusted.gpg' files (main file and subdir/'drop-in' files).

This evaluation is just from a quick scan of apt-key source, so someone
might want to verify that apt-key is actually the problem.

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

Title:
  GPG keys are not shown in Software and Updates

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  software-properties-gtk does not show the registered apt gpg keys in
  the "Authentication" tab on my Ubuntu 21.10 and 22.04 systems.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: ubuntu-release-upgrader-core 1:22.04.10
  ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30
  Uname: Linux 5.15.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82
  Architecture: amd64
  CasperMD5CheckResult: pass
  CrashDB: ubuntu
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Apr 26 20:48:04 2022
  InstallationDate: Installed on 2022-04-25 (0 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220419)
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  Symptom: ubuntu-release-upgrader
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1970449/+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 1964494] Re: Setting DuplicateAddressDetection=none doesn't disable DAD for link-local IPs

[Dan Streetman]

marked verified per comment 10

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

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

Title:
  Setting DuplicateAddressDetection=none doesn't disable DAD for link-
  local IPs

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [impact]

  manual disabling of ipv4 DAD (IACD) for static link-local address does
  not work in jammy

  [test case]

  see 'Reproducer' in original description below

  [regression potential]

  failure to disable DAD, or incorrect disabling of DAD, or networkd
  issues around parsing of DAD config parsing

  [scope]

  this is needed for j and k

  introduced upstream by commit
  1cf4ed142d6c1e2b9dc6a0bc74b6a83ae30b0f8e, first included in v249, so
  this bug does not affect impish or earlier

  fixed upstream by commit 2859932bd64d61a89f85fa027762bc16961fcf53

  [original description]

  A customer reported network disconnections on their storage
  servers when running 'netplan apply'. The culprit was that
  they have link-local addresses configured and the Duplicate
  Address Detection (DAD) mechanism was delaying the interfaces
  from coming back up.

  As a workaround we tried to disable DAD for the interfaces
  but that's not working in Ubuntu 22.04:

  I've noticed that setting DuplicateAddressDetection=none for an
  interface with a link-local address (e.g., 169.254.*) via a
  .network file added to /etc/systemd/network/ doesn't really
  disable Duplicate Address Detection.

  OS and package versions:
  
   - Description:   Ubuntu Jammy Jellyfish (development branch). Release: 
22.04
   - systemd 249.5-2ubuntu4

  Reproducer:
  ---
  1- Set up Ubuntu 22.04 VM
  2- Increase systemlog level:

    mkdir -p /etc/systemd/system/systemd-networkd.service.d/
    cat > /etc/systemd/system/systemd-networkd.service.d/10-debug.conf 

[Touch-packages] [Bug 1964494] Re: Setting DuplicateAddressDetection=none doesn't disable DAD for link-local IPs

[Dan Streetman]

** Description changed:

- A customer reported network disconnections on their storage 
+ [impact]
+ 
+ manual disabling of ipv4 DAD (IACD) for static link-local address does
+ not work in jammy
+ 
+ [test case]
+ 
+ see 'Reproducer' in original description below
+ 
+ [regression potential]
+ 
+ failure to disable DAD, or incorrect disabling of DAD, or networkd
+ issues around parsing of DAD config parsing
+ 
+ [scope]
+ 
+ this is needed for j and k
+ 
+ introduced upstream by commit 1cf4ed142d6c1e2b9dc6a0bc74b6a83ae30b0f8e,
+ first included in v249, so this bug does not affect impish or earlier
+ 
+ fixed upstream by commit 2859932bd64d61a89f85fa027762bc16961fcf53
+ 
+ [original description]
+ 
+ A customer reported network disconnections on their storage
  servers when running 'netplan apply'. The culprit was that
- they have link-local addresses configured and the Duplicate 
- Address Detection (DAD) mechanism was delaying the interfaces 
- from coming back up. 
+ they have link-local addresses configured and the Duplicate
+ Address Detection (DAD) mechanism was delaying the interfaces
+ from coming back up.
  
- As a workaround we tried to disable DAD for the interfaces 
+ As a workaround we tried to disable DAD for the interfaces
  but that's not working in Ubuntu 22.04:
  
  I've noticed that setting DuplicateAddressDetection=none for an
- interface with a link-local address (e.g., 169.254.*) via a 
- .network file added to /etc/systemd/network/ doesn't really 
+ interface with a link-local address (e.g., 169.254.*) via a
+ .network file added to /etc/systemd/network/ doesn't really
  disable Duplicate Address Detection.
  
  OS and package versions:
  
-  - Description:   Ubuntu Jammy Jellyfish (development branch). Release: 
22.04
-  - systemd 249.5-2ubuntu4
+  - Description:   Ubuntu Jammy Jellyfish (development branch). Release: 
22.04
+  - systemd 249.5-2ubuntu4
  
  Reproducer:
  ---
  1- Set up Ubuntu 22.04 VM
  2- Increase systemlog level:
  
-   mkdir -p /etc/systemd/system/systemd-networkd.service.d/
-   cat > /etc/systemd/system/systemd-networkd.service.d/10-debug.conf < /etc/systemd/system/systemd-networkd.service.d/10-debug.conf  /etc/systemd/system/systemd-networkd.service.d/10-debug.conf 

[Touch-packages] [Bug 1940715] Re: systemd-resolved restricts edns0 advertised max size to 512

[Dan Streetman]

** Description changed:

  [impact]
  
  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of the
  primary benefits of edns0 is to allow using packet sizes larger than
  512, which is the pre-edns0 max packet size.
  
  this results in systemd-resolved failing to handle responses larger than
  512 with udp/edns0, and having to fall back to tcp. This is not optimal
  (since tcp dns imposes significantly higher overhead) and may even cause
  failures, if a firewall allows udp dns but blocks tcp dns traffic.
  
  [test case]
  
  enable debug logging in systemd-resolved, with 'sudo systemctl edit
  systemd-resolved' and then add:
  
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug
  
  then save that file and restart systemd-resolved (or reboot).
  
  Make sure to flush the cache and reset server features before
  reproducing:
  
  $ sudo resolvectl flush-caches
  $ sudo resolvectl reset-server-features
  
  Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see if
  it used TCP fallback or not:
  
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a 
response at feature level TCP from DNS server 10.202.51.1.
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive 
unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on 
eth0/INET/10.202.51.1
  
  A correct lookup using larger EDNS0 response size looks like:
  
  ...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level 
UDP+EDNS0 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 
10.202.51.1 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 
1472 in egress EDNS(0) packet.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 
1500, socket MTU is 0, minimal MTU is 40
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with 
id 43808 of size 49.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing query...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Received dns UDP packet of 
size 689, ifindex=131, ttl=0, fragsize=0
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing incoming packet 
of size 689 on transaction 43808 (rcode=SUCCESS).
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Added positive 
unauthenticated non-confidential cache entry for toomany.ddstreet.org IN A 
1175s on eth0/INET/10.202.51.1
  ...
  
  [regression potential]
  
  failure to correctly look up dns records, or other problems while
  performing dns lookups with systemd-resolved
  
  [scope]
  
- this is needed for all releases
+ this is needed in impish and earlier
  
- this still needs fixing upstream:
+ this is fixed in jammy at commit
+ 22545a74c3a24395bc6e894fe6a681deb66d434c
+ 
+ this is fixed upstream by commit
+ 526fce97afe130f71dba3bd4646196bbb1188b82 which in included in v250, so
+ this is fixed in kinetic and later
+ 
+ the upstream PR is:
  https://github.com/systemd/systemd/pull/20528

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

Title:
  systemd-resolved restricts edns0 advertised max size to 512

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Confirmed

Bug description:
  [impact]

  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of
  the primary benefits of edns0 is to allow using packet sizes larger
  than 512, which is the pre-edns0 max packet size.

  this results in systemd-resolved failing to handle responses larger
  than 512 with udp/edns0, and having to fall back to tcp. This is not
  optimal (since tcp dns imposes significantly higher overhead) and may
  even cause failures, if a firewall allows udp dns but blocks tcp dns
  traffic.

  [test case]

  enable debug logging in systemd-resolved, with 'sudo systemctl edit
  systemd-resolved' and then add:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then save that file and restart systemd-resolved (or reboot).

  Make sure to flush the cache and reset server features before
  reproducing:

  $ sudo resolvectl flush-caches
  $ sudo resolvectl reset-server-features

  Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see
  if it used TCP fallback or not:

  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resol

[Touch-packages] [Bug 1940715] Re: systemd-resolved restricts edns0 advertised max size to 512

[Dan Streetman]

** Changed in: systemd (Ubuntu Hirsute)
   Status: In Progress => Won't Fix

** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/1940715

Title:
  systemd-resolved restricts edns0 advertised max size to 512

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Confirmed

Bug description:
  [impact]

  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of
  the primary benefits of edns0 is to allow using packet sizes larger
  than 512, which is the pre-edns0 max packet size.

  this results in systemd-resolved failing to handle responses larger
  than 512 with udp/edns0, and having to fall back to tcp. This is not
  optimal (since tcp dns imposes significantly higher overhead) and may
  even cause failures, if a firewall allows udp dns but blocks tcp dns
  traffic.

  [test case]

  enable debug logging in systemd-resolved, with 'sudo systemctl edit
  systemd-resolved' and then add:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then save that file and restart systemd-resolved (or reboot).

  Make sure to flush the cache and reset server features before
  reproducing:

  $ sudo resolvectl flush-caches
  $ sudo resolvectl reset-server-features

  Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see
  if it used TCP fallback or not:

  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a 
response at feature level TCP from DNS server 10.202.51.1.
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive 
unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on 
eth0/INET/10.202.51.1

  A correct lookup using larger EDNS0 response size looks like:

  ...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level 
UDP+EDNS0 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 
10.202.51.1 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 
1472 in egress EDNS(0) packet.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 
1500, socket MTU is 0, minimal MTU is 40
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with 
id 43808 of size 49.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing query...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Received dns UDP packet of 
size 689, ifindex=131, ttl=0, fragsize=0
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing incoming packet 
of size 689 on transaction 43808 (rcode=SUCCESS).
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Added positive 
unauthenticated non-confidential cache entry for toomany.ddstreet.org IN A 
1175s on eth0/INET/10.202.51.1
  ...

  [regression potential]

  failure to correctly look up dns records, or other problems while
  performing dns lookups with systemd-resolved

  [scope]

  this is needed in impish and earlier

  this is fixed in jammy at commit
  22545a74c3a24395bc6e894fe6a681deb66d434c

  this is fixed upstream by commit
  526fce97afe130f71dba3bd4646196bbb1188b82 which in included in v250, so
  this is fixed in kinetic and later

  the upstream PR is:
  https://github.com/systemd/systemd/pull/20528

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1940715/+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 1881207] Re: systemd-networkd brings eno1 up and down repeatedly

[Dan Streetman]

** Changed in: systemd (Ubuntu)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Bionic)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Eoan)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Focal)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Groovy)
     Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Hirsute)
     Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Impish)
 Assignee: Dan Streetman (ddstreet) => (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/1881207

Title:
  systemd-networkd brings eno1 up and down repeatedly

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Eoan:
  Won't Fix
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  Won't Fix
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  In Progress

Bug description:
  [impact]

  a system using dhcp for an interface where (1) the interface 'resets'
  itself during mtu setting (meaning it briefly drops carrier during mtu
  change), and (2) the dhcp server provides a non-standard (i.e. other
  than 1500) mtu, will continually loop changing mtu between 1500 and
  the dhcp-privded mtu.

  [test case]

  The e1000e nic is one such nic where the driver briefly drops carrier
  when changing the mtu, so this can be reproduced by creating a VM and
  setting the interface to the 'e1000e' emulated hardware. Then
  configure a dhcp server to provide dhcp service to the VM, and set the
  mtu to e.g. 9000 (anything other than the default 1500).

  When the VM runs dhcp, it will loop with:

  Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier
  Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 
address 1.2.3.133/24 via 1.2.3.1
  Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier
  Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease 
lost
  Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease 
lost
  Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier
  Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 
address 1.2.3.133/24 via 1.2.3.1
  Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier
  Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease 
lost
  Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease 
lost
  Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier
  Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 
address 1.2.3.133/24 via 1.2.3.1
  Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier
  Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease 
lost
  Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease 
lost

  [regression potential]

  any regression would likely involve an issue with dhcpv4 service;
  possibly not setting the mtu correctly, or possibly not completing
  dhcpv4 at all.

  [scope]

  this is not fixed upstream yet, so (once fixed upstream) it will be
  needed for b/f/g/h

  [original description]

  Running on a NUC (BOXNUC8i7BEH3).

  After updating the `systemd` package past `237-3ubuntu10.32`, I see
  the onboard NIC link being taken down / up repeatedly, as shown below
  (dates are from my original notes, but the issue remains the same
  today).

  The NIC fails to remain up, and all networking is out of action.

  Running `systemctl stop systemd-netword` stops this and leaves the NIC in an 
unknown state.
  Subsequently running `ifconfig eno1 up && dhclient eno1` allows networking to 
continue basic operation, albeit without systemd's oversight.

  My original solution was to downgrade both the `libsystemd0` and
  `systemd` packages to `237-3ubuntu10.28`.

  After attempting an `apt update && apt upgrade` again today, exactly
  the same thing is happening with `237-3ubuntu10.41`.

  Good versions:
  - 237-3ubuntu10.28
  - 237-3ubuntu10.32 (currently in use, and held)

  Bad versions:
  - 237-3ubuntu10.33
  - 237-3ubuntu10.38
  - 237-3ubuntu10.41

  dmesg:

  [  360.711367] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: Rx/Tx
  [  360.714370] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000
  [  360.726189] e1000e :00:1f.6: Interrupt Throttle Rate off
  [  361.733073] e1000e 

[Touch-packages] [Bug 1961833] Re: openssh 8.8 breaks login to Canonical servers

[Dan Streetman]

interestingly, paramiko is also broken when connecting to older servers,
but not for the same reason as this bug. See bug 1973241

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

Title:
  openssh 8.8 breaks login to Canonical servers

Status in openssh package in Ubuntu:
  Won't Fix

Bug description:
  With 8.7p1-4 connecting to wendigo

  debug1: Next authentication method: publickey
  debug1: Offering public key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent
  debug1: Server accepts key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent

  With 8.8p1-1

  debug1: Offering public key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent

 
  debug1: send_pubkey_test: no mutual signature algorithm   

  
  Needs further investigation, but blocks people a bit right now

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1961833/+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 1961833] Re: openssh 8.8 breaks login to Canonical servers

[Dan Streetman]

For reference to anyone coming here with this problem, when connecting
to a remote sshd server you can find what host key algorithms the remote
host uses by using -vv and check the debug output; look first for the
*peer* server KEXINIT proposal (not the earlier *local client* KEXINIT
proposal):

debug2: peer server KEXINIT proposal

a line or two after that, you should see the list of host key algorithms
the remote host is offering; if it contains *only* ssh-rsa then this bug
is relevant.

debug2: host key algorithms: ssh-rsa

Note that by default many systems support multiple algorithms, e.g. you
may see:

debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-
ed25519

in this case, even though the remote host does offer ssh-rsa, it also
supports other algorithms that jammy does support.

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

Title:
  openssh 8.8 breaks login to Canonical servers

Status in openssh package in Ubuntu:
  Won't Fix

Bug description:
  With 8.7p1-4 connecting to wendigo

  debug1: Next authentication method: publickey
  debug1: Offering public key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent
  debug1: Server accepts key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent

  With 8.8p1-1

  debug1: Offering public key: /home/jak/.ssh/id_rsa RSA 
SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent

 
  debug1: send_pubkey_test: no mutual signature algorithm   

  
  Needs further investigation, but blocks people a bit right now

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1961833/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

** Changed in: openssl (Ubuntu)
 Assignee: Nicolas Bock (nicolasbock) => (unassigned)

** Changed in: openssl (Ubuntu Bionic)
 Assignee: Nicolas Bock (nicolasbock) => Bruce Elrick (virtuous-sloth)

** Changed in: openssl (Ubuntu Bionic)
   Status: Fix Committed => In Progress

** Tags removed: verification-needed verification-needed-bionic

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  In Progress

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

** Changed in: systemd (Ubuntu)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Hirsute)
 Assignee: Dan Streetman (ddstreet) => (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/1906331

Title:
  systemd-resolve crashes fairly often (and reports various assertions)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Incomplete
Status in systemd source package in Groovy:
  Won't Fix
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  systemd-resolved crashes

  [test case]

  see original description; I can't reproduce so I'm relying on the
  reporter(s) to test/verify.

  [regression potential]

  any regression would likely occur while processing sd_event objects,
  which are used throughout systemd code; this could result in crashes
  in almost any part of systemd code. However a more likely regression
  would be leaks of sd_event objects due to failure to release the final
  ref for an object.

  [scope]

  This is needed for f/g/h

  This might be fixed by upstream commit
  f814c871e65df8552a055dd887bc94b074037833; if so, that commit isn't
  included in any systemd release yet, and so is needed in h and
  earlier.

  [other info]

  I believe this is caused by a freed sd_event object that is then
  processed and calls the on_query_timeout callback with invalid state,
  leading to failed assertion, which causes resolved to crash; that's
  what analysis of the crash dump appears to indicate. This may be fixed
  by the upstream commit referenced in [scope], which takes additional
  refs during function calls. However I haven't reproduced this myself,
  so I'm only guessing as to the cause and solution at this point.

  I'm unsure why this would not occur in bionic, but per comment 5 it
  seems it doesn't happen in that release.

  [original description]

  (Tested on regularly updated Ubuntu 20.04, currently i use systemd
  245.4-4ubuntu3.2)

  I observe fairly lot of segfaults of systemd-resolve. Frequency vary
  but … see below.

  I have no clue what is the reason. Specific feature of my machine is
  that apart from normal cable connection (to OpenWRT router) I use
  OpenVPN for business network (and this submits specific nameserver for
  myorg.local domain).

  ~
  $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve
  [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 
ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in 
libsystemd-shared-245.so[7fd98f74c000+16e000]
  [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 
55ab7b0cb686 sp 7fff78ce4bd0 error 4 in 
systemd-resolved[55ab7b0a4000+3e000]
  [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 
55ca69fed91c sp 7ffc4d757dc0 error 6 in 
systemd-resolved[55ca69fc2000+3e000]
  [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 
ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in 
libsystemd-shared-245.so[7fc1bc994000+16e000]
  [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 
ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in 
libsystemd-shared-245.so[7f7ed17c4000+16e000]
  [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 
558d992e2686 sp 7fff08906af0 error 4 in 
systemd-resolved[558d992bb000+3e000]
  [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 
ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in 
libsystemd-shared-245.so[7fd4c16fc000+16e000]
  [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 
ip 7f1008549dc9 sp 7fff44a6db70 error 4 in 
libsystemd-shared-245.so[7f1008524000+16e000]
  [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 
55a37fe5a686 sp 7ffd9a160440 error 4 in 
systemd-resolved[55a37fe33000+3e000]
  [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 
ip 558d292947d0 sp 7ffec7ab3bf8 error 15
  [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 
ip 558995b77cf0 sp 7ffe545ae4a8 error 15
  [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 
ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in 
libsystemd-shared-245.so[7f66bb504000+16e000]
  [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 
ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in 
libsystemd-shared-245.so[7fdc40b2c000+16e000]
  [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 
ip 7f6a92839dc9 sp 7ffe4ba00440 error 4 in 
libsystemd-shared-245.so[7f6a92814000+16e000]
  [Sun Nov 29 21:13:10 2020] systemd-resolve[1660272]: segfault at 555f9a5915e0 
ip 0

[Touch-packages] [Bug 1928733] Re: Starting systemd Network Service fails with "Invalid argument"

[Dan Streetman]

per comment 6, this should be fixed in jammy, so marking fixed released
there.

** Changed in: systemd (Ubuntu)
   Status: Triaged => 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/1928733

Title:
  Starting systemd Network Service fails with "Invalid argument"

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Triaged
Status in systemd source package in Focal:
  Triaged
Status in systemd source package in Groovy:
  Won't Fix
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Triaged

Bug description:
  This server has a new install of Ubuntu 18.04 server. Sometimes
  (around 50% of the time) when it boots systemd-networkd.service
  initially fails to start with an error as below. It then tries again
  and succeeds, however other services which depend on systemd-networkd
  have already failed on the dependency by then.

  From the output of "journalctl -u systemd-networkd":

  -- Reboot --
  May 17 19:44:28 server1 systemd[1]: Starting Network Service...
  May 17 19:44:30 server1 systemd[2261]: systemd-networkd.service: Failed to 
set up mount namespacing: Invalid argument
  May 17 19:44:30 server1 systemd[2261]: systemd-networkd.service: Failed at 
step NAMESPACE spawning /lib/systemd/systemd-networkd: Invalid argument
  May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Main process 
exited, code=exited, status=226/NAMESPACE
  May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Failed with 
result 'exit-code'.
  May 17 19:44:30 server1 systemd[1]: Failed to start Network Service.
  May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Service has no 
hold-off time, scheduling restart.
  May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Scheduled 
restart job, restart counter is at 1.
  May 17 19:44:30 server1 systemd[1]: Stopped Network Service.
  May 17 19:44:30 server1 systemd[1]: Starting Network Service...
  May 17 19:44:30 server1 systemd-networkd[2321]: Enumeration completed
  May 17 19:44:30 server1 systemd[1]: Started Network Service.
  May 17 19:44:30 server1 systemd-networkd[2321]: eno2: IPv6 successfully 
enabled
  May 17 19:44:30 server1 systemd-networkd[2321]: eno1: Link is not managed by 
us
  May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f0np0: Link is not 
managed by us
  May 17 19:44:30 server1 systemd-networkd[2321]: lo: Link is not managed by us
  May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f1np1: Link is not 
managed by us
  May 17 19:44:30 server1 systemd-networkd[2321]: eno1: IPv6 successfully 
enabled
  May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f0np0: Link is not 
managed by us
  May 17 19:44:30 server1 systemd-networkd[2321]: lo: Link is not managed by us
  May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f1np1: Link is not 
managed by us
  May 17 19:44:31 server1 systemd-networkd[2321]: eno2: Link UP
  May 17 19:44:31 server1 systemd-networkd[2321]: eno1: Link UP
  May 17 19:44:34 server1 systemd-networkd[2321]: eno2: Gained carrier
  May 17 19:44:34 server1 systemd-networkd[2321]: eno1: Gained carrier
  May 17 19:44:35 server1 systemd-networkd[2321]: eno1: Gained IPv6LL
  May 17 19:44:35 server1 systemd-networkd[2321]: eno1: Configured
  May 17 19:44:36 server1 systemd-networkd[2321]: eno2: Gained IPv6LL
  May 17 19:44:36 server1 systemd-networkd[2321]: eno2: Configured

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.46
  ProcVersionSignature: Ubuntu 4.15.0-142.146-generic 4.15.18
  Uname: Linux 4.15.0-142-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.23
  Architecture: amd64
  Date: Mon May 17 19:53:11 2021
  InstallationDate: Installed on 2021-03-18 (60 days ago)
  InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 1604:10c0 Tascam 
   Bus 001 Device 003: ID 1604:10c0 Tascam 
   Bus 001 Device 002: ID 1604:10c0 Tascam 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. PowerEdge R440
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-142-generic 
root=/dev/mapper/vg1-lv_root ro processor.max_cstate=1 intel_idle.max_cstate=0 
transparent_hugepage=never
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/23/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.9.3
  dmi.board.name: 04JN2K
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A06
  dmi.chassis.type: 23
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.9.3:bd09/23/2020:svnDellInc.:pnPowerEdgeR440:pvr:rvnDellInc.:rn04JN2K:rvrA06:cvnDellInc.:ct23:cvr:
  dmi.product.family: PowerEdge
 

[Touch-packages] [Bug 1939255] Re: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once

[Dan Streetman]

> It seems this issue may occur not only when receiving addresses on
multiple interfaces, but also when dhcp requests on multiple interfaces
times out and the hook script was called with 'reason' == FAIL.

yep, the try-reload-or-restart is done for those as well and this should
be fixed for those $reason cases; since this bug is already resolved, I
suggest you open a new bug.

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

Title:
  dhclient triggers systemd-resolved start limit when processing more
  than 5 interfaces at once

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  on a system where systemd-resolved is running, if dhclient is used on
  more than 5 interfaces, it calls the '/etc/dhcp/dhclient-enter-
  hooks.d/resolved' script multiple times, which then restarts systemd-
  resolved multiple times, triggering the unit's start-limit throttle
  which results in the unit entering failed state

  [test case]

  on a system with more than 5 available interfaces to run dhclient on
  (where all the interfaces will get a dhcp response), run dhclient with
  the interfaces:

  $ dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15

  check if systemd-resolved failed:

  $ journalctl -b -1 -u systemd-resolved
  ...
  Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Start 
request repeated too quickly.
  Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Failed with 
result 'start-limit-hit'.
  Aug 09 00:38:08 sf316232-b systemd[1]: Failed to start Network Name 
Resolution.

  [regression potential]

  failure to start/stop/restart systemd-resolved, or problems adding
  dhclient-provided DNS nameservers to systemd-resolved

  [scope]

  this is needed only for b/f

  the dhclient 'hook' script is provided by the systemd package in focal
  and earlier, and needs fixing in those releases

  in h and later, the 'hook' script is included in the isc-dhcp-client
  package and notifies systemd-resolved in a more direct way without
  requiring restarting, and so doesn't trigger the restart limiting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1939255/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04

[Dan Streetman]

> I think you have a problem there too.

oh I'm certainly not claiming a 1g default swap is appropriate, that
does seem far, far too small to me and will likely cause widespread
issues beyond just this, I was only saying that tweaking the systemd-
oomd swap % full setting would IMHO not be likely to fix this very well
- and as you point out increasing the swap size to a more reasonable
size almost certainly will help (and might be why upstream hadn't
noticed this before), regardless of the systemd-oomd swap % used default
setting, because it would be far less likely to fill swap up to the oomd
swap % full default.

> Maybe running with such a starved swapspace triggers systemd-oom to do
weird things?

>From my quick read of the code, it doesn't seem to be doing anything
weird at all, I think it's doing exactly what it's programmed to do. I
just don't think the code is correct.

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

Title:
  applications crash that never crashed under Ubuntu-20.04

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  Just now I was watching some video in Firefox. I popped over to
  another virtual workspace for a few minutes, and when I popped back to
  Firefox it had gone. The same thing had been happening all week (I
  installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and
  Thunderbird.

  This time instead of shrugging it off I looked in the logs, and found
  this

  Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope
 due to memory used (15940579328) / total (16153944064) and swap used 
(925564928) / total (1023406080) being more than 90.00%
  Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: 
systemd-oomd killed 298 process(es) in this unit.
  Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope
 due to memory used (15591993344) / total (16149745664) and swap used 
(927760384) / total (1023406080) being more than 90.00%
  Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: 
systemd-oomd killed 173 process(es) in this unit.

  I know it's saying those three entirely unrelated applications had
  suddenly decided to swallow all the RAM+swap on this laptop of mine -
  but the very same apps didn't act like that last week under
  Ubuntu-20.04, so I suspect something else is going on

  I can't say they hadn't swallowed all the RAM, but there is ZERO sign
  of a system on the verge of collapsing - everything has been screaming
  along just nicely - no sign of the "staggering" you normally get when
  the OS is heavily into swap.

  However, now that I look I see my 16G laptop only has 1G swap??? I
  just let the Ubuntu installer do it's defaults - but it used to auto-
  choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be
  related?

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd-oomd 249.11-0ubuntu1
  ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
  Uname: Linux 5.15.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 25 19:47:44 2022
  InstallationDate: Installed on 2022-03-13 (11 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313)
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04

[Dan Streetman]

> it's going to be hard to get around the core issue of oomd counting
pagecache as memory pressure

assuming my quick 10-minute assessment of this bug is correct, of
course...maybe i'm totally wrong about what the problem is ;-)

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

Title:
  applications crash that never crashed under Ubuntu-20.04

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  Just now I was watching some video in Firefox. I popped over to
  another virtual workspace for a few minutes, and when I popped back to
  Firefox it had gone. The same thing had been happening all week (I
  installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and
  Thunderbird.

  This time instead of shrugging it off I looked in the logs, and found
  this

  Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope
 due to memory used (15940579328) / total (16153944064) and swap used 
(925564928) / total (1023406080) being more than 90.00%
  Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: 
systemd-oomd killed 298 process(es) in this unit.
  Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope
 due to memory used (15591993344) / total (16149745664) and swap used 
(927760384) / total (1023406080) being more than 90.00%
  Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: 
systemd-oomd killed 173 process(es) in this unit.

  I know it's saying those three entirely unrelated applications had
  suddenly decided to swallow all the RAM+swap on this laptop of mine -
  but the very same apps didn't act like that last week under
  Ubuntu-20.04, so I suspect something else is going on

  I can't say they hadn't swallowed all the RAM, but there is ZERO sign
  of a system on the verge of collapsing - everything has been screaming
  along just nicely - no sign of the "staggering" you normally get when
  the OS is heavily into swap.

  However, now that I look I see my 16G laptop only has 1G swap??? I
  just let the Ubuntu installer do it's defaults - but it used to auto-
  choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be
  related?

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd-oomd 249.11-0ubuntu1
  ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
  Uname: Linux 5.15.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 25 19:47:44 2022
  InstallationDate: Installed on 2022-03-13 (11 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313)
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04

[Dan Streetman]

> So, maybe the default SwapUsedLimit is not appropriate for Ubuntu

I don't think tweaking that will help much if at all, it's going to be
hard to get around the core issue of oomd counting pagecache as memory
pressure

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

Title:
  applications crash that never crashed under Ubuntu-20.04

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  Just now I was watching some video in Firefox. I popped over to
  another virtual workspace for a few minutes, and when I popped back to
  Firefox it had gone. The same thing had been happening all week (I
  installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and
  Thunderbird.

  This time instead of shrugging it off I looked in the logs, and found
  this

  Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope
 due to memory used (15940579328) / total (16153944064) and swap used 
(925564928) / total (1023406080) being more than 90.00%
  Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: 
systemd-oomd killed 298 process(es) in this unit.
  Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope
 due to memory used (15591993344) / total (16149745664) and swap used 
(927760384) / total (1023406080) being more than 90.00%
  Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: 
systemd-oomd killed 173 process(es) in this unit.

  I know it's saying those three entirely unrelated applications had
  suddenly decided to swallow all the RAM+swap on this laptop of mine -
  but the very same apps didn't act like that last week under
  Ubuntu-20.04, so I suspect something else is going on

  I can't say they hadn't swallowed all the RAM, but there is ZERO sign
  of a system on the verge of collapsing - everything has been screaming
  along just nicely - no sign of the "staggering" you normally get when
  the OS is heavily into swap.

  However, now that I look I see my 16G laptop only has 1G swap??? I
  just let the Ubuntu installer do it's defaults - but it used to auto-
  choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be
  related?

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd-oomd 249.11-0ubuntu1
  ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
  Uname: Linux 5.15.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 25 19:47:44 2022
  InstallationDate: Installed on 2022-03-13 (11 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313)
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04

[Dan Streetman]

wow, looking at the systemd code (even upstream), oomd is counting
pagecache as 'used' memory which is massively unfair as the kernel is
responsible for pagecache use, not userspace, and it's not even accurate
(from a OOM perspective) since the kernel will drop pagecache as memory
pressure increases.

Definitely some discussion and patching needs to happen upstream in
systemd I think.

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

Title:
  applications crash that never crashed under Ubuntu-20.04

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  Just now I was watching some video in Firefox. I popped over to
  another virtual workspace for a few minutes, and when I popped back to
  Firefox it had gone. The same thing had been happening all week (I
  installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and
  Thunderbird.

  This time instead of shrugging it off I looked in the logs, and found
  this

  Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope
 due to memory used (15940579328) / total (16153944064) and swap used 
(925564928) / total (1023406080) being more than 90.00%
  Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: 
systemd-oomd killed 298 process(es) in this unit.
  Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed 
/user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope
 due to memory used (15591993344) / total (16149745664) and swap used 
(927760384) / total (1023406080) being more than 90.00%
  Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: 
systemd-oomd killed 173 process(es) in this unit.

  I know it's saying those three entirely unrelated applications had
  suddenly decided to swallow all the RAM+swap on this laptop of mine -
  but the very same apps didn't act like that last week under
  Ubuntu-20.04, so I suspect something else is going on

  I can't say they hadn't swallowed all the RAM, but there is ZERO sign
  of a system on the verge of collapsing - everything has been screaming
  along just nicely - no sign of the "staggering" you normally get when
  the OS is heavily into swap.

  However, now that I look I see my 16G laptop only has 1G swap??? I
  just let the Ubuntu installer do it's defaults - but it used to auto-
  choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be
  related?

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: systemd-oomd 249.11-0ubuntu1
  ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
  Uname: Linux 5.15.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 25 19:47:44 2022
  InstallationDate: Installed on 2022-03-13 (11 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313)
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1965180] Re: apt-add-repository requires --login for private repos, breaking automated workflows

[Dan Streetman]

** Merge proposal linked:
   
https://code.launchpad.net/~ddstreet/software-properties/+git/software-properties/+merge/417981

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

Title:
  apt-add-repository requires --login for private repos, breaking
  automated workflows

Status in software-properties package in Ubuntu:
  New
Status in software-properties source package in Jammy:
  New

Bug description:
  On Focal, in an automated environment (such as a launchpad builder), a
  used can do the following workflow:

  curl
  "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x${FINGERPRINT}";
  --output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

  apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
  ppa.launchpad.net/${REPO}/ubuntu focal main"

  Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
  Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  Hit:3 http://archive.ubuntu.com/ubuntu focal-backports InRelease
  Hit:4 http://security.ubuntu.com/ubuntu focal-security InRelease
  Get:5 https://private-ppa.launchpad.net/$REPO/ubuntu focal InRelease [24.3 kB]
  Get:6 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main amd64 
Packages [3288 B] 
  Get:7 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main 
Translation-en [1892 B]  

  However, on Jammy, I get the following:

  
  curl "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x${FINGERPRINT}"; 
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

  apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
  ppa.launchpad.net/${REPO}/ubuntu jammy main"

  Repository: 'deb https://private-ppa.launchpad.net/$REPO/ubuntu jammy main'
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 105, 
in lpppa
  self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line 
592, in __call__
  response, content = self.root._browser._request(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line 
429, in _request
  raise error
  lazr.restfulclient.errors.NotFound: HTTP Error 404: Not Found
  Response headers:
  ---
  -content-encoding: gzip
  content-length: 91
  content-type: text/plain;charset=utf-8
  date: Wed, 16 Mar 2022 19:54:16 GMT
  server: gunicorn/19.8.1
  status: 404
  vary: Accept-Encoding
  x-powered-by: Zope (www.zope.org), Python (www.python.org)
  x-request-id: ec4bd7ff-f333-4543-ba91-3b7b063fab0e
  x-vcs-revision: 81acd06336f3c4be8f28a2213f7a64912593402d
  ---
  Response body:
  ---
  b"Object: , 
name: '$REPO'"
  ---

  
  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 364, in 
  sys.exit(0 if addaptrepo.main() else 1)
File "/usr/bin/apt-add-repository", line 352, in main
  self.prompt_user_shortcut(shortcut)
File "/usr/bin/apt-add-repository", line 140, in prompt_user_shortcut
  if shortcut.description:
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 117, 
in description
  return self.lpppa.description
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 109, 
in lpppa
  raise ShortcutException(msg)
  softwareproperties.shortcuthandler.ShortcutException: ERROR: ppa 
'$REPO/proposed' not found (use --login if private)

  Impish similarly breaks. Digging through changelogs, I see various
  entries in Impish forward, starting with version 0.99.0 where a
  refactor was done.

  using `--login` is not possible in an automated setup (such as a
  builder) as it starts an OAuth dance, which requires human
  interaction. this will break existing automation utilizing apt-add-
  repository for users when migrating to Jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1965180/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

uploaded to bionic queue, thanks!

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

If you'd rather remove the opt-in part, that's fine with me; I can
sponsor the debdiff then with the opt-in parts left out, if that works
for you Bruce and Nicolas.

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

@ubuntu-security since this is openssl, could you give the debdiff a
review? I can sponsor it as a normal SRU if you have no objections (and
the changes look ok to you), as it doesn't really seem like it would
specifically need to go to the -security pocket.

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

> It's not needed for actual functionality of the backport but that
assumes that any future backports or fixes don't break this backport

yes i get that, my comment is about whether or not the patch changes any
code *outside* of the self-tests, e.g. the TLSProxy perl code changes.
If that's *only* used for self-tests then including in the backport
shouldn't cause any regression.

Remember that people reviewing/sponsoring patches may not have deep
experience with the code so it's good to more clearly explain things
that aren't necessarily obvious, such as the 2nd patch only affecting
test code (if that is indeed the case), since at first glance that isn't
what it looks like.

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

The 2nd upstream patch appears to add new functionality, for actually
parsing a certificate request; is that actually needed (outside of the
self-tests)? If not, it shouldn't be included in the backport.

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted

[Dan Streetman]

> I have update ongoing on esm-infa-staging for it

just to clarify, if the systemd patch isn't added to the actual main
(currently closed) xenial-updates repo, it won't be very much help to
anyone wanting to create new xenial containers on jammy. So, just
patching systemd in the esm repo likely is not enough - especially if
the prebuilt LXD container images don't pick up the ESM version of
systemd.

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

Title:
  xenial systemd fails to start if cgroup2 is mounted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  [impact]

  now that jammy has moved to using unified cgroup2, containers started
  on jammy must also use unified cgroup2 (since the cgroup subsystems
  can only be mounted as v1 or v2 throughout the entire system,
  including inside containers).

  However, the systemd in xenial does not include support for cgroup2,
  and doesn't recognize its magic (added in upstream commit
  099619957a0), so it fails to start completely.

  [workaround]
  On Jammy host edit default kernel command line to include

  systemd.unified_cgroup_hierarchy=false

  update your bootloader configuration; and reboot

  then hybrid cgroups will be on the host, and one can launch xenial
  container then.

  
  [test case]

  create a jammy system, that has unified cgroup2 mounted. Then:

  $ lxc launch ubuntu:xenial test-x
  ...
  $ lxc shell test-x

  (inside xenial container):
  $ mv /sbin/init /sbin/init.old
  $ cat > /sbin/init <+a q
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!] Failed to mount API filesystems, freezing.
  Freezing execution.

  [regression potential]

  any regression would likely break xenial containers from starting at
  all, or cause cgroup-related problems with systemd starting and/or
  managing services.

  [scope]

  this is needed only for xenial. However, as xenial is out of standard
  support, this would need to be an exception.

  this is fixed upstream with commit 099619957a0 (and possibly others -
  needs closer investigation and testing) which is first included in
  v230, so this is fixed already in b and later.

  this is not needed - by default - for trusty because upstart is used
  there; however, I think it's possible to change trusty over to use
  systemd instead of upstart. But since trusty is out of standard
  support, and it doesn't fail by default, it doesn't seem like it
  should be fixed.

  [other info]

  An alternative appears to be to change the host system back to using
  the 'hybrid' cgroup, however that obviously is awful and would remove
  the benefits of cgroup v2 from the host system, and force all
  containers on the host system to also use the 'hybrid' cgroup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1964494] Re: Setting DuplicateAddressDetection=none doesn't disable DAD for link-local IPs

[Dan Streetman]

> I think this commit [1] may be related (landed in systemd v249)

yeah, that commit seems to be intentionally forcing ACD on for
statically configured ipv4, i'm not sure quite why, it seems like a
user-configured setting should be honored; but possibly Yu was trying to
default it to on instead of overriding user config.

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

Title:
  Setting DuplicateAddressDetection=none doesn't disable DAD for link-
  local IPs

Status in systemd package in Ubuntu:
  New

Bug description:
  A customer reported network disconnections on their storage 
  servers when running 'netplan apply'. The culprit was that
  they have link-local addresses configured and the Duplicate 
  Address Detection (DAD) mechanism was delaying the interfaces 
  from coming back up. 

  As a workaround we tried to disable DAD for the interfaces 
  but that's not working in Ubuntu 22.04:

  I've noticed that setting DuplicateAddressDetection=none for an
  interface with a link-local address (e.g., 169.254.*) via a 
  .network file added to /etc/systemd/network/ doesn't really 
  disable Duplicate Address Detection.

  OS and package versions:
  
   - Description:   Ubuntu Jammy Jellyfish (development branch). Release: 
22.04
   - systemd 249.5-2ubuntu4

  Reproducer:
  ---
  1- Set up Ubuntu 22.04 VM
  2- Increase systemlog level:

mkdir -p /etc/systemd/system/systemd-networkd.service.d/
cat > /etc/systemd/system/systemd-networkd.service.d/10-debug.conf 

[Touch-packages] [Bug 1962038] Re: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf

[Dan Streetman]

> systemd should drop its setting to defer to the file that we have been
carrying in procps for a very long time.

at some point it would be a better idea to drop the procps files and
adjust the systemd defaults where/if needed. The sysctl configuration
hasn't been applied by procps since upstart; with systemd, the systemd-
sysctl service is what applies all the sysctl settings.

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

Title:
  wrong sysrq value in /usr/lib/sysctl.d/50-default.conf

Status in procps package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Triaged
Status in procps source package in Impish:
  Won't Fix
Status in systemd source package in Impish:
  New
Status in procps source package in Jammy:
  New
Status in systemd source package in Jammy:
  Triaged

Bug description:
  [Impact]

  I've just learned that systemd is setting kernel.sysrq to 16 in
  /usr/lib/sysctl.d/50-default.conf.  This is inconsistent with
  /etc/sysctl.d/10-magic-sysrq.conf which intentionally sets it to 176
  by default.  systemd should drop its setting to defer to the file that
  we have been carrying in procps for a very long time.

  Therefore, users can only sync their storage but not do any other
  actions using the magic sysrq key.

  [Test Plan]

  $ sysctl kernel.sysrq
  => This should show "kernel.sysrq = 176" as set by 
/etc/sysctl.d/10-magic-sysrq.conf
  $ sysctl net.ipv4.conf.all.rp_filter
  => This should show "net.ipv4.conf.all.rp_filter=2" as set by 
/etc/sysctl.d/10-network-security.conf

  [Where problems could occur]

   * This patch changes systemd's sysctl configuration in /lib/sysctl.d/*.conf
   * If something is broken it could fail to apply any of systemd's sysctl 
configuration, but Ubuntu's defaults from /etc/sysctl.d/*.conf would still be 
in place.

  [Other Info]
   
   * None

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1962038/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted

[Dan Streetman]

> "so this is fixed already in f and later" - think you mean "b and
later" here?

yes sorry, fixed in b and later

** Description changed:

  [impact]
  
  now that jammy has moved to using unified cgroup2, containers started on
  jammy must also use unified cgroup2 (since the cgroup subsystems can
  only be mounted as v1 or v2 throughout the entire system, including
  inside containers).
  
  However, the systemd in xenial does not include support for cgroup2, and
  doesn't recognize its magic (added in upstream commit 099619957a0), so
  it fails to start completely.
  
  [test case]
  
  create a jammy system, that has unified cgroup2 mounted. Then:
  
  $ lxc launch ubuntu:xenial test-x
  ...
  $ lxc shell test-x
  
  (inside xenial container):
  $ mv /sbin/init /sbin/init.old
  $ cat > /sbin/init <+a q
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!] Failed to mount API filesystems, freezing.
  Freezing execution.
  
  [regression potential]
  
  any regression would likely break xenial containers from starting at
  all, or cause cgroup-related problems with systemd starting and/or
  managing services.
  
  [scope]
  
  this is needed only for xenial. However, as xenial is out of standard
  support, this would need to be an exception.
  
  this is fixed upstream with commit 099619957a0 (and possibly others -
  needs closer investigation and testing) which is first included in v230,
- so this is fixed already in f and later.
+ so this is fixed already in b and later.
  
  this is not needed - by default - for trusty because upstart is used
  there; however, I think it's possible to change trusty over to use
  systemd instead of upstart. But since trusty is out of standard support,
  and it doesn't fail by default, it doesn't seem like it should be fixed.
  
  [other info]
  
  An alternative appears to be to change the host system back to using the
  'hybrid' cgroup, however that obviously is awful and would remove the
  benefits of cgroup v2 from the host system, and force all containers on
  the host system to also use the 'hybrid' cgroup.

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

Title:
  xenial systemd fails to start if cgroup2 is mounted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  [impact]

  now that jammy has moved to using unified cgroup2, containers started
  on jammy must also use unified cgroup2 (since the cgroup subsystems
  can only be mounted as v1 or v2 throughout the entire system,
  including inside containers).

  However, the systemd in xenial does not include support for cgroup2,
  and doesn't recognize its magic (added in upstream commit
  099619957a0), so it fails to start completely.

  [test case]

  create a jammy system, that has unified cgroup2 mounted. Then:

  $ lxc launch ubuntu:xenial test-x
  ...
  $ lxc shell test-x

  (inside xenial container):
  $ mv /sbin/init /sbin/init.old
  $ cat > /sbin/init <+a q
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!] Failed to mount API filesystems, freezing.
  Freezing execution.

  [regression potential]

  any regression would likely break xenial containers from starting at
  all, or cause cgroup-related problems with systemd starting and/or
  managing services.

  [scope]

  this is needed only for xenial. However, as xenial is out of standard
  support, this would need to be an exception.

  this is fixed upstream with commit 099619957a0 (and possibly others -
  needs closer investigation and testing) which is first included in
  v230, so this is fixed already in b and later.

  this is not needed - by default - for trusty because upstart is used
  there; however, I think it's possible to change trusty over to use
  systemd instead of upstart. But since trusty is out of standard
  support, and it doesn't fail by default, it doesn't seem like it
  should be fixed.

  [other info]

  An alternative appears to be to change the host system back to using
  the 'hybrid' cgroup, however that obviously is awful and would remove
  the benefits of cgroup v2 from the host system, and force all
  containers on the host system to also use the 'hybrid' cgroup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1962332] [NEW] xenial systemd fails to start if cgroup2 is mounted

[Dan Streetman]

Public bug reported:

[impact]

now that jammy has moved to using unified cgroup2, containers started on
jammy must also use unified cgroup2 (since the cgroup subsystems can
only be mounted as v1 or v2 throughout the entire system, including
inside containers).

However, the systemd in xenial does not include support for cgroup2, and
doesn't recognize its magic (added in upstream commit 099619957a0), so
it fails to start completely.

[test case]

create a jammy system, that has unified cgroup2 mounted. Then:

$ lxc launch ubuntu:xenial test-x
...
$ lxc shell test-x

(inside xenial container):
$ mv /sbin/init /sbin/init.old
$ cat > /sbin/init <+a q
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!] Failed to mount API filesystems, freezing.
Freezing execution.

[regression potential]

any regression would likely break xenial containers from starting at
all, or cause cgroup-related problems with systemd starting and/or
managing services.

[scope]

this is needed only for xenial. However, as xenial is out of standard
support, this would need to be an exception.

this is fixed upstream with commit 099619957a0 (and possibly others -
needs closer investigation and testing) which is first included in v230,
so this is fixed already in f and later.

this is not needed - by default - for trusty because upstart is used
there; however, I think it's possible to change trusty over to use
systemd instead of upstart. But since trusty is out of standard support,
and it doesn't fail by default, it doesn't seem like it should be fixed.

[other info]

An alternative appears to be to change the host system back to using the
'hybrid' cgroup, however that obviously is awful and would remove the
benefits of cgroup v2 from the host system, and force all containers on
the host system to also use the 'hybrid' cgroup.

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: Fix Released

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

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

** Changed in: systemd (Ubuntu)
   Status: New => 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/1962332

Title:
  xenial systemd fails to start if cgroup2 is mounted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  New

Bug description:
  [impact]

  now that jammy has moved to using unified cgroup2, containers started
  on jammy must also use unified cgroup2 (since the cgroup subsystems
  can only be mounted as v1 or v2 throughout the entire system,
  including inside containers).

  However, the systemd in xenial does not include support for cgroup2,
  and doesn't recognize its magic (added in upstream commit
  099619957a0), so it fails to start completely.

  [test case]

  create a jammy system, that has unified cgroup2 mounted. Then:

  $ lxc launch ubuntu:xenial test-x
  ...
  $ lxc shell test-x

  (inside xenial container):
  $ mv /sbin/init /sbin/init.old
  $ cat > /sbin/init <+a q
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!] Failed to mount API filesystems, freezing.
  Freezing execution.

  [regression potential]

  any regression would likely break xenial containers from starting at
  all, or cause cgroup-related problems with systemd starting and/or
  managing services.

  [scope]

  this is needed only for xenial. However, as xenial is out of standard
  support, this would need to be an exception.

  this is fixed upstream with commit 099619957a0 (and possibly others -
  needs closer investigation and testing) which is first included in
  v230, so this is fixed already in f and later.

  this is not needed - by default - for trusty because upstart is used
  there; however, I think it's possible to change trusty over to use
  systemd instead of upstart. But since trusty is out of standard
  support, and it doesn't fail by default, it doesn't seem like it
  should be fixed.

  [other info]

  An alternative appears to be to change the host system back to using
  the 'hybrid' cgroup, however that obviously is awful and would remove
  the benefits of cgroup v2 from the host system, and force all
  containers on the host system to also use the 'hybrid' cgroup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge

[Dan Streetman]

did you find any alternate way to handle this? If not we should probably
review/merge the 247 naming approach, if @slyon approves

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

Title:
  udev produces unpredictable net names when PCI device is a bridge

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  udev can produce unpredictable network interface names by default when 
multiple devices map to the same slot due to an intermediate bridge. On an 
Nvidia DGX2 system, I see the following when booting a system with udev 
245.4-4ubuntu3.13:

  ubuntu@akis:~$ ls /sys/class/net
  enp134s0f0  enp6s0  ens103  ens107  eth3  eth9
  enp134s0f1  ens102  ens106  eth1eth7  lo

  For each ens* device, there is a sibling eth* device that maps to the
  same slot because both devices are behind the same bridge.

  Unpredictable names present well known problems, but I'll describe a
  specific issue I'm having. We currently do automated network testing
  that MAAS deploys a system and then configures 2 specific NICs on the
  system. While MAAS does take care to always restore the names used
  during commissioning (eth3 will always be the same NIC on every
  deploy), these names can change each time the system is commissioned.
  So today we need to go in and edit the NIC names manually in MAAS any
  time the system is re-commissioned.

  [Test Case]
  Boot with kernel option net.naming-scheme=v247; verify that all network 
interfaces receive predictable names.

  [Fix]
  This issue was addressed upstream by adding a new v247 naming scheme that 
detects this scenario and disables usage of slot-based names for these devices. 
Obviously changing the default naming scheme in a released LTS series could 
break users. However, we could introduce the v247 scheme in a focal SRU, and 
keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users 
impacted by this could then opt-in to the v247 scheme by passing 
net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. 
I could add this to DGX2 systems via a kernel_opts MAAS tag to always get 
predictable names during commissioning.

  [Regression Risk]
  This would change the behavior of any users who select 
net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm 
not sure why an existing Ubuntu user would be doing that though - AFAICT, 
Ubuntu currently always defaults to the latest scheme.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1950508] Re: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup

[Dan Streetman]

** Changed in: systemd (Ubuntu Impish)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Impish)
   Status: In Progress => 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/1950508

Title:
  unified cgroup incorrectly used in container on host with
  legacy/hybrid cgroup

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [impact]

  after systemd was changed to default to cgroupv2, any container
  started on a host that still uses legacy or hybrid cgroup mounts will
  result in a container that attempts to use unified cgroup but can't
  due to all the controllers being used as v1 in the host kernel.

  [test case]

  TBD

  [regression potential]

  container, or vm or bare metal, that incorrectly uses cgroupv1, or
  incorrect use of cgroupv2.

  [scope]

  needed only for i and later

  f and earlier default to cgroupv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950508/+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 1934147] Re: systemd leaks abandoned session scopes

[Dan Streetman]

per comment 5, released for impish

** Changed in: systemd (Ubuntu Impish)
   Status: Fix Committed => Fix Released

** Changed in: systemd (Ubuntu)
   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/1934147

Title:
  systemd leaks abandoned session scopes

Status in snapd:
  Invalid
Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in systemd source package in Groovy:
  Won't Fix
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [impact]

  systemd may leak sessions, leaving empty cgroups around as well as
  abandoned session scopes.

  [test case]

  on a system where the user has a ssh key that allows noninteractive
  login to localhost, and also has noninteractive sudo, run:

  $ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
  done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
  reload; done

  check the sessions to see there have been leaked sessions:

  $ loginctl list-sessions

  SESSION  UID USER   SEAT TTY
1 1000 ubuntu  ttyS0
  350 1000 ubuntu  
  351 1000 ubuntu  
  360 1000 ubuntu  
  ...

  to verify the sessions were leaked, clear them out with:

  $ echo '' | sudo tee
  
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events

  that should result in all the leaked sessions being cleaned up.

  [regression potential]

  issues during systemd pid1 reexec/reload, or issues while cleaning up
  sessions, including leaking sessions/cgroups

  [scope]

  this is needed for all releases

  upstream bug linked above, and upstream PR:
  https://github.com/systemd/systemd/pull/20199

  [original description]

  On a system that is monitored via telegraf I found many abandoned
  systemd session which I believe are created by a potential race where
  systemd is reloading unit files and at the same time a user is
  connecting to the system via ssh or is executing the su command.

  The simple reproducer

  $ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
  daemon-reload & ssh localhost sleep 1 & done

  Wait > 1 second

  $ jobs -p | xargs --verbose --no-run-if-empty kill -KILL

  To clean out STOPPED jobs and

  $ systemctl status --all 2> /dev/null | grep --before-context 3
  abandoned

  will produce something similar to

     │ ├─  175 su - ubuntu
     │ ├─  178 -su
     │ ├─62375 systemctl status --all
     │ └─62376 grep --color=auto --before-context 3 abandoned
  --
  ● session-273.scope - Session 273 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
  --
  ● session-274.scope - Session 274 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
  --
  ● session-30.scope - Session 30 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
  --
  ● session-302.scope - Session 302 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
  --
     │ ├─  175 su - ubuntu
     │ ├─  178 -su
     │ ├─62375 systemctl status --all
     │ └─62376 grep --color=auto --before-context 3 abandoned

  The system in question is running Bionic, systemd-237-3ubuntu10.48

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log

[Dan Streetman]

I think we should ignore hirsute since it reaches EOL next week.

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

Title:
  attempt to dlopen nonexistent pam_kwallet.so spams log

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Bionic:
  New
Status in lightdm source package in Focal:
  Fix Committed
Status in lightdm source package in Hirsute:
  Fix Committed
Status in lightdm source package in Impish:
  Fix Committed
Status in lightdm source package in Jammy:
  Fix Released

Bug description:
  [impact]

  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.

  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so

  [test case]

  install/enable lightdm and check system log at boot for messages like:

  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

  [regression potential]

  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.

  [scope]

  this is needed in all releases

  [other info]

  https://github.com/canonical/lightdm/pull/216

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log

[Dan Streetman]

ubuntu@lp1949970-f:~$ dpkg -l lightdm|grep lightdm
ii  lightdm1.30.0-0ubuntu4~20.04.1 amd64Display Manager
ubuntu@lp1949970-f:~$ journalctl -b -g 'unable to dlopen'
-- Logs begin at Tue 2022-01-11 17:28:51 UTC, end at Tue 2022-01-11 18:02:33 
UTC. --
Jan 11 17:58:09 lp1949970-f lightdm[1048]: PAM unable to 
dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object 
file: No such file or directory
Jan 11 17:58:09 lp1949970-f lightdm[1048]: PAM unable to 
dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared 
object file: No such file or directory
Jan 11 17:58:11 lp1949970-f lightdm[1278]: PAM unable to 
dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object 
file: No such file or directory
Jan 11 17:58:11 lp1949970-f lightdm[1278]: PAM unable to 
dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared 
object file: No such file or directory

...(upgrade and reboot)...

ubuntu@lp1949970-f:~$ dpkg -l lightdm|grep lightdm
ii  lightdm1.30.0-0ubuntu4~20.04.2 amd64Display Manager
ubuntu@lp1949970-f:~$ journalctl -b -g 'unable to dlopen'
-- Logs begin at Tue 2022-01-11 17:28:51 UTC, end at Tue 2022-01-11 18:03:41 
UTC. --
-- No entries --


** Tags removed: verification-needed verification-needed-focal 
verification-needed-impish
** Tags added: verification-done verification-done-focal 
verification-done-impish

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

Title:
  attempt to dlopen nonexistent pam_kwallet.so spams log

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Bionic:
  New
Status in lightdm source package in Focal:
  Fix Committed
Status in lightdm source package in Hirsute:
  Fix Committed
Status in lightdm source package in Impish:
  Fix Committed
Status in lightdm source package in Jammy:
  Fix Released

Bug description:
  [impact]

  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.

  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so

  [test case]

  install/enable lightdm and check system log at boot for messages like:

  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

  [regression potential]

  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.

  [scope]

  this is needed in all releases

  [other info]

  https://github.com/canonical/lightdm/pull/216

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log

[Dan Streetman]

ubuntu@lp1949970-i:~$ dpkg -l lightdm|grep lightdm
ii  lightdm  1.30.0-0ubuntu4
amd64Display Manager
ubuntu@lp1949970-i:~$ journalctl -b -g 'unable to dlopen'
-- Journal begins at Tue 2022-01-11 17:28:57 UTC, ends at Tue 2022-01-11 
17:59:05 UTC. --
Jan 11 17:58:14 lp1949970-i lightdm[939]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
Jan 11 17:58:14 lp1949970-i lightdm[939]: PAM unable to 
dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared 
object file: No such file or directory
Jan 11 17:58:16 lp1949970-i lightdm[1083]: PAM unable to 
dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object 
file: No such file or directory
Jan 11 17:58:16 lp1949970-i lightdm[1083]: PAM unable to 
dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared 
object file: No such file or directory


...(upgrade and reboot)...

ubuntu@lp1949970-i:~$ dpkg -l lightdm|grep lightdm
ii  lightdm1.30.0-0ubuntu4.21.10.1 amd64Display Manager
ubuntu@lp1949970-i:~$ journalctl -b -g 'unable to dlopen'
-- Journal begins at Tue 2022-01-11 17:28:57 UTC, ends at Tue 2022-01-11 
18:01:00 UTC. --
-- No entries --

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

Title:
  attempt to dlopen nonexistent pam_kwallet.so spams log

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Bionic:
  New
Status in lightdm source package in Focal:
  Fix Committed
Status in lightdm source package in Hirsute:
  Fix Committed
Status in lightdm source package in Impish:
  Fix Committed
Status in lightdm source package in Jammy:
  Fix Released

Bug description:
  [impact]

  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.

  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so

  [test case]

  install/enable lightdm and check system log at boot for messages like:

  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

  [regression potential]

  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.

  [scope]

  this is needed in all releases

  [other info]

  https://github.com/canonical/lightdm/pull/216

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1950496] Re: networkd doesn't provide DNS to nspawn containers

[Dan Streetman]

Also for future reference I think upstream commit
fb3aec45a0de7f71aa6418bd4f9d5f314efb4eb5 fixes this, but I never got a
chance to test it before upgrading.

** Changed in: systemd (Ubuntu Focal)
   Status: New => Incomplete

** Changed in: systemd (Ubuntu)
   Status: New => 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/1950496

Title:
  networkd doesn't provide DNS to nspawn containers

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Incomplete

Bug description:
  [impact]

  the host networkd doesn't include DNS info to nspawn containers

  [test case]

  create/start a nspawn container, e.g. with 'machinectl start', open a
  shell in the container, and check resolvectl to see if a nameserver
  was provided.

  [regression potential]

  failures in the host networkd, possibly affecting other host
  interfaces which are controlled by networkd, or (more likely) failure
  to provide dhcp to nspawn containers

  [scope]

  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950496/+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 1950496] Re: networkd doesn't provide DNS to nspawn containers

[Dan Streetman]

I was able to reproduce this when my bare metal system was running
focal, but I since have upgraded to impish and now i can't reproduce
this problem in a focal VM, so probably there is some specific network
setup required to reproduce (that I have on my bare metal system but not
in a VM); since it's no longer a problem for me as I've upgraded to
impish, I'm dropping ownership of this, but if anyone else has this
problem (i.e. can reproduce it) please reopen the bug and/or add a
comment.

** Changed in: systemd (Ubuntu Focal)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: systemd (Ubuntu Focal)
   Importance: Medium => Low

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => 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/1950496

Title:
  networkd doesn't provide DNS to nspawn containers

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Incomplete

Bug description:
  [impact]

  the host networkd doesn't include DNS info to nspawn containers

  [test case]

  create/start a nspawn container, e.g. with 'machinectl start', open a
  shell in the container, and check resolvectl to see if a nameserver
  was provided.

  [regression potential]

  failures in the host networkd, possibly affecting other host
  interfaces which are controlled by networkd, or (more likely) failure
  to provide dhcp to nspawn containers

  [scope]

  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950496/+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 1946388] Re: Journalctl -f --file some.journal causes coredump

[Dan Streetman]

** Changed in: systemd (Ubuntu Focal)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Focal)
   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/1946388

Title:
  Journalctl -f --file some.journal causes coredump

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress

Bug description:
  [impact]

  journalctl -f --file FILE results in segfault

  [test case]

  $ journalctl -f --file $FILENAME

  [regression potential]

  journalctl segfault or failure to properly operate

  [scope]

  needed in focal

  fixed upstream in 2b6df46d21a at v246, so fixed already in h and later

  [original description]

  Focal latest systemd 245.

  Journalctl -f --file path/to/file.journal.  Will allways causes
  journalctl crash...

  The same doesnt happen on centos8 systemd 239... I couldnt test on any
  more systems atm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1946388/+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 1946388] Re: Journalctl -f --file some.journal causes coredump

[Dan Streetman]

** Bug watch added: github.com/systemd/systemd/issues #15528
   https://github.com/systemd/systemd/issues/15528

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/15528
   Importance: Unknown
   Status: Unknown

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

** Changed in: systemd (Ubuntu)
   Status: New => Fix Released

** Description changed:

+ [impact]
+ 
+ journalctl -f --file FILE results in segfault
+ 
+ [test case]
+ 
+ $ journalctl -f --file $FILENAME
+ 
+ [regression potential]
+ 
+ journalctl segfault or failure to properly operate
+ 
+ [scope]
+ 
+ needed in focal
+ 
+ fixed upstream in 2b6df46d21a at v246, so fixed already in h and later
+ 
+ [original description]
+ 
  Focal latest systemd 245.
  
  Journalctl -f --file path/to/file.journal.  Will allways causes
  journalctl crash...
  
  The same doesnt happen on centos8 systemd 239... I couldnt test on any
  more systems atm.

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

Title:
  Journalctl -f --file some.journal causes coredump

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  New

Bug description:
  [impact]

  journalctl -f --file FILE results in segfault

  [test case]

  $ journalctl -f --file $FILENAME

  [regression potential]

  journalctl segfault or failure to properly operate

  [scope]

  needed in focal

  fixed upstream in 2b6df46d21a at v246, so fixed already in h and later

  [original description]

  Focal latest systemd 245.

  Journalctl -f --file path/to/file.journal.  Will allways causes
  journalctl crash...

  The same doesnt happen on centos8 systemd 239... I couldnt test on any
  more systems atm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1946388/+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 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers

[Dan Streetman]

> Reverting this upstream commit seems to fix the problem: 
> https://github.com/systemd/systemd/commit/0299deab53d2a087727a5d04c1500c322c48b63e

lxd and systemd have what I can only describe euphemistically as a
horrible relationship. Instead of carrying another patch on systemd to
get it working in lxd, could you try to work this out correctly, either
by convincing upstream systemd to change or convincing lxd to change?

Long term, it does Ubuntu no favors by hacking up systemd because lxd doesn't 
conform to the systemd container interface.
https://systemd.io/CONTAINER_INTERFACE/

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

Title:
  DHCPv4 (IAID+DUID) networking broken in LXC containers

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  DHCPv4 networking does not work in the default IAID+DUID
  (ClientIdentifier=duid) mode in LXC containers, using systemd-networkd
  v249.5-2ubuntu1. Static configuration and DHCPv6 work without problem.

  Reproducer:
  $ lxc launch ubuntu-daily:jammy jj
  $ lxc exec jj bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # cat /etc/systemd/network/00-test.network
  [Match]
  Name=eth0

  [Network]
  DHCP=ipv4
  # systemctl restart systemd-networkd.service
  # networkctl 
  IDX LINK TYPE OPERATIONAL SETUP
  [...]
  611 eth0 ethercarrier failed  

  A workaround is to avoid IAID+DUID mode via:
  [DHCPv4]
  #ClientIdentifier=mac
  ClientIdentifier=duid-only

  Interesting logs:
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Requested to activate link
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCPv4 client: Failed to set 
IAID: Device or resource busy
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCP4 CLIENT: Failed to set 
IAID+DUID: Device or resource busy
  Nov 12 14:10:48 jj systemd-networkd[174]: Failed to check link is 
initialized: Device or resource busy
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+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 1950520] Re: systemd-resolved delivers SOA information when it should not

[Dan Streetman]

> Is there a ppa with a more recent systemd-resolved to try on focal

yes, https://launchpad.net/~ubuntu-support-team/+archive/ubuntu/systemd

however that includes the entire upstream systemd code, not only
systemd-resolved; i'd suggest you test inside a VM and not on your main
system.

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

Title:
  systemd-resolved delivers SOA information when it should not

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I have a setup where a host (say A) in the network runs knot-resolver
  as a caching nameserver.

  Among the other hosts, some of them run ubuntu 20.04 and use systemd-
  resolved. The dhcp setup make all these host use A as their
  nameserver.

  The issue with systemd-

  The issue is that if I do:

  host -t SOA foo.local

  the hosts running systemd-resolved answer

  foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800
  10800

  making up the SOA record from nowhere (sort of).  In fact, if I do the
  same query pointing directly at A

  host -t SOA foo.local 

  I correctly get no SOA record.

  
  

  The incorrect response of resolved breaks mDNS resolution. In fact, if
  nsswitch.conf is set at

  hosts:  files mdns4_minimal [NOTFOUND=return] dns

  any call requiring name resolution first goes through the hosts files,
  then mdns is attempted. However, the nss mdnd implementation first
  checks if the DNS server responds to SOA queries for the top level
  local name and if this is the case, it gives up. As a consequence,
  trying to access hosts on the .local domain always fail.

  
  The reason why systemd-resolved makes up a SOA record for hosts such as 
foo.local is that knot resolver replies to queries about it without an answer, 
but including an authority section

  ;; AUTHORITY SECTION:
  foo.local. 10800   IN  SOA foo.local. nobody.invalid. 1 3600 1200 
604800 10800

  ;; ADDITIONAL SECTION:
  explanation.invalid.10800   IN  TXT "Blocking is mandated by 
standards, see references on 
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml";

  and systemd-resolved turns that AUTHORITY section into a SOA record.
   
  It is not totally clear to me if the fault is on knot-resolver, 
systemd-resolved or both, but I tend to think it is the second one.

  Unfortunately, trying to inquire upstream about systemd-resolved
  appears to be forbidden for anybody not running the last two releases
  of systemd.  Furthermore, I understand that the nature of systemd
  makes it extra hard or impossible to test a more recent version of
  systemd-resolved than the one shipped in ubuntu focal.

  Interestingly, the issue seems to bite those running omnia turris
  router too (see https://forum.turris.cz/t/avahi-local-domain-warning-
  on-ubuntu/13437).  Maybe they use knot-resolver as their caching
  nameserver.

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

[Dan Streetman]

> It's not something that snapd writes out, it's curious where this
comes from

it's not written out, it's internally handled/added by pid1, and it
*should* be there, because you do want (for example) the mount to be
stopped if its backing device is removed. However when the mount is
stopped, the BindsTo should be removed (internally, by pid1). So there's
some problem with non-core bionic systemd that isn't correctly adding
the relation at all, and some problem with core bionic systemd that
isn't properly removing the relation when the mount is stopped

-- 
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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

[Dan Streetman]

Sorry to clarify that, the dep is added to the mount over a daemon-
reload, but only on core:

ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─-.mount
● ├─snap.mount
● ├─system.slice
● └─var-lib-snapd.mount
ddstreet@localhost:~$ systemctl list-dependencies --reverse 
snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● └─multi-user.target
●   └─graphical.target
ddstreet@localhost:~$ sudo systemctl daemon-reload 
ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─-.mount
● ├─dev-loop2.device
● ├─snap.mount
● ├─system.slice
● └─var-lib-snapd.mount
ddstreet@localhost:~$ systemctl list-dependencies --reverse 
snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─dev-loop2.device
● └─multi-user.target
●   └─graphical.target


ubuntu@test-b-full:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─-.mount
● └─system.slice
ubuntu@test-b-full:~$ systemctl list-dependencies --reverse 
snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● └─multi-user.target
●   └─graphical.target
ubuntu@test-b-full:~$ sudo systemctl daemon-reload 
ubuntu@test-b-full:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─-.mount
● └─system.slice
ubuntu@test-b-full:~$ systemctl list-dependencies --reverse 
snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● └─multi-user.target
●   └─graphical.target

-- 
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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

[Dan Streetman]

This added BindsTo is what's causing the problem:

ddstreet@localhost:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount 
BindsTo=
ddstreet@localhost:~$ sudo systemctl daemon-reload 
ddstreet@localhost:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount 
BindsTo=dev-loop6.device

ubuntu@test-b-full:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount 
BindsTo=
ubuntu@test-b-full:~$ sudo systemctl daemon-reload 
ubuntu@test-b-full:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount 
BindsTo=

Once the mount unit BindsTo= the loop device, systemd won't start the
mount unit (which actually runs 'mount') until the loop device is
'started' but of course the loop device won't ever be started until
'mount' is called.

-- 
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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

[Dan Streetman]

Note one interesting point is that in a core18 system, a squashfs mount
(any loop-based mount, really) includes a dep from the mount to its loop
device, while the non-core system does not:

ddstreet@localhost:~$ cat /etc/issue
Ubuntu Core 18 on \4 (\l)

ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─-.mount
● ├─dev-loop3.device
● ├─snap.mount
● ├─system.slice
● └─var-lib-snapd.mount
ddstreet@localhost:~$ systemctl list-dependencies --reverse 
snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─dev-loop3.device
● └─multi-user.target
●   └─graphical.target


ubuntu@test-b-full:~$ cat /etc/issue
Ubuntu 18.04.6 LTS \n \l

ubuntu@test-b-full:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● ├─-.mount
● └─system.slice
ubuntu@test-b-full:~$ systemctl list-dependencies --reverse 
snap-hello\\x2dworld-29.mount 
snap-hello\x2dworld-29.mount
● └─multi-user.target
●   └─graphical.target

-- 
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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

[Dan Streetman]

> @slyon you might want to see if commit
918e6f1c0151429f5095355f4f3f74f16e79724a fixes this

(and there are a couple follow on commits to this)

-- 
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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

[Dan Streetman]

@slyon you might want to see if commit
918e6f1c0151429f5095355f4f3f74f16e79724a fixes this

-- 
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 1591490] Re: Please backport apt 1.0.9.2ubuntu2 from utopic (to fix do-release-upgrade)

[Dan Streetman]

** Changed in: trusty-backports
   Status: New => Won't Fix

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

Title:
  Please backport apt 1.0.9.2ubuntu2 from utopic (to fix do-release-
  upgrade)

Status in trusty-backports:
  Won't Fix
Status in apt package in Ubuntu:
  Confirmed

Bug description:
  For me (and apparently many others), upgrading Ubuntu Trusty LTS to
  Ubuntu Xenial LTS fails because do-release-upgrade bails out because
  of apt error messages like this:

  
  Unknown Multi-Arch type 'no' for package 'kwin'
  Unknown Multi-Arch type 'no' for package 'kwin-dev'
  Unknown Multi-Arch type 'no' for package 'kwin-wayland'
  Unknown Multi-Arch type 'no' for package 'kwin-x11'
  Unknown Multi-Arch type 'no' for package 'libkf5sysguard-dev'

  Unknown Multi-Arch type 'no' for package 'compiz-core'
  Unknown Multi-Arch type 'no' for package 'compiz-gnome'
  Unknown Multi-Arch type 'no' for package 'libxapian-dev'

  
  It is caused by Debian bug #759099 [1] fixed in apt 1.0.7. Therefore I'm 
requesting a backport of "apt" to trusty.

  In the title I've suggested 1.0.9 from utopic - a more recent version
  might be fine too but when I tried to build the wily version on my
  local machine it couldn't because the g++ requirement had moved on too
  far.

  
  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759099

To manage notifications about this bug go to:
https://bugs.launchpad.net/trusty-backports/+bug/1591490/+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 1285783] Re: Right panel has a transparent background

[Dan Streetman]

** Changed in: trusty-backports
   Status: New => Won't Fix

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

Title:
  Right panel has a transparent background

Status in trusty-backports:
  Won't Fix
Status in gtk+3.0 package in Ubuntu:
  Fix Released
Status in ubuntu-themes package in Ubuntu:
  Fix Released

Bug description:
  Launching gnome-tweak-tool and choosing a category on the left panel
  makes the right panel transparent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/trusty-backports/+bug/1285783/+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 326217] Re: QT libraries in hardy broken because of backports

[Dan Streetman]

** Changed in: hardy-backports
   Status: Incomplete => Won't Fix

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

Title:
  QT libraries in hardy broken because of backports

Status in Hardy Backports:
  Won't Fix
Status in qt4-x11 package in Ubuntu:
  Invalid

Bug description:
  Binary package hint: libqt4-core

  Hello,

  there is an uncompatibility in the current LTS release Hardy Heron.
  Several packages (like qt4-core, qt4-gui etc) are in 4.3.4 version but
  some others (libqt4-dbg, libqt4-doc...) are backported and in version
  4.4.0.

  And this is big problem. For example I am unable to develop with QT4
  because I need all of the modules (core, bui, dbg, doc, xml, webkit
  etc) and this cannot be done because of dependencies:

  The following packages have unmet dependencies:
libqt4-help: Depends: libqt4-sql (= 4.4.0-1ubuntu5~hardy1) but 
4.3.4-0ubuntu3 is to be installed

  Solution: backport all QT4 libraries (version 4.4.0). Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hardy-backports/+bug/326217/+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 313960] Re: Please update dnsmasq hardy packages to version 2.46

[Dan Streetman]

** Changed in: hardy-backports
   Status: New => Won't Fix

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

Title:
  Please update dnsmasq hardy packages to version 2.46

Status in Hardy Backports:
  Won't Fix
Status in dnsmasq package in Ubuntu:
  Invalid

Bug description:
  Binary package hint: dnsmasq

  Hello,

  Dnsmasq has added support for CNAME directives in the config file starting 
with version 2.46.
  This version is not available in Hardy, while I believe a LTS release should 
deserve this improvement.
  All alternatives require (to my knowledge) heavier configuration and / or 
demand more on resources.
  Switching to bind in order to use CNAME or compiling dnsmasq2.46 from source 
should be considered nontrivial/discourage for the average/beginning user.

  How about relasing a package for v2.46 in backports ?

  Regards,

  Dr. Moe

To manage notifications about this bug go to:
https://bugs.launchpad.net/hardy-backports/+bug/313960/+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 792301] Re: Ericsson F5521gw 3G module for Lenovo not using optimal kernel module

[Dan Streetman]

** Changed in: lucid-backports
   Status: New => Won't Fix

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

Title:
  Ericsson F5521gw 3G module for Lenovo not using optimal kernel module

Status in Lucid Backports:
  Won't Fix
Status in ModemManager:
  Fix Released
Status in modemmanager package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: modemmanager

  The Ericsson F5521gw 3G module should use the usb_ncm kernel module
  (/dev/usb0) for connecting for optimal speed and CPU usage (important
  for HSPA+ connections). Modemmanager needs to be told this for the usb
  ID 0bdb:1911 (currently only 0bdb:190d supported).

  See the attached patch already in current version of modemmanager:

  
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=0b757465ffe6108066d32312ab4e895c372c8f72

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: modemmanager 0.4+git.20110124t203624.00b6cce-2ubuntu1
  ProcVersionSignature: Ubuntu 2.6.38-9.43-generic-pae 2.6.38.4
  Uname: Linux 2.6.38-9-generic-pae i686
  Architecture: i386
  Date: Fri Jun  3 12:41:25 2011
  ProcEnviron:
   LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:en
   PATH=(custom, user)
   LANG=nb_NO.UTF-8
   SHELL=/bin/bash
  SourcePackage: modemmanager
  UpgradeStatus: Upgraded to natty on 2011-04-29 (35 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/lucid-backports/+bug/792301/+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 865907] Re: Please backport tracker to Oneiric

[Dan Streetman]

** Changed in: oneiric-backports
   Status: New => Won't Fix

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

Title:
  Please backport tracker to Oneiric

Status in Oneiric Backports:
  Won't Fix
Status in tracker package in Ubuntu:
  Invalid

Bug description:
  Tracker 0.12 is the latest stable release of GNOME's search engine. It
  is needed for GNOME Documents. I've tested version 12.6-1 by letting
  it index my home directory and I ran some searches. The indexed
  documents showed up in GNOME Documents as they were supposed to.

  Build log: https://launchpadlibrarian.net/81619551/buildlog_ubuntu-
  oneiric-amd64.tracker_0.12.3-1~ppa1_BUILDING.txt.gz

  Tracker 0.12 has been in the GNOME 3 PPA for a month now (since
  October 5). I've been running it on my computer for a month and I've
  not seen a single complaint about it not working.
  
https://launchpad.net/~gnome3-team/+archive/gnome3/+builds?build_text=tracker&build_state=all

To manage notifications about this bug go to:
https://bugs.launchpad.net/oneiric-backports/+bug/865907/+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 1791958] Re: iptables-restore is missing -w option

[Dan Streetman]

Hello,

the backports process has recently been updated, please see the new 
documentation:
https://wiki.ubuntu.com/UbuntuBackports

I'm closing this bug, but please feel free to open a new bug (or reopen
this bug) using the new process, if appropriate.


** Changed in: bionic-backports
   Status: New => Won't Fix

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

Title:
  iptables-restore is missing -w option

Status in Bionic Backports:
  Won't Fix
Status in iptables package in Ubuntu:
  Confirmed

Bug description:
  For CRIU we need to have iptables version 1.6.2 which includes the
  '-w' option in iptables-restore.

  This is a request to update iptables to 1.6.2 in 18.10 and if possible
  backport the necessary changes to 18.04.

  The CRIU project gets right now many bug reports (mostly in the
  combination LXD + CRIU) due to the missing '-w' option in iptables-
  restore. Especially as 18.04 will be around for some time it would be
  good to have iptables-restore available with '-w'.

  This is one example bug report: https://github.com/checkpoint-
  restore/criu/issues/551

  But not only CRIU would benefit from this change. It seems also
  problematic with Kubernetes:
  https://github.com/kubernetes/kubernetes/pull/60978

  So if possible, please update iptables to 1.6.2 (or backport changes)
  to support -w in iptables-restore.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bionic-backports/+bug/1791958/+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 1950511] [NEW] FTBFS due to meson disallowing + for bools

[Dan Streetman]

Public bug reported:

FTBFS with new meson:

../meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]: False>
of type bool does not support the `+` operator.

** Affects: systemd (Ubuntu)
 Importance: High
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: systemd (Ubuntu Jammy)
 Importance: High
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

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

** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Jammy)
   Importance: Medium => High

** Changed in: systemd (Ubuntu Jammy)
   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/1950511

Title:
  FTBFS due to meson disallowing + for bools

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Jammy:
  In Progress

Bug description:
  FTBFS with new meson:

  ../meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]:
  False> of type bool does not support the `+` operator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950511/+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 1950508] Re: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup

[Dan Streetman]

** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Impish)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Impish)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Impish)
   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/1950508

Title:
  unified cgroup incorrectly used in container on host with
  legacy/hybrid cgroup

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Impish:
  In Progress
Status in systemd source package in Jammy:
  In Progress

Bug description:
  [impact]

  after systemd was changed to default to cgroupv2, any container
  started on a host that still uses legacy or hybrid cgroup mounts will
  result in a container that attempts to use unified cgroup but can't
  due to all the controllers being used as v1 in the host kernel.

  [test case]

  TBD

  [regression potential]

  container, or vm or bare metal, that incorrectly uses cgroupv1, or
  incorrect use of cgroupv2.

  [scope]

  needed only for i and later

  f and earlier default to cgroupv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950508/+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 1950508] [NEW] unified cgroup incorrectly used in container on host with legacy/hybrid cgroup

[Dan Streetman]

Public bug reported:

[impact]

after systemd was changed to default to cgroupv2, any container started
on a host that still uses legacy or hybrid cgroup mounts will result in
a container that attempts to use unified cgroup but can't due to all the
controllers being used as v1 in the host kernel.

[test case]

TBD

[regression potential]

container, or vm or bare metal, that incorrectly uses cgroupv1, or
incorrect use of cgroupv2.

[scope]

needed only for i and later

f and earlier default to cgroupv1

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

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

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

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

** Also affects: systemd (Ubuntu Impish)
   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/1950508

Title:
  unified cgroup incorrectly used in container on host with
  legacy/hybrid cgroup

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [impact]

  after systemd was changed to default to cgroupv2, any container
  started on a host that still uses legacy or hybrid cgroup mounts will
  result in a container that attempts to use unified cgroup but can't
  due to all the controllers being used as v1 in the host kernel.

  [test case]

  TBD

  [regression potential]

  container, or vm or bare metal, that incorrectly uses cgroupv1, or
  incorrect use of cgroupv2.

  [scope]

  needed only for i and later

  f and earlier default to cgroupv1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950508/+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 1950496] [NEW] networkd doesn't provide DNS to nspawn containers

[Dan Streetman]

Public bug reported:

[impact]

the host networkd doesn't include DNS info to nspawn containers

[test case]

create/start a nspawn container, e.g. with 'machinectl start', open a
shell in the container, and check resolvectl to see if a nameserver was
provided.

[regression potential]

failures in the host networkd, possibly affecting other host interfaces
which are controlled by networkd, or (more likely) failure to provide
dhcp to nspawn containers

[scope]

TBD

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

** Affects: systemd (Ubuntu Focal)
 Importance: Medium
     Assignee: Dan Streetman (ddstreet)
 Status: In Progress

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

** Changed in: systemd (Ubuntu Focal)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Focal)
   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/1950496

Title:
  networkd doesn't provide DNS to nspawn containers

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  In Progress

Bug description:
  [impact]

  the host networkd doesn't include DNS info to nspawn containers

  [test case]

  create/start a nspawn container, e.g. with 'machinectl start', open a
  shell in the container, and check resolvectl to see if a nameserver
  was provided.

  [regression potential]

  failures in the host networkd, possibly affecting other host
  interfaces which are controlled by networkd, or (more likely) failure
  to provide dhcp to nspawn containers

  [scope]

  TBD

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

[Dan Streetman]

> and in QEMU it seems that this bug is not reproducible

can you provide steps on how this is reproducable then?

-- 
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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log

[Dan Streetman]

** Also affects: lightdm (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: lightdm (Ubuntu Bionic)
   Importance: Undecided => Low

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

Title:
  attempt to dlopen nonexistent pam_kwallet.so spams log

Status in lightdm package in Ubuntu:
  New
Status in lightdm source package in Bionic:
  New
Status in lightdm source package in Focal:
  New
Status in lightdm source package in Hirsute:
  New
Status in lightdm source package in Impish:
  New
Status in lightdm source package in Jammy:
  New

Bug description:
  [impact]

  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.

  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so

  [test case]

  install/enable lightdm and check system log at boot for messages like:

  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

  [regression potential]

  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.

  [scope]

  this is needed in all releases

  [other info]

  https://github.com/canonical/lightdm/pull/216

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log

[Dan Streetman]

** Description changed:

  [impact]
  
  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.
  
  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so
  
  [test case]
  
  install/enable lightdm and check system log at boot for messages like:
  
  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so
  
  [regression potential]
  
  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.
  
  [scope]
  
  this is needed in all releases
+ 
+ [other info]
+ 
+ https://github.com/canonical/lightdm/pull/216

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

Title:
  attempt to dlopen nonexistent pam_kwallet.so spams log

Status in lightdm package in Ubuntu:
  New
Status in lightdm source package in Focal:
  New
Status in lightdm source package in Hirsute:
  New
Status in lightdm source package in Impish:
  New
Status in lightdm source package in Jammy:
  New

Bug description:
  [impact]

  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.

  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so

  [test case]

  install/enable lightdm and check system log at boot for messages like:

  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

  [regression potential]

  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.

  [scope]

  this is needed in all releases

  [other info]

  https://github.com/canonical/lightdm/pull/216

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] [NEW] attempt to dlopen nonexistent pam_kwallet.so spams log

[Dan Streetman]

Public bug reported:

[impact]

lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
only the newer '5' version, not the older unversioned library file.

This results in repeated spam error messages in the system log
complaining about failure to load pam_kwallet.so

[test case]

install/enable lightdm and check system log at boot for messages like:

Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

[regression potential]

any regression would likely cause problems during login and/or missing
or extra log messages during pam authentication.

[scope]

this is needed in all releases

** Affects: lightdm (Ubuntu)
 Importance: Low
 Status: New

** Affects: lightdm (Ubuntu Focal)
 Importance: Low
 Status: New

** Affects: lightdm (Ubuntu Hirsute)
 Importance: Low
 Status: New

** Affects: lightdm (Ubuntu Impish)
 Importance: Low
 Status: New

** Affects: lightdm (Ubuntu Jammy)
 Importance: Low
 Status: New

** Also affects: lightdm (Ubuntu Impish)
   Importance: Undecided
   Status: New

** Also affects: lightdm (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: lightdm (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: lightdm (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Changed in: lightdm (Ubuntu Focal)
   Importance: Undecided => Low

** Changed in: lightdm (Ubuntu Hirsute)
   Importance: Undecided => Low

** Changed in: lightdm (Ubuntu Impish)
   Importance: Undecided => Low

** Changed in: lightdm (Ubuntu Jammy)
   Importance: Undecided => Low

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

Title:
  attempt to dlopen nonexistent pam_kwallet.so spams log

Status in lightdm package in Ubuntu:
  New
Status in lightdm source package in Focal:
  New
Status in lightdm source package in Hirsute:
  New
Status in lightdm source package in Impish:
  New
Status in lightdm source package in Jammy:
  New

Bug description:
  [impact]

  lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
  well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
  which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
  kwallet) while pam_kwallet5.so comes from kwallet-pam which provides
  only the newer '5' version, not the older unversioned library file.

  This results in repeated spam error messages in the system log
  complaining about failure to load pam_kwallet.so

  [test case]

  install/enable lightdm and check system log at boot for messages like:

  Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): 
/lib/security/pam_kwallet.so: cannot open shared object file: No such file or 
directory
  Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so

  [regression potential]

  any regression would likely cause problems during login and/or missing
  or extra log messages during pam authentication.

  [scope]

  this is needed in all releases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

> the additional information contains valid data.

then I think SRU'ing this would cause a behavior change that could
possibly break someone, which isn't something we should do.

I'd suggest putting the fix behind some opt-in mechanism, so anyone who
is affected can opt-in to the fixed behavior, but there's no change by
default.

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1948538] Re: USB serial devices not available in /dev/serial/by-id/ after upgrade

[Dan Streetman]

> /usr/lib/udev/rules.d/90-pi-bluetooth.rules:14 Invalid value ...

rules provided by pi-bluetooth package, not systemd.

** Package changed: systemd (Ubuntu) => pi-bluetooth (Ubuntu)

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

Title:
  USB serial devices not available in /dev/serial/by-id/ after upgrade

Status in pi-bluetooth package in Ubuntu:
  New

Bug description:
  it looks like systemd-udevd is crashing with the following error:

  -- Boot a74cfdb7e237433f9321d32ebe70e086 --
  Oct 23 13:28:50 Himari systemd-udevd[931]: 
/usr/lib/udev/rules.d/90-pi-bluetooth.rules:14 Invalid value "/bin/sh -c 
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0 $ALIASES/serial0; 
then echo 0;elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 
1; fi'" for PROGRAM (char 58: invalid substitution type), ignoring, but please 
fix it.
  Oct 23 13:28:50 Himari systemd-udevd[931]: 
/usr/lib/udev/rules.d/90-pi-bluetooth.rules:27 Invalid value "/bin/sh -c 
'ALIASES=/proc/device-tree/aliases; if [ -e /dev/ttyAMA0 ]; then exit 1; elif 
cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0 
$ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 97: invalid 
substitution type), ignoring, but please fix it.
  Oct 23 13:28:50 Himari systemd-udevd[931]: 
/usr/lib/udev/rules.d/90-pi-bluetooth.rules:38 Invalid value "/bin/sh -c 
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart1 $ALIASES/serial0; 
then echo 0; elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then echo 1; else 
exit 1; fi '" for PROGRAM (char 58: invalid substitution type), ignoring, but 
please fix it.

  I'm not sure if this is related, or a red herring.

  
  this is on a raspberry pi 4b 2GB that was recently upgraded from 21.04 to 
21.10

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: udev 248.3-1ubuntu8
  ProcVersionSignature: Ubuntu 5.13.0-1008.9-raspi 5.13.14
  Uname: Linux 5.13.0-1008-raspi aarch64
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: arm64
  CasperMD5CheckResult: unknown
  CustomUdevRuleFiles: 70-snap.snapd.rules 70-snap.mjpg-streamer.rules
  Date: Sat Oct 23 13:31:46 2021
  ImageMediaBuild: 20210421.1
  Lspci-vt: -[:00]---00.0-[01]00.0  VIA Technologies, Inc. VL805/806 
xHCI USB 3.0 Controller
  Lsusb:
   Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 1d50:614e OpenMoko, Inc. lpc1769
   Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  ProcEnviron:
   SHELL=/bin/bash
   LANG=C.UTF-8
   TERM=xterm
   XDG_RUNTIME_DIR=
   PATH=(custom, user)
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 
snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 
bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 
smsc95xx.macaddr=DC:A6:32:7C:E6:E5 vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 
console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait 
fixrtc quiet splash
  SourcePackage: systemd
  UpgradeStatus: Upgraded to impish on 2021-10-17 (6 days ago)
  acpidump:

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pi-bluetooth/+bug/1948538/+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 1947708] Re: Cannot configure suspend-then-hibernate

[Dan Streetman]

> [   82.230208] Lockdown: systemd-logind: hibernation is restricted;
see man kernel_lockdown.7

you're using UEFI secure boot, which puts the system into 'lockdown',
which disallows (unencrypted) hibernation.

So this isn't a problem with systemd, this requires the kernel to handle
encrypted hibernation.

I *think* that functionality isn't yet in the upstream kernel, as I think this 
thread was the last discussion about adding it:
https://lore.kernel.org/lkml/20210220013255.1083202-1-matthewgarr...@google.com/


** Package changed: systemd (Ubuntu) => linux (Ubuntu)

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

Title:
  Cannot configure suspend-then-hibernate

Status in linux package in Ubuntu:
  New

Bug description:
  Previous bug 1947617 was closed because my swap space was
  insufficient. Swap was increased to 24G and the problem remains.

  Configuring login to suspend-then-hiberrnate when the lid is off and
  configuring sleep so that hibernate happens 10 seconds after suspend,
  when trying to test with:

  sudo systemctl suspend-then-hibernate

  I get:

  Failed to suspend system, hibernate later via logind: Sleep verb
  "suspend-then-hibernate" not supported

  This could be a security vulnerability. If the user expects the system
  to suspend (and then lock) when the lid is off and it does not work,
  somebody could then just reopen the lid and get access.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: systemd 248.3-1ubuntu8
  ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
  Uname: Linux 5.13.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: i3
  Date: Tue Oct 19 11:51:50 2021
  InstallationDate: Installed on 2021-10-14 (4 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  MachineType: HP HP ENVY x360 Convertible 13-ay0xxx
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-19-generic 
root=UUID=e85d08c2-ae82-4f0f-a625-a5012616c934 ro quiet splash vt.handoff=7
  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/systemd-localed.service → 
/usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   3 overridden configuration files found.
  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.
   --
   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)
  dmi.bios.date: 07/30/2021
  dmi.bios.release: 15.20
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.20
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 876E
  dmi.board.vendor: HP
  dmi.board.version: 12.52
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 12.52
  dmi.modalias: 
dmi:bvnInsyde:bvrF.20:bd07/30/2021:br15.20:efr12.52:svnHP:pnHPENVYx360Convertible13-ay0xxx:pvrType1ProductConfigId:sku3V693EA#ABF:rvnHP:rn876E:rvr12.52:cvnHP:ct31:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP Envy
  dmi.product.name: HP ENVY x360 Convertible 13-ay0xxx
  dmi.product.sku: 3V693EA#ABF
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP
  mtime.conffile..etc.systemd.logind.conf: 2021-10-18T18:51:43.976989
  mtime.conffile..etc.systemd.sleep.conf: 2021-10-18T18:52:04.283409

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947708/+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 1947617] Re: Cannot configure suspend-then-hibernate

[Dan Streetman]

You have 16G of memory:

> [0.081527] Memory: 15609664K/16134968K available

But you only seem to have 2G of swap:

[2.770354] Adding 2097148k swap on /swapfile

There is no way hibernation is possible on your system with this setup.

** Changed in: systemd (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/1947617

Title:
  Cannot configure suspend-then-hibernate

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Configuring login to suspend-then-hiberrnate when the lid is off and
  configuring sleep so that hibernate happens 10 seconds after suspend,
  when trying to test with:

  sudo systemctl suspend-then-hibernate

  I get:

  Failed to suspend system, hibernate later via logind: Sleep verb
  "suspend-then-hibernate" not supported

  This could be a security vulnerability. If the user expects the system
  to suspend (and then lock) when the lid is off and it does not work,
  somebody could then just reopen the lid and get access.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: systemd 248.3-1ubuntu8
  ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
  Uname: Linux 5.13.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: i3
  Date: Mon Oct 18 18:57:35 2021
  InstallationDate: Installed on 2021-10-14 (3 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  MachineType: HP HP ENVY x360 Convertible 13-ay0xxx
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-19-generic 
root=UUID=e85d08c2-ae82-4f0f-a625-a5012616c934 ro quiet splash vt.handoff=7
  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/systemd-localed.service → 
/usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   3 overridden configuration files found.
  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.
   --
   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)
  dmi.bios.date: 07/30/2021
  dmi.bios.release: 15.20
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.20
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 876E
  dmi.board.vendor: HP
  dmi.board.version: 12.52
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 12.52
  dmi.modalias: 
dmi:bvnInsyde:bvrF.20:bd07/30/2021:br15.20:efr12.52:svnHP:pnHPENVYx360Convertible13-ay0xxx:pvrType1ProductConfigId:sku3V693EA#ABF:rvnHP:rn876E:rvr12.52:cvnHP:ct31:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP Envy
  dmi.product.name: HP ENVY x360 Convertible 13-ay0xxx
  dmi.product.sku: 3V693EA#ABF
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP
  mtime.conffile..etc.systemd.logind.conf: 2021-10-18T18:51:43.976989
  mtime.conffile..etc.systemd.sleep.conf: 2021-10-18T18:52:04.283409

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1947617/+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 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations

[Dan Streetman]

Ok let's go with option #1 then, just open up systemd-logind to network
access directly by editing the service file.

@mbiebl, do you want to patch this in Debian too, should I open a merge
request in salsa? Obviously if Debian is patched first, that's ideal.
Assuming you're ok with directly patching systemd-logind to open network
access, instead of putting a drop-in file in the nis package.

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

Title:
  systemd-logind network access is blocked, and breaks remote
  authentication configurations

Status in systemd:
  Fix Released
Status in nis package in Ubuntu:
  Confirmed
Status in openldap package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in nis package in Debian:
  Fix Released

Bug description:
  [impact]

  starting in focal, systemd-logind runs sandboxed without any network
  access, which breaks any configuration that uses remote servers for
  user data, e.g. ldap, nis, etc

  A more full discussion is available in the upstream bug report as well
  as the debian bug report, see other info section below

  [test case]

  many possible ways to reproduce this; there are reproducers in some of
  the bugs reported before that are caused by this, e.g. bug 1915502 or
  bug 1916235

  [regression potential]

  failure to authenticate when using remote user data, incorrect
  authentication, security issues due to un-sandboxing of systemd-logind

  [scope]

  this is needed in f and later

  before focal, systemd-logind was not sandboxed so this did not apply

  [other info]

  this isn't actually a bug in systemd, this is a by-design security feature; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
  https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
  https://github.com/systemd/systemd/issues/15705#issuecomment-624125354

  this may also can cause systemd-udevd failures in some cases as well.
  https://github.com/systemd/systemd/pull/7343#issuecomment-344800313

  For reference, upstream discussion around the systemd-logind sandboxing 
specifically:
  https://github.com/systemd/systemd/issues/7074
  upstream updated doc PR explaining the upstream position:
  https://github.com/systemd/systemd/pull/7343

  Debian bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625
  Note that while this Debian bug is marked as fix released, I don't think it 
actually fixes the problem, from the final comment it seems like the only 
change was to add Recommends: nscd, which doesn't really solve things if 
someone doesn't use nscd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1934393/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge

[Dan Streetman]

>  I like the idea of the kernel command line argument because it is
easy to apply and consistent across install types.

I agree the kernel boot param is absolutely easier, especially in the
context of maas.

TL;DR from me is: I think it's at least worth looking at using a link
file, or some other simpler method for this specific situation/hardware;
if that's significantly more work and/or more complex, I'm +1 on this
MR.


For more detail; my main objection to the MR is 2 things:

1) it would (in very limited situations) change the interface naming for
anyone who is manually setting net-naming to 'latest' (which can be done
either with a boot param, or editing the env var used by systemd-udevd).
Why would anyone manually set that? I don't know for sure, since it is
(and as you say, has long been) the default for ubuntu builds of
systemd, but of course that's exactly the requirement for anyone to
actually use the change introduced by the MR, so it's possible.

2) it doesn't actually fix this for anyone currently experiencing the
problem; they would have to know about this change, and then take the
extra step of manually setting the net-naming. So this really is a
change that primarily benefits a very limited group of possibly affected
users.

Note that I don't think #2 is necessarily a blocker; I've done exactly
that before, e.g. bug 304393. I do think your backport of the v247
naming scheme is the best way to handle this *if* there is no other way
to address it (that isn't significantly more painful).

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

Title:
  udev produces unpredictable net names when PCI device is a bridge

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  udev can produce unpredictable network interface names by default when 
multiple devices map to the same slot due to an intermediate bridge. On an 
Nvidia DGX2 system, I see the following when booting a system with udev 
245.4-4ubuntu3.13:

  ubuntu@akis:~$ ls /sys/class/net
  enp134s0f0  enp6s0  ens103  ens107  eth3  eth9
  enp134s0f1  ens102  ens106  eth1eth7  lo

  For each ens* device, there is a sibling eth* device that maps to the
  same slot because both devices are behind the same bridge.

  Unpredictable names present well known problems, but I'll describe a
  specific issue I'm having. We currently do automated network testing
  that MAAS deploys a system and then configures 2 specific NICs on the
  system. While MAAS does take care to always restore the names used
  during commissioning (eth3 will always be the same NIC on every
  deploy), these names can change each time the system is commissioned.
  So today we need to go in and edit the NIC names manually in MAAS any
  time the system is re-commissioned.

  [Test Case]
  Boot with kernel option net.naming-scheme=v247; verify that all network 
interfaces receive predictable names.

  [Fix]
  This issue was addressed upstream by adding a new v247 naming scheme that 
detects this scenario and disables usage of slot-based names for these devices. 
Obviously changing the default naming scheme in a released LTS series could 
break users. However, we could introduce the v247 scheme in a focal SRU, and 
keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users 
impacted by this could then opt-in to the v247 scheme by passing 
net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. 
I could add this to DGX2 systems via a kernel_opts MAAS tag to always get 
predictable names during commissioning.

  [Regression Risk]
  This would change the behavior of any users who select 
net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm 
not sure why an existing Ubuntu user would be doing that though - AFAICT, 
Ubuntu currently always defaults to the latest scheme.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge

[Dan Streetman]

> how would one insert such a file during (and early enough) in the
commissioning process?

well, i'll leave that one up to the maas team to answer properly, but i think 
there are ways to use custom commissioning scripts:
https://maas.io/docs/commissioning-scripts-reference

or even custom commissioning images:
https://maas.io/docs/image-builder

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

Title:
  udev produces unpredictable net names when PCI device is a bridge

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  udev can produce unpredictable network interface names by default when 
multiple devices map to the same slot due to an intermediate bridge. On an 
Nvidia DGX2 system, I see the following when booting a system with udev 
245.4-4ubuntu3.13:

  ubuntu@akis:~$ ls /sys/class/net
  enp134s0f0  enp6s0  ens103  ens107  eth3  eth9
  enp134s0f1  ens102  ens106  eth1eth7  lo

  For each ens* device, there is a sibling eth* device that maps to the
  same slot because both devices are behind the same bridge.

  Unpredictable names present well known problems, but I'll describe a
  specific issue I'm having. We currently do automated network testing
  that MAAS deploys a system and then configures 2 specific NICs on the
  system. While MAAS does take care to always restore the names used
  during commissioning (eth3 will always be the same NIC on every
  deploy), these names can change each time the system is commissioned.
  So today we need to go in and edit the NIC names manually in MAAS any
  time the system is re-commissioned.

  [Test Case]
  Boot with kernel option net.naming-scheme=v247; verify that all network 
interfaces receive predictable names.

  [Fix]
  This issue was addressed upstream by adding a new v247 naming scheme that 
detects this scenario and disables usage of slot-based names for these devices. 
Obviously changing the default naming scheme in a released LTS series could 
break users. However, we could introduce the v247 scheme in a focal SRU, and 
keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users 
impacted by this could then opt-in to the v247 scheme by passing 
net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. 
I could add this to DGX2 systems via a kernel_opts MAAS tag to always get 
predictable names during commissioning.

  [Regression Risk]
  This would change the behavior of any users who select 
net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm 
not sure why an existing Ubuntu user would be doing that though - AFAICT, 
Ubuntu currently always defaults to the latest scheme.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge

[Dan Streetman]

> udev can produce unpredictable network interface names by default when
multiple devices map to the same slot due to an intermediate bridge.

so, if I understand it right, the MR won't actually fix this for anyone
without additional per-system work, right? specifically, any system with
this problem will need to also add the 'net.naming-scheme=latest' boot
parameter (or set it via systemd-udevd env var).

If that's the case, then it seems like a much simpler manual workaround
for this would be to just avoid slot naming for the problematic nics,
for example by dropping a link file into /etc/systemd/network/ with
content like:

[Match]
Driver="whatever driver the DGX nics use, or use some other specific match"

[Link]
NamePolicy=keep kernel database onboard path
AlternativeNamesPolicy=database onboard path
MACAddressPolicy=persistent


essentially, override the 99-default.link to remove 'slot' naming.

> While MAAS does take care to always restore the names used during
commissioning (eth3 will always be the same NIC on every deploy), these
names can change each time the system is commissioned.

if the only change needed is during maas comissioning, that seems like
the perfect time to use a link file to override the specific problematic
nics by whatever matching logic is best.

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

Title:
  udev produces unpredictable net names when PCI device is a bridge

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  udev can produce unpredictable network interface names by default when 
multiple devices map to the same slot due to an intermediate bridge. On an 
Nvidia DGX2 system, I see the following when booting a system with udev 
245.4-4ubuntu3.13:

  ubuntu@akis:~$ ls /sys/class/net
  enp134s0f0  enp6s0  ens103  ens107  eth3  eth9
  enp134s0f1  ens102  ens106  eth1eth7  lo

  For each ens* device, there is a sibling eth* device that maps to the
  same slot because both devices are behind the same bridge.

  Unpredictable names present well known problems, but I'll describe a
  specific issue I'm having. We currently do automated network testing
  that MAAS deploys a system and then configures 2 specific NICs on the
  system. While MAAS does take care to always restore the names used
  during commissioning (eth3 will always be the same NIC on every
  deploy), these names can change each time the system is commissioned.
  So today we need to go in and edit the NIC names manually in MAAS any
  time the system is re-commissioned.

  [Test Case]
  Boot with kernel option net.naming-scheme=v247; verify that all network 
interfaces receive predictable names.

  [Fix]
  This issue was addressed upstream by adding a new v247 naming scheme that 
detects this scenario and disables usage of slot-based names for these devices. 
Obviously changing the default naming scheme in a released LTS series could 
break users. However, we could introduce the v247 scheme in a focal SRU, and 
keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users 
impacted by this could then opt-in to the v247 scheme by passing 
net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. 
I could add this to DGX2 systems via a kernel_opts MAAS tag to always get 
predictable names during commissioning.

  [Regression Risk]
  This would change the behavior of any users who select 
net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm 
not sure why an existing Ubuntu user would be doing that though - AFAICT, 
Ubuntu currently always defaults to the latest scheme.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1940715] Re: systemd-resolved restricts edns0 advertised max size to 512

[Dan Streetman]

** Bug watch added: github.com/systemd/systemd/issues #20993
   https://github.com/systemd/systemd/issues/20993

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/20993
   Importance: Unknown
   Status: Unknown

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

Title:
  systemd-resolved restricts edns0 advertised max size to 512

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  In Progress
Status in systemd source package in Impish:
  New

Bug description:
  [impact]

  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of
  the primary benefits of edns0 is to allow using packet sizes larger
  than 512, which is the pre-edns0 max packet size.

  this results in systemd-resolved failing to handle responses larger
  than 512 with udp/edns0, and having to fall back to tcp. This is not
  optimal (since tcp dns imposes significantly higher overhead) and may
  even cause failures, if a firewall allows udp dns but blocks tcp dns
  traffic.

  [test case]

  enable debug logging in systemd-resolved, with 'sudo systemctl edit
  systemd-resolved' and then add:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then save that file and restart systemd-resolved (or reboot).

  Make sure to flush the cache and reset server features before
  reproducing:

  $ sudo resolvectl flush-caches
  $ sudo resolvectl reset-server-features

  Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see
  if it used TCP fallback or not:

  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a 
response at feature level TCP from DNS server 10.202.51.1.
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive 
unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on 
eth0/INET/10.202.51.1

  A correct lookup using larger EDNS0 response size looks like:

  ...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level 
UDP+EDNS0 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 
10.202.51.1 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 
1472 in egress EDNS(0) packet.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 
1500, socket MTU is 0, minimal MTU is 40
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with 
id 43808 of size 49.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing query...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Received dns UDP packet of 
size 689, ifindex=131, ttl=0, fragsize=0
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing incoming packet 
of size 689 on transaction 43808 (rcode=SUCCESS).
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Added positive 
unauthenticated non-confidential cache entry for toomany.ddstreet.org IN A 
1175s on eth0/INET/10.202.51.1
  ...

  [regression potential]

  failure to correctly look up dns records, or other problems while
  performing dns lookups with systemd-resolved

  [scope]

  this is needed for all releases

  this still needs fixing upstream:
  https://github.com/systemd/systemd/pull/20528

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1940715/+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 1946086] Re: systemd user daemon fails with Permission denied when creating transient scope

[Dan Streetman]

*** This bug is a duplicate of bug 1742804 ***
https://bugs.launchpad.net/bugs/1742804

** This bug has been marked a duplicate of bug 1742804
   Failed to add PIDs to scope's control group

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

Title:
  systemd user daemon fails with Permission denied when creating
  transient scope

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Observed on 18.04. Systemd user instance fails when trying to create a
  transient scope when logged in through ssh as a regular user

  Specifically this fails:
  $ systemd-run --user --scope ls
  Job for run-rc78f932ad730440490bd7bc17f9d5c8c.scope failed.
  See "systemctl status run-rc78f932ad730440490bd7bc17f9d5c8c.scope" and 
"journalctl -xe" for details.

  Inspecting journal shows:
  Oct 05 10:38:16 ubuntu systemd[1437]: 
run-rc78f932ad730440490bd7bc17f9d5c8c.scope: Failed to add PIDs to scope's 
control group: Permission denied
  Oct 05 10:38:16 ubuntu systemd[1437]: 
run-rc78f932ad730440490bd7bc17f9d5c8c.scope: Failed with result 'resources'.
  Oct 05 10:38:16 ubuntu systemd[1437]: Failed to start /bin/ls.
  Oct 05 10:38:16 ubuntu polkitd(authority=local)[1244]: Unregistered 
Authentication Agent for unix-process:7425:200857 (system bus name :1.106, 
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale 
en_US.UTF-8) (disconnected from bus)

  
  Further strace shows that there is an EACCES when writing the PID of the 
forked process to cgroup procs: 

  1437  openat(AT_FDCWD, 
"/sys/fs/cgroup/pids/user.slice/user-999.slice/user@999.service/run-r067b0361ac97410886bbb3eec1c3848d.scope/pids.max",
 O_WRONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  1437  newfstatat(AT_FDCWD, "/sys/fs/cgroup/unified", {st_dev=makedev(0, 32), 
st_ino=1, st_mode=S_IFDIR|0555, st_nlink=5, st_uid=0, st_gid=0, 
st_blksize=4096, st_blocks=0, st_size=0, st_atime=1633428300 /* 
2021-10-05T10:05:00.33600+ */, st_atime_nsec=33600, 
st_mtime=1633428300 /* 2021-10-05T10:05:00.33600+ */, 
st_mtime_nsec=33600, st_ctime=1633428300 /* 
2021-10-05T10:05:00.33600+ */, st_ctime_nsec=33600}, 
AT_SYMLINK_NOFOLLOW) = 0
  1437  openat(AT_FDCWD, 
"/sys/fs/cgroup/unified/user.slice/user-999.slice/user@999.service/run-r067b0361ac97410886bbb3eec1c3848d.scope/cgroup.procs",
 O_WRONLY|O_NOCTTY|O_CLOEXEC) = 34
  1437  fcntl(34, F_GETFL)= 0x8001 (flags O_WRONLY|O_LARGEFILE)
  1437  fstat(34, {st_dev=makedev(0, 32), st_ino=2358, st_mode=S_IFREG|0644, 
st_nlink=1, st_uid=999, st_gid=999, st_blksize=4096, st_blocks=0, st_size=0, 
st_atime=1633430486 /* 2021-10-05T10:41:26.701277147+ */, 
st_atime_nsec=701277147, st_mtime=1633430486 /* 
2021-10-05T10:41:26.701277147+ */, st_mtime_nsec=701277147, 
st_ctime=1633430486 /* 2021-10-05T10:41:26.701277147+ */, 
st_ctime_nsec=701277147}) = 0
  1437  write(34, "7461\n", 5)= -1 EACCES (Permission denied)
  1437  close(34) = 0

  Full strace of the failed attempt:
  https://paste.ubuntu.com/p/4vwtYQ7mww/

  When executing the same command from a gnome terminal, the scope is
  created successfuly. Full trace of successful execution:
  https://paste.ubuntu.com/p/XjJ8mfxSXn/

  The relevant bit from the happy execution path:

  openat(AT_FDCWD, 
"/sys/fs/cgroup/pids/user.slice/user-999.slice/user@999.service/run-rd9ebe0f0326b482e82ca374c5ae613cd.scope/pids.max",
 O_WRONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  newfstatat(AT_FDCWD, "/sys/fs/cgroup/unified", {st_dev=makedev(0, 32), 
st_ino=1, st_mode=S_IFDIR|0555, st_nlink=5, st_uid=0, st_gid=0, 
st_blksize=4096, st_blocks=0, st_size=0, st_atime=1633428300 /* 
2021-10-05T10:05:00.33600+ */, st_atime_nsec=33600, 
st_mtime=1633428300 /* 2021-10-05T10:05:00.33600+ */, 
st_mtime_nsec=33600, st_ctime=1633428300 /* 
2021-10-05T10:05:00.33600+ */, st_ctime_nsec=33600}, 
AT_SYMLINK_NOFOLLOW) = 0
  openat(AT_FDCWD, 
"/sys/fs/cgroup/unified/user.slice/user-999.slice/user@999.service/run-rd9ebe0f0326b482e82ca374c5ae613cd.scope/cgroup.procs",
 O_WRONLY|O_NOCTTY|O_CLOEXEC) = 34
  fcntl(34, F_GETFL)  = 0x8001 (flags O_WRONLY|O_LARGEFILE)
  fstat(34, {st_dev=makedev(0, 32), st_ino=2298, st_mode=S_IFREG|0644, 
st_nlink=1, st_uid=999, st_gid=999, st_blksize=4096, st_blocks=0, st_size=0, 
st_atime=1633429609 /* 2021-10-05T10:26:49.619626843+ */, 
st_atime_nsec=619626843, st_mtime=1633429609 /* 
2021-10-05T10:26:49.619626843+ */, st_mtime_nsec=619626843, 
st_ctime=1633429609 /* 2021-10-05T10:26:49.619626843+ */, 
st_ctime_nsec=619626843}) = 0
  write(34, "7410\n", 5)  = 5
  close(34)   = 0

  23838 write(31, "24075\n", 6)   = -1 EACCES (Permission
  denied)

  $ lsb_release -rd
  Description

[Touch-packages] [Bug 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

for later reference, i'd discussed this with nick and asked him to check
if the 'status_request' reply contained any kind of valid data in the
specific cases where this patch will disable it; my concern is if there
is valid data in it, it's possible there are applications out there that
might currently expect and/or use it, even if it's against the RFC,
which might result in a regression after this patch. However, if the
reply is empty or just has garbage, it's unlikely that any application
is using it for anything currently, so there would be less chance of
causing a regression.

** Tags added: sts-sponsor-ddstreet

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

Title:
  OpenSSL servers can send a non-empty status_request in a
  CertificateRequest

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
  CertificateRequest message to the client with a non-empty
  status_request extension.

  This issue was fixed in openssl-1.1.1d and is included in Focal
  onward.

  Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
  Upstream patch review at https://github.com/openssl/openssl/pull/9780

  The issue leads to various client failures with TLS 1.3 as described
  in, e.g.

  https://github.com/golang/go/issues/35722
  https://github.com/golang/go/issues/34040

  [Test Plan]

  The issue can be reproduced by building with `enable-ssl-trace`
  and then running `s_server` like this:

  ```
  openssl s_server -key key.pem -cert cert.pem -status_file 
test/recipes/ocsp-response.der -Verify 5
  ```

  And running `s_client` like this:

  ```
  openssl s_client -status -trace -cert cert.pem -key key.pem
  ```

  The output shows a `status_request` extension in the
  `CertificateRequest` as follows:

  Received Record
  Header:
    Version = TLS 1.2 (0x303)
    Content Type = ApplicationData (23)
    Length = 1591
    Inner Content Type = Handshake (22)
  CertificateRequest, Length=1570
    request_context (len=0):
    extensions, length = 1567
  extension_type=status_request(5), length=1521
     - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2   
0..
    000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01   
0.+.0..
    001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86   
0...0..
    002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47   
0..1.0...UG
  ...more lines omitted...

  If the `status_request` extension is present in a
  `CertificateRequest` then it must be empty according to RFC8446,
  Sec. 4.4.2.1.

  [Where problems could occur]

  The patch disables the `status_request` extension inside a
  `CertificateRequest`. Applications expecting the incorrect,
  non-empty reply for the `status_request` extension will break
  with this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1945066] Re: package udev 245.4-4ubuntu3.11 failed to install/upgrade: installed udev package post-installation script subprocess returned error exit status 1

[Dan Streetman]

your system has kernel warnings and hung task errors, and you appear to
be using an unsupported 5.9 kernel, it seems the problem is there, not
with systemd/udevd.

** Package changed: systemd (Ubuntu) => linux (Ubuntu)

** Changed in: linux (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/1945066

Title:
  package udev 245.4-4ubuntu3.11 failed to install/upgrade: installed
  udev package post-installation script subprocess returned error exit
  status 1

Status in linux package in Ubuntu:
  Invalid

Bug description:
  The error explains itself, I think.

  Best regards.

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: udev 245.4-4ubuntu3.11
  Uname: Linux 5.9.10-050910-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.18
  AptOrdering:
   udev:amd64: Install
   libudev1:amd64: Install
   libudev1:amd64: Configure
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  CustomUdevRuleFiles: 70-snap.stellarium-daily.rules 70-snap.hw-probe.rules 
70-snap.snapd.rules 70-snap.snap-store.rules 70-snap.zoom-client.rules 
70-snap.acestreamplayer.rules 70-snap.brave.rules
  Date: Sat Sep 25 16:37:14 2021
  ErrorMessage: installed udev package post-installation script subprocess 
returned error exit status 1
  InstallationDate: Installed on 2020-11-06 (323 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  MachineType: LENOVO 82B5
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.9.10-050910-generic 
root=UUID=4ebadc28-5f91-4ef7-84ea-9f51b6e6b941 ro quiet splash 
amdgpu.exp_hw_support=1 vt.handoff=7
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.4
  SourcePackage: systemd
  Title: package udev 245.4-4ubuntu3.11 failed to install/upgrade: installed 
udev package post-installation script subprocess returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/01/2021
  dmi.bios.release: 1.31
  dmi.bios.vendor: LENOVO
  dmi.bios.version: EUCN31WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo Legion 5 15ARH05
  dmi.ec.firmware.release: 1.31
  dmi.modalias: 
dmi:bvnLENOVO:bvrEUCN31WW:bd01/01/2021:br1.31:efr1.31:svnLENOVO:pn82B5:pvrLenovoLegion515ARH05:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoLegion515ARH05:
  dmi.product.family: Legion 5 15ARH05
  dmi.product.name: 82B5
  dmi.product.sku: LENOVO_MT_82B5_BU_idea_FM_Legion 5 15ARH05
  dmi.product.version: Lenovo Legion 5 15ARH05
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1945066/+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 1944459] Re: systemd-udevd NamePolicy= warning issue

[Dan Streetman]

> "ubuntu systemd-udevd[911]: Network interface NamePolicy= disabled on
kernel command line, ignoring."

yes..you have disabled it on the kernel command line. I don't understand
what the bug is here?

** Changed in: systemd (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/1944459

Title:
  systemd-udevd NamePolicy= warning issue

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  So I'm getting a warning on syslog:

  "ubuntu systemd-udevd[911]: Network interface NamePolicy= disabled on
  kernel command line, ignoring."

  I've seen another similar report which seems to be fixed back in 2015:

  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411992

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.13
  ProcVersionSignature: Ubuntu 5.4.0-1043.47-raspi 5.4.133
  Uname: Linux 5.4.0-1043-raspi armv7l
  ApportVersion: 2.20.11-0ubuntu27.20
  Architecture: armhf
  CasperMD5CheckResult: skip
  Date: Tue Sep 21 20:46:59 2021
  ImageMediaBuild: 20210819.1
  Lspci-vt: -[:00]---00.0-[01]00.0  VIA Technologies, Inc. VL805 USB 
3.0 Host Controller
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
   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
   |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=usbfs, 
480M
   |__ Port 2: Dev 3, If 1, Class=Vendor Specific Class, Driver=, 480M
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 
snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=0 
bcm2708_fb.fbheight=0 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:66:9F:A2 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  net.ifnames=0 
dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable 
rootfstype=ext4 elevator=deadline rootwait fixrtc fsck.mode=auto 
fsck.repair=yes ipv6.disable=1 bcm2835_wdt.nowayout=1 bcm2835_wdt.heartbeat=10 
quiet splash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  acpidump:
   
  mtime.conffile..etc.systemd.resolved.conf: 2021-09-21T18:08:30.647280

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1944459/+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 1910769] Re: systemd-logind: loss of input devices when logging in after restart

[Dan Streetman]

*** This bug is a duplicate of bug 1944711 ***
https://bugs.launchpad.net/bugs/1944711

I suspect this is due to bug 1944711, which i'll dup this one to; i know
your bug is far older, but since i couldn't reproduce your bug and i'm
not sure if it's the same, i didn't want to take it over with the fix
for that bug. If that one turns out not to fix this please feel free to
un-dup this bug.

** This bug has been marked a duplicate of bug 1944711
   restarting systemd-logind loses all existing sessions

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

Title:
  systemd-logind: loss of input devices when logging in after restart

Status in systemd package in Ubuntu:
  New

Bug description:
  # Steps to reproduce

  1) Login as a regular user.
  2) `sudo systemctl restart systemd-logind`

  This boots you back to GDM, as you would expect.

  3) Login as a user.
  4) Wait a few seconds.

  # Expected behaviour

  I can continue to use my system normally.

  # Actual behaviour

  My keyboard and mouse stop working; unplugging/replugging has no
  effect.  Everything on screen continues to behave normally.

  # Debugging Notes

  I noticed, when Ctrl-Alt-F'ing around trying to figure out what was
  going on, that there are _two_ GDM sessions apparently running after
  the logind restart.

  Furthermore, I logged in on a console (Ctrl-Alt-F2) before performing
  the restart of logind, and when my keyboard stopped working in my
  graphical session, typing commands still worked!  (I couldn't see this
  console, obviously, but I tested it by typing `mplayer Music/*/*` and
  observing music start playing.)

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.6-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-36.40-generic 5.8.18
  Uname: Linux 5.8.0-36-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu50.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Jan  8 10:06:56 2021
  InstallationDate: Installed on 2019-05-07 (611 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Gigabyte Technology Co., Ltd. B450M DS3H
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-36-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash 
resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/systemd-logind.service → 
/etc/systemd/system/systemd-logind.service.d/override.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   3 overridden configuration files found.
  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.
   --
   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: Upgraded to groovy on 2020-06-22 (199 days ago)
  dmi.bios.date: 01/25/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F4
  dmi.board.asset.tag: Default string
  dmi.board.name: B450M DS3H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B450M DS3H
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910769/+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 1944711] Re: restarting systemd-logind loses all existing sessions

[Dan Streetman]

** Changed in: systemd (Ubuntu)
   Status: New => Fix Released

** Description changed:

  [impact]
  
  restarting the systemd-logind service loses all existing sessions
  
  [test case]
  
  ubuntu@test-f:~$ loginctl list-sessions
- SESSION  UID USER   SEAT TTY  
-3789 1000 ubuntu  pts/0
+ SESSION  UID USER   SEAT TTY
+    3789 1000 ubuntu  pts/0
  
  1 sessions listed.
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  ubuntu@test-f:~$ sudo systemctl restart systemd-logind
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service...
  Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded.
  Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service.
  Sep 23 11:23:07 test-f systemd[1]: Starting Login Service...
  Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 
1000, ignoring: Invalid argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid 
argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known.
  Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No 
such file or directory
  Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0.
  Sep 23 11:23:07 test-f systemd[1]: Started Login Service.
  ubuntu@test-f:~$ loginctl list-sessions
  No sessions.
  
  [regression potential]
  
  any regression would likely occur during a systemd-logind restart,
  likely causing a loss of current login sessions.
  
  [scope]
  
- this is needed in f and earlier
+ this is needed only in f
  
  this is fixed upstream by commit
  ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246, so
  this is fixed in h and later already.
+ 
+ in b, the function used to parse the /run/systemd/users/* files allows
+ either usernames or uids, so this bug does not exist there

** Changed in: systemd (Ubuntu Focal)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Focal)
   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/1944711

Title:
  restarting systemd-logind loses all existing sessions

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress

Bug description:
  [impact]

  restarting the systemd-logind service loses all existing sessions

  [test case]

  ubuntu@test-f:~$ loginctl list-sessions
  SESSION  UID USER   SEAT TTY
     3789 1000 ubuntu  pts/0

  1 sessions listed.
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  ubuntu@test-f:~$ sudo systemctl restart systemd-logind
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service...
  Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded.
  Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service.
  Sep 23 11:23:07 test-f systemd[1]: Starting Login Service...
  Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 
1000, ignoring: Invalid argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid 
argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known.
  Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No 
such file or directory
  Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0.

[Touch-packages] [Bug 1944711] [NEW] restarting systemd-logind loses all existing sessions

[Dan Streetman]

Public bug reported:

[impact]

restarting the systemd-logind service loses all existing sessions

[test case]

ubuntu@test-f:~$ loginctl list-sessions
SESSION  UID USER   SEAT TTY  
   3789 1000 ubuntu  pts/0

1 sessions listed.
ubuntu@test-f:~$ journalctl -b -u systemd-logind
-- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 
UTC. --
Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
ubuntu@test-f:~$ sudo systemctl restart systemd-logind
ubuntu@test-f:~$ journalctl -b -u systemd-logind
-- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 
UTC. --
Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service...
Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded.
Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service.
Sep 23 11:23:07 test-f systemd[1]: Starting Login Service...
Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 
1000, ignoring: Invalid argument
Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid 
argument
Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known.
Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No such 
file or directory
Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0.
Sep 23 11:23:07 test-f systemd[1]: Started Login Service.
ubuntu@test-f:~$ loginctl list-sessions
No sessions.

[regression potential]

any regression would likely occur during a systemd-logind restart,
likely causing a loss of current login sessions.

[scope]

this is needed in f and earlier

this is fixed upstream by commit
ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246, so
this is fixed in h and later already.

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

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

** Also affects: systemd (Ubuntu Focal)
   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/1944711

Title:
  restarting systemd-logind loses all existing sessions

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New

Bug description:
  [impact]

  restarting the systemd-logind service loses all existing sessions

  [test case]

  ubuntu@test-f:~$ loginctl list-sessions
  SESSION  UID USER   SEAT TTY  
 3789 1000 ubuntu  pts/0

  1 sessions listed.
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  ubuntu@test-f:~$ sudo systemctl restart systemd-logind
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service...
  Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded.
  Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service.
  Sep 23 11:23:07 test-f systemd[1]: Starting Login Service...
  Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 
1000, ignoring: Invalid argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid 
argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known.
  Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No 
such file or directory
  Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0.
  Sep 23 11:23:07 test-f systemd[1]: Started Login Service.
  ubuntu@test-f:~$ loginctl list-sessions
  No sessions.

  [regression potential]

  any regression would likely occur during a systemd-logind restart,
  likely causing a loss of current login sessions.

  [scope]

  this is needed in f and earlier

  this is fixed upstream by commit
  ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246, so

[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations

[Dan Streetman]

One good point in favor of including systemd-userdbd in Debian/Ubuntu
would be that we only need to adjust the restrictions for that service;
all other systemd-provided services would use (or at least, *should*
use...) systemd-userdbd to get user records. I'm not sure if that is
actually worth including and using systemd-userdbd to the distro.


Putting that aside for now, I think the only options to fix this all involve 
removing the systemd-logind restriction(s). The only question seems to be 
what/who removes the restrictions.

1) We could simply remove the restrictions for systemd-logind in the
Debian/Ubuntu package, for everyone. This would (theoretically) reduce
the security of systemd-logind by allowing it to access the network, but
also it would allow network-based NSS lookups to work in all situations
(meaning, for all possible NSS modules, not only NIS and/or select other
packages/modules).

2) We could add drop-in files to remove the restrictions for systemd-
logind, for the 'nis' package (which I think has been split out in later
releases and in Debian, so we'd need to pick the correct client
package). We would also need to include drop-in files for any other
package that provides an NSS module that needs to perform network
lookups, such as the 'libnss-ldap' package (I haven't verified this
needs network access but I believe it does, e.g. comment 7 above).

3) We could simply add documentation to the README and/or man pages
and/or other docs and leave it up to the system admin to add the
systemd-logind drop-in file when they set up NIS or LDAP or whatever
other network-based auth provider.


Personally, I think #3 is barely better than the current situation; there's 
just far too many setup guides and other documentation out there for us to 
expect all Debian/Ubuntu users to notice the additional step we might add to 
our own docs, even if it's in the package README and man pages. However, if we 
think that NSS-based network auth services are a thing of the past (as seems to 
be the upstream position on this), then maybe just adding docs is the right way 
to handle this.

I'm not too enthusiastic about option #2 either. While it would help
with users of specific packages, without those users needing to know any
specific details about the workaround, it won't cover all use cases -
since we don't necessarily know all the different packages that might
need to provide a drop-in - and also it could *add* confusion in some
cases. For example, if someone is using a custom network-based libnss
module, it would work on any system where they had the 'nis' package
installed, but fail on any system where it wasn't installed - regardless
of whether they are actually using nis for anything at all. That's the
kind of thing that is incredibly painful to debug. This option also
would require the 'nis' and 'libnss-ldap' packages to restart systemd-
logind when they are installed, which (in the past at least) has
sometimes been problematic.

I know that option #1 is kind of the 'worst', since it essentially just
gives up and removes the restriction from systemd-logind for everyone.
However, I personally think it's the best option. If/when we do start
providing systemd-userdbd (and it's enabled by default), I think we
should move the lifted restriction over to it, instead of systemd-
logind. But for now we should just modify systemd-logind to allow
network access, IMHO.

Since this is *theoretically* related to security, I'd like to get the
Ubuntu security team's opinion on the change. I've cc'ed them on this
bug.

@mbiebl, what do you think? I really don't know what the best approach
is, either for Debian or for Ubuntu. And obviously, if you (or anyone)
has other suggestions I'm happy to hear them.

And finally just FTR, I personally think upstream systemd should just
remove the restriction (specifically, I mean remove IPAddressDeny=any)
from systemd-userdbd.service. That service already funnels all systemd
requests for user data into a single isolated process, I think it's
overkill to also restrict that process from network access, when it's so
common to have NSS-based network authentication mechanisms. However,
Lennart's made his opinion known[1], and I'd prefer not to be the person
who tries to argue with him to change his mind.

[1]:
https://github.com/systemd/systemd/issues/15705#issuecomment-624125354


** Changed in: systemd (Ubuntu)
   Status: Won't Fix => Confirmed

** Description changed:

  [impact]
  
  starting in focal, systemd-logind runs sandboxed without any network
  access, which breaks any configuration that uses remote servers for user
  data, e.g. ldap, nis, etc
  
  A more full discussion is available in the upstream bug report as well
  as the debian bug report, see other info section below
  
  [test case]
  
  many possible ways to reproduce this; there are reproducers in some of
  the bugs reported before that are caused by this, e.g. bug 1915502 or
  bug 1916235
  
  [regression po

[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations

[Dan Streetman]

** Description changed:

  [impact]
  
  starting in focal, systemd-logind runs sandboxed without any network
  access, which breaks any configuration that uses remote servers for user
  data, e.g. ldap, nis, etc
  
  A more full discussion is available in the upstream bug report as well
  as the debian bug report, see other info section below
  
  [test case]
  
  many possible ways to reproduce this; there are reproducers in some of
  the bugs reported before that are caused by this, e.g. bug 1915502 or
  bug 1916235
  
  [regression potential]
  
  failure to authenticate when using remote user data, incorrect
  authentication, security issues due to un-sandboxing of systemd-logind
  
  [scope]
  
  this is needed in f and later
  
  before focal, systemd-logind was not sandboxed so this did not apply
  
  [other info]
  
- this isn't actually a bug in systemd, this is a by-design security
- feature, and the intended upstream design is for systemd-logind to talk
- to systemd-userdb, so that systemd-logind can remain network-sandboxed
- while systemd-userdb performs any needed network access for user/auth
- data. However, Debian and Ubuntu don't enable/provide systemd-userdb, so
- that design does not work for Debian/Ubuntu.
+ this isn't actually a bug in systemd, this is a by-design security feature; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
+ https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
+ https://github.com/systemd/systemd/issues/15705#issuecomment-624125354
  
- this also can cause systemd-udevd failures in some cases as well,
- apparently (based on upstream and debian discussion comments)
+ this may also can cause systemd-udevd failures in some cases as well.
+ https://github.com/systemd/systemd/pull/7343#issuecomment-344800313
  
  For reference, upstream discussion around the systemd-logind sandboxing 
specifically:
  https://github.com/systemd/systemd/issues/7074
  upstream updated doc PR explaining the upstream position:
  https://github.com/systemd/systemd/pull/7343
  
  Debian bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625

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

Title:
  systemd-logind network access is blocked, and breaks remote
  authentication configurations

Status in systemd:
  Fix Released
Status in nis package in Ubuntu:
  Confirmed
Status in openldap package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Won't Fix
Status in nis package in Debian:
  Fix Released

Bug description:
  [impact]

  starting in focal, systemd-logind runs sandboxed without any network
  access, which breaks any configuration that uses remote servers for
  user data, e.g. ldap, nis, etc

  A more full discussion is available in the upstream bug report as well
  as the debian bug report, see other info section below

  [test case]

  many possible ways to reproduce this; there are reproducers in some of
  the bugs reported before that are caused by this, e.g. bug 1915502 or
  bug 1916235

  [regression potential]

  failure to authenticate when using remote user data, incorrect
  authentication, security issues due to un-sandboxing of systemd-logind

  [scope]

  this is needed in f and later

  before focal, systemd-logind was not sandboxed so this did not apply

  [other info]

  this isn't actually a bug in systemd, this is a by-design security feature; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
  https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
  https://github.com/systemd/systemd/issues/15705#issuecomment-624125354

  this may also can cause systemd-udevd failures in some cases as well.
  https://github.com/systemd/systemd/pull/7343#issuecomment-344800313

  For reference, upstream discussion around the systemd-logind sandboxing 
specifically:
  https://github.com/systemd/systemd/issues/7074
  upstream updated doc PR explaining the upstream position:
  https://github.com/systemd/systemd/pull/7343

  Debian bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1934393/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lis

[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations

[Dan Streetman]

> @Dan: have you actually confirmed, that building and running userdbd
solves those issues with NIS and LDAP?

sorry for the delay in getting back to this.

So, you're correct, userdb doesn't actually help this, it only moves the
problem.

While systemd-userdbd.service does (currently, at least) allow AF_INET
and AF_INET6, I missed that it also includes IPAddressDeny=any which
results in the problem existing there as well.

So if we include systemd-userdbd in Debian/Ubuntu, then the network-
restricted systemd-logind problem is simply moved to systemd-userdbd. I
will note that I did verify, if systemd-logind is running with its
default restrictions and systemd-userdbd is also running without its
IPAddressDeny=any restriction, the issue is fixed; systemd-logind does
correctly get the user record from NIS through systemd-userdbd.

I also seem to have misunderstood Lennart's position on this; after re-
reading his statements[1] it seems that his position is that *all*
systemd services should be locked down (or at least, both systemd-logind
and systemd-userdbd) and the responsibility for poking holes in one (or
both, or more) of those services' restrictions is on NIS and any other
NSS library that requires network access.

So enabling systemd-userdbd won't help with this bug, unless we want to
diverge from upstream by removing its IPAddressDeny=any restriction. But
we could just as easily remove that from systemd-logind (along with
adding AF_INET and AF_INET6 to it).

[1]:
https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
https://github.com/systemd/systemd/issues/15705#issuecomment-624125354


** Bug watch added: github.com/systemd/systemd/issues #15705
   https://github.com/systemd/systemd/issues/15705

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

Title:
  systemd-logind network access is blocked, and breaks remote
  authentication configurations

Status in systemd:
  Fix Released
Status in nis package in Ubuntu:
  Confirmed
Status in openldap package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Won't Fix
Status in nis package in Debian:
  Fix Released

Bug description:
  [impact]

  starting in focal, systemd-logind runs sandboxed without any network
  access, which breaks any configuration that uses remote servers for
  user data, e.g. ldap, nis, etc

  A more full discussion is available in the upstream bug report as well
  as the debian bug report, see other info section below

  [test case]

  many possible ways to reproduce this; there are reproducers in some of
  the bugs reported before that are caused by this, e.g. bug 1915502 or
  bug 1916235

  [regression potential]

  failure to authenticate when using remote user data, incorrect
  authentication, security issues due to un-sandboxing of systemd-logind

  [scope]

  this is needed in f and later

  before focal, systemd-logind was not sandboxed so this did not apply

  [other info]

  this isn't actually a bug in systemd, this is a by-design security feature; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
  https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
  https://github.com/systemd/systemd/issues/15705#issuecomment-624125354

  this may also can cause systemd-udevd failures in some cases as well.
  https://github.com/systemd/systemd/pull/7343#issuecomment-344800313

  For reference, upstream discussion around the systemd-logind sandboxing 
specifically:
  https://github.com/systemd/systemd/issues/7074
  upstream updated doc PR explaining the upstream position:
  https://github.com/systemd/systemd/pull/7343

  Debian bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1934393/+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 1943990] Re: After updating systemd packages to 245.4-4ubuntu3.13 and libvirt packages to 6.0.0-0ubuntu8.14, it is no longer possible to start kvm virtual machines

[Dan Streetman]

you state you have systemd version 245.4-4ubuntu3.13 installed, but your 
description shows otherwise:
Package: systemd-container 245.4-4ubuntu3.11


** Changed in: systemd (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/1943990

Title:
  After updating systemd packages to 245.4-4ubuntu3.13 and libvirt
  packages to 6.0.0-0ubuntu8.14, it is no longer possible to start kvm
  virtual machines

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  # systemctl status systemd-machined.service 
  ● systemd-machined.service - Virtual Machine and Container Registration 
Service
   Loaded: loaded (/lib/systemd/system/systemd-machined.service; static; 
vendor preset: enabled)
   Active: inactive (dead)
 Docs: man:systemd-machined.service(8)
   https://www.freedesktop.org/wiki/Software/systemd/machined

  Sep 17 15:40:42 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual 
Machine and Container Registration Service.
  Sep 17 15:40:42 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job 
systemd-machined.service/start failed with result 'dependency'.
  Sep 17 15:42:26 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual 
Machine and Container Registration Service.
  Sep 17 15:42:26 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job 
systemd-machined.service/start failed with result 'dependency'.
  Sep 17 16:02:55 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual 
Machine and Container Registration Service.
  Sep 17 16:02:55 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job 
systemd-machined.service/start failed with result 'dependency'.
  Sep 17 16:04:39 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual 
Machine and Container Registration Service.
  Sep 17 16:04:39 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job 
systemd-machined.service/start failed with result 'dependency'.

  Trying to start a virtual machine from openstack, it defines the
  machine, but is not able to execute it.

  I used to have libvirt apparmor errors, but disabling libvirt in apparmor 
didn't solve the problem:
  [   27.785713] audit: type=1400 audit(1631888214.441:67): apparmor="DENIED" 
operation="capable" profile="libvirtd" pid=4817 comm="libvirtd" capability=17  
capname="sys_rawio"

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd-container 245.4-4ubuntu3.11
  ProcVersionSignature: Ubuntu 5.11.0-34.36~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-34-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.20
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Sep 17 16:23:39 2021
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1943990/+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 1938259] Re: Add ACCEL_LOCATION=base property for Dell clamshell models

[Dan Streetman]

this was marked fix-released for f/h just due to the tooling matching
the bug number; this was actually reverted as shown in the changelogs
posted in the above comments. I'll just correct f/h to indicate this is
wontfix, and a new bug will or has been opened to fix this correctly.

** Changed in: systemd (Ubuntu Hirsute)
   Status: Fix Released => Won't Fix

** Changed in: systemd (Ubuntu Focal)
   Status: Fix Released => Won't Fix

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

Title:
  Add ACCEL_LOCATION=base property for Dell clamshell models

Status in OEM Priority Project:
  Won't Fix
Status in systemd package in Ubuntu:
  Won't Fix
Status in systemd source package in Focal:
  Won't Fix
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix

Bug description:
  We are planning to do SRU to systemd in focal, to avoid unwanted
  screen rotations on some Dell laptop models.

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A3E or 0E0E, install this package and 
kernel 5.13, or kernel with this patch backported:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e26f023e01ef26b4138bc1099af309bdc4523d23
   * Rotate the laptop and the display should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * This fix would only take effect with kernel 5.13 or the above patch
  backported.

  [scope]

  this is needed for all releases

  this is being fixed upstream by
  https://github.com/systemd/systemd/pull/20314

  [Other info]

   * The patch mentioned above is going to have a separated SRU for
  linux-oem-5.10 and linux-hwe-5.11 (LP: #1938143)

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1938259/+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 1939255] Re: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once

[Dan Streetman]

as systemd was respun (for focal) due to bug 1942899, and only the one
udev (hwdb) patch was reverted which shouldn't affect this at all, I'm
remarking this as verified still based on testing for the previous
version above.


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

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

Title:
  dhclient triggers systemd-resolved start limit when processing more
  than 5 interfaces at once

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  on a system where systemd-resolved is running, if dhclient is used on
  more than 5 interfaces, it calls the '/etc/dhcp/dhclient-enter-
  hooks.d/resolved' script multiple times, which then restarts systemd-
  resolved multiple times, triggering the unit's start-limit throttle
  which results in the unit entering failed state

  [test case]

  on a system with more than 5 available interfaces to run dhclient on
  (where all the interfaces will get a dhcp response), run dhclient with
  the interfaces:

  $ dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15

  check if systemd-resolved failed:

  $ journalctl -b -1 -u systemd-resolved
  ...
  Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Start 
request repeated too quickly.
  Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Failed with 
result 'start-limit-hit'.
  Aug 09 00:38:08 sf316232-b systemd[1]: Failed to start Network Name 
Resolution.

  [regression potential]

  failure to start/stop/restart systemd-resolved, or problems adding
  dhclient-provided DNS nameservers to systemd-resolved

  [scope]

  this is needed only for b/f

  the dhclient 'hook' script is provided by the systemd package in focal
  and earlier, and needs fixing in those releases

  in h and later, the 'hook' script is included in the isc-dhcp-client
  package and notifies systemd-resolved in a more direct way without
  requiring restarting, and so doesn't trigger the restart limiting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1939255/+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 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting

[Dan Streetman]

as systemd was respun due to bug 1942899, and only the one udev (hwdb)
patch was reverted which shouldn't affect this at all, I'm remarking
this as verified still based on testing for the previous version above.


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

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

Title:
  systemd-time-wait-sync.service stuck in "activating" state after boot,
  blocks timers from starting

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  systemd-time-wait-sync service sometimes misses sync completed event
  and remains in 'activating' state

  [test case]

  this isn't consistently reproducable, see original description for
  test case

  [regression potential]

  possible problems with the systemd-time-wait-sync service completing
  too early or not completing on time

  [scope]

  this is needed only for f

  this is fixed upstream with commit
  f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is
  fixed in h and later already

  the service does not exist in b so this does not apply there

  [original description]

  When I start my server running Ubuntu 20.04 the systemd-time-wait-
  sync.service is stuck in "activating" state. I noticed this because
  none of the systemd timer units triggered, because all the timers
  depend on systemd-time-wait-sync.service. Running "systemctl restart
  systemd-time-wait-sync.service" manually works around the problem.

  Some logs and command outputs:

  raek@mizar:~$ lsb_release -rd
  Description:Ubuntu 20.04.2 LTS
  Release:20.04

  raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service
    systemd-time-wait-sync.service  
 loaded activating start start Wait Until Kernel Time 
Synchronized

  raek@mizar:~$ systemctl status systemd-time-wait-sync.service
  ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized
   Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; 
enabled; vendor preset: enabled)
   Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago
     Docs: man:systemd-time-wait-sync.service(8)
     Main PID: 514 (systemd-time-wa)
    Tasks: 1 (limit: 9415)
   Memory: 972.0K
   CGroup: /system.slice/systemd-time-wait-sync.service
   └─514 /lib/systemd/systemd-time-wait-sync

  Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 
time Thu 2021-07-22 09:06:52.216338 UTC
  Warning: journal has been rotated since unit was started, output may be 
incomplete.

  raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service
  -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 
CEST. --
  Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 
time Thu 2021-07-22 09:06:52.216338 UTC

  raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service
  systemd: /lib/systemd/system/systemd-time-wait-sync.service

  raek@mizar:~$ apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.11
    Candidate: 245.4-4ubuntu3.11
    Version table:
   *** 245.4-4ubuntu3.11 500
  500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3.10 500
  500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
   245.4-4ubuntu3.8 400
  400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
   245.4-4ubuntu3 500
  500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

[Dan Streetman]

root@lp1853164-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.51 amd64system and service manager
root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf'
ii  ifupdown 0.8.17ubuntu1.1 amd64  
  high level tools to configure network interfaces
ii  resolvconf   1.79ubuntu10.18.04.3all
  name server information handler
root@lp1853164-b:~# grep eth0 /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
root@lp1853164-b:~# ip a show dev eth0
222: eth0@if223:  mtu 1500 qdisc noqueue state 
UP group default qlen 1000
link/ether 00:16:3e:16:1c:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.202.51.62/24 brd 10.202.51.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe16:1c78/64 scope link 
   valid_lft forever preferred_lft forever
root@lp1853164-b:~# systemctl is-enabled systemd-resolved
disabled
root@lp1853164-b:~# systemctl is-enabled systemd-networkd
disabled
root@lp1853164-b:~# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

root@lp1853164-b:~#


root@lp1853164-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.52 amd64system and service manager
root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf'
ii  ifupdown 0.8.17ubuntu1.1 amd64  
  high level tools to configure network interfaces
ii  resolvconf   1.79ubuntu10.18.04.3all
  name server information handler
root@lp1853164-b:~# grep eth0 /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
root@lp1853164-b:~# ip a show dev eth0
224: eth0@if225:  mtu 1500 qdisc noqueue state 
UP group default qlen 1000
link/ether 00:16:3e:16:1c:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.202.51.62/24 brd 10.202.51.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe16:1c78/64 scope link 
   valid_lft forever preferred_lft forever
root@lp1853164-b:~# systemctl is-enabled systemd-resolved
disabled
root@lp1853164-b:~# systemctl is-enabled systemd-networkd
disabled
root@lp1853164-b:~# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 10.202.51.1
search lxd
root@lp1853164-b:~# 


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

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

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  with systemd-resolved disabled, dhclient doesn't correctly notify
  resolvconf about dns server(s)

  [test case]

  install resolvconf and ifupdown and disable systemd-resolved and
  systemd-networkd, use ifupdown to get a dhcp address where the lease
  includes a dns nameserver, verify resolvconf is using that dhcp-
  provided nameserver

  [regression potential]

  failure to correctly notify systemd-resolved about new dhclient-
  provided nameserver(s)

  [scope]

  this is needed for f and earlier

  in g and later the hook script is moved to the isc-dhcp package, and
  edited to correctly check is-enabled systemd-resolved instead of only
  checking for the existence of the binary

  [original description]

  The functionality exists to allow users to revert to the traditional ifupdown
  package for network configuration. Alongside this, systemd's often-buggy
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled.
  The issue is here:

  if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved
  isn't enabled, it's difficult to imagine this code wanting to run. I've tested
  this with resolvconf and ifupdown dri

[Touch-packages] [Bug 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

[Dan Streetman]

as systemd was respun due to bug 1942899, and only the one udev (hwdb)
patch was reverted which shouldn't affect this at all, I'm remarking
this as verified still based on testing for the previous version above.

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

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  with systemd-resolved disabled, dhclient doesn't correctly notify
  resolvconf about dns server(s)

  [test case]

  install resolvconf and ifupdown and disable systemd-resolved and
  systemd-networkd, use ifupdown to get a dhcp address where the lease
  includes a dns nameserver, verify resolvconf is using that dhcp-
  provided nameserver

  [regression potential]

  failure to correctly notify systemd-resolved about new dhclient-
  provided nameserver(s)

  [scope]

  this is needed for f and earlier

  in g and later the hook script is moved to the isc-dhcp package, and
  edited to correctly check is-enabled systemd-resolved instead of only
  checking for the existence of the binary

  [original description]

  The functionality exists to allow users to revert to the traditional ifupdown
  package for network configuration. Alongside this, systemd's often-buggy
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled.
  The issue is here:

  if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved
  isn't enabled, it's difficult to imagine this code wanting to run. I've tested
  this with resolvconf and ifupdown driving dhclient, and it corrects the
  behaviour that was broken with the introduction of systemd-resolved.

  I'm attaching a patch, and am also including it here for easy access:

  *** resolved.broken 2019-11-19 15:01:28.785588838 +
  --- resolved2019-11-19 15:08:06.519430073 +
  ***
  *** 14,20 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! if [ -x /lib/systemd/systemd-resolved ] ; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in
  --- 14,21 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! systemctl is-active systemd-resolved > /dev/null 2>&1
  ! if [ $? -eq 0 ]; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

[Dan Streetman]

heh, please ignore the above comment, the current focal systemd was
respun, but the fix for this was already released for focal, this only
needs bionic verified now :)

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

Title:
  systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  with systemd-resolved disabled, dhclient doesn't correctly notify
  resolvconf about dns server(s)

  [test case]

  install resolvconf and ifupdown and disable systemd-resolved and
  systemd-networkd, use ifupdown to get a dhcp address where the lease
  includes a dns nameserver, verify resolvconf is using that dhcp-
  provided nameserver

  [regression potential]

  failure to correctly notify systemd-resolved about new dhclient-
  provided nameserver(s)

  [scope]

  this is needed for f and earlier

  in g and later the hook script is moved to the isc-dhcp package, and
  edited to correctly check is-enabled systemd-resolved instead of only
  checking for the existence of the binary

  [original description]

  The functionality exists to allow users to revert to the traditional ifupdown
  package for network configuration. Alongside this, systemd's often-buggy
  resolver can be disabled. However, there's a logic error in the systemd-
  supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
  from populating /etc/resolv.conf properly when systemd-resolved is disabled.
  The issue is here:

  if [ -x /lib/systemd/systemd-resolved ] ; then

  Instead of checking to see if the systemd-resolved service is enabled or
  active, which would be the correct behaviour, this checks for the existence of
  a binary, assuming that if it exists it's supposed to be used.

  I've not tested this in the absence of resolvconf, but if systemd-resolved
  isn't enabled, it's difficult to imagine this code wanting to run. I've tested
  this with resolvconf and ifupdown driving dhclient, and it corrects the
  behaviour that was broken with the introduction of systemd-resolved.

  I'm attaching a patch, and am also including it here for easy access:

  *** resolved.broken 2019-11-19 15:01:28.785588838 +
  --- resolved2019-11-19 15:08:06.519430073 +
  ***
  *** 14,20 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! if [ -x /lib/systemd/systemd-resolved ] ; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in
  --- 14,21 
    #   (D) = master script downs interface
    #   (-) = master script does nothing with this

  ! systemctl is-active systemd-resolved > /dev/null 2>&1
  ! if [ $? -eq 0 ]; then
    # For safety, first undefine the nasty default make_resolv_conf()
    make_resolv_conf() { : ; }
    case "$reason" in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models

[Dan Streetman]

for the verifications above, i also updated the 'udev' package to the
same version as systemd

** Tags removed: verification-needed verification-needed-focal 
verification-needed-hirsute
** Tags added: verification-done verification-done-focal 
verification-done-hirsute

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

Title:
  Revert Add ACCEL_LOCATION=base property for Dell clamshell models

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Committed

Bug description:
  [impact]

  initial patch for LP: #1938259 was incorrect.

  [test case]

  this bug is only to revert the previous patch

  the upstream commit
  
is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e

  checking for lack of the new 'sku' lines, and presence of the old
  lines, should be enough to verify this revert is correct

  [regression potential]

  any regression would likely be restricted to dell clamshell models
  matching the modified config settings

  [scope]

  the incorrect patch was added in f/h/i so only those need the patch
  removed/reverted

  [other info]

  this only reverts the patch that was added for bug 1938259, as the bug
  reporter indicated in that bug in comment 15 that the patch did not
  actually work correctly.

  a correct patch will need to go upstream first, so this bug is just to
  revert the last patch and respin systemd for all releases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models

[Dan Streetman]

commit to focal that needed reverting:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-focal&id=5c1be33900edee94da0dc9a4ade8edcd079b4c85

ubuntu@lp1942899-f:~$ dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.11 amd64system and service manager
ubuntu@lp1942899-f:~$ grep -E 'sku0A3E|sku0B0B' /lib/udev/hwdb.d/60-sensor.hwdb 
ubuntu@lp1942899-f:~$ 

ubuntu@lp1942899-f:~$ dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.13 amd64system and service manager
ubuntu@lp1942899-f:~$ grep -E 'sku0A3E|sku0B0B' /lib/udev/hwdb.d/60-sensor.hwdb 
ubuntu@lp1942899-f:~$

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

Title:
  Revert Add ACCEL_LOCATION=base property for Dell clamshell models

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Committed

Bug description:
  [impact]

  initial patch for LP: #1938259 was incorrect.

  [test case]

  this bug is only to revert the previous patch

  the upstream commit
  
is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e

  checking for lack of the new 'sku' lines, and presence of the old
  lines, should be enough to verify this revert is correct

  [regression potential]

  any regression would likely be restricted to dell clamshell models
  matching the modified config settings

  [scope]

  the incorrect patch was added in f/h/i so only those need the patch
  removed/reverted

  [other info]

  this only reverts the patch that was added for bug 1938259, as the bug
  reporter indicated in that bug in comment 15 that the patch did not
  actually work correctly.

  a correct patch will need to go upstream first, so this bug is just to
  revert the last patch and respin systemd for all releases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models

[Dan Streetman]

commit to hirsute that needed reverting:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a21edd743408b5603b0177e9c230c6d6b919e589

ubuntu@lp1942899-h:~$ dpkg -l systemd|grep systemd
ii  systemd247.3-3ubuntu3.4 amd64system and service manager
ubuntu@lp1942899-h:~$ grep -E 'pnLatitude7420|pnLatitude9520|sku0B0B|sku0A3E' 
/lib/udev/hwdb.d/60-sensor.hwdb 
sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude9520:*:ct10:*
sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude7420:*
ubuntu@lp1942899-h:~$ 


ubuntu@lp1942899-h:~$ dpkg -l systemd|grep systemd
ii  systemd247.3-3ubuntu3.6 amd64system and service manager
ubuntu@lp1942899-h:~$ grep -E 'pnLatitude7420|pnLatitude9520|sku0B0B|sku0A3E' 
/lib/udev/hwdb.d/60-sensor.hwdb 
sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude9520:*:ct10:*
sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude7420:*
ubuntu@lp1942899-h:~$

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

Title:
  Revert Add ACCEL_LOCATION=base property for Dell clamshell models

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Committed

Bug description:
  [impact]

  initial patch for LP: #1938259 was incorrect.

  [test case]

  this bug is only to revert the previous patch

  the upstream commit
  
is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e

  checking for lack of the new 'sku' lines, and presence of the old
  lines, should be enough to verify this revert is correct

  [regression potential]

  any regression would likely be restricted to dell clamshell models
  matching the modified config settings

  [scope]

  the incorrect patch was added in f/h/i so only those need the patch
  removed/reverted

  [other info]

  this only reverts the patch that was added for bug 1938259, as the bug
  reporter indicated in that bug in comment 15 that the patch did not
  actually work correctly.

  a correct patch will need to go upstream first, so this bug is just to
  revert the last patch and respin systemd for all releases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models

[Dan Streetman]

** Description changed:

  [impact]
  
  initial patch for LP: #1938259 was incorrect.
  
  [test case]
  
  this bug is only to revert the previous patch
+ 
+ the upstream commit
+ 
is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e
+ 
+ checking for lack of the new 'sku' lines, and presence of the old lines,
+ should be enough to verify this revert is correct
  
  [regression potential]
  
  any regression would likely be restricted to dell clamshell models
  matching the modified config settings
  
  [scope]
  
  the incorrect patch was added in f/h/i so only those need the patch
  removed/reverted
  
  [other info]
  
  this only reverts the patch that was added for bug 1938259, as the bug
  reporter indicated in that bug in comment 15 that the patch did not
  actually work correctly.
  
  a correct patch will need to go upstream first, so this bug is just to
  revert the last patch and respin systemd for all releases

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

Title:
  Revert Add ACCEL_LOCATION=base property for Dell clamshell models

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Committed
Status in systemd source package in Impish:
  Fix Committed

Bug description:
  [impact]

  initial patch for LP: #1938259 was incorrect.

  [test case]

  this bug is only to revert the previous patch

  the upstream commit
  
is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e

  checking for lack of the new 'sku' lines, and presence of the old
  lines, should be enough to verify this revert is correct

  [regression potential]

  any regression would likely be restricted to dell clamshell models
  matching the modified config settings

  [scope]

  the incorrect patch was added in f/h/i so only those need the patch
  removed/reverted

  [other info]

  this only reverts the patch that was added for bug 1938259, as the bug
  reporter indicated in that bug in comment 15 that the patch did not
  actually work correctly.

  a correct patch will need to go upstream first, so this bug is just to
  revert the last patch and respin systemd for all releases

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