[Touch-packages] [Bug 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-28 Thread Lukas Märdian
This should now be solved, as of 249.9-0ubuntu2

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

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1957086/+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 1958887] Re: Please merge logrotate 3.19.0-1 (main) from Debian unstable (main)

2022-01-28 Thread Lukas Märdian
Thank you, LGTM!

$ dput ubuntu ../logrotate_3.19.0-1ubuntu1_source.changes
D: Setting host argument.
Checking signature on .changes
gpg: ../logrotate_3.19.0-1ubuntu1_source.changes: Valid signature from 
5889C17AB1C8D890
Checking signature on .dsc
gpg: ../logrotate_3.19.0-1ubuntu1.dsc: Valid signature from 5889C17AB1C8D890
Uploading to ubuntu (via sftp to upload.ubuntu.com):
  Uploading logrotate_3.19.0-1ubuntu1.dsc: done.
  Uploading logrotate_3.19.0.orig.tar.xz: done.
  Uploading logrotate_3.19.0.orig.tar.xz.asc: done.
  Uploading logrotate_3.19.0-1ubuntu1.debian.tar.xz: done.  
  Uploading logrotate_3.19.0-1ubuntu1_source.buildinfo: done.
  Uploading logrotate_3.19.0-1ubuntu1_source.changes: done.
Successfully uploaded packages.

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

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

Title:
  Please merge logrotate 3.19.0-1 (main) from Debian unstable (main)

Status in logrotate package in Ubuntu:
  In Progress

Bug description:
  Please merge logrotate 3.19.0-1 (main) from Debian unstable (main)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1958887/+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 1955997] Re: The airplane hotkey has no function on a HP platform

2022-01-26 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
   Status: New => In Progress

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

Title:
  The airplane hotkey has no function on a HP platform

Status in OEM Priority Project:
  Triaged
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Focal:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  In Progress

Bug description:
  [Impact]
  The airplane hokey doesn't work on HP new generation machines.

  [Test Plan]
  Press airplane hokey.

  Before the patch, nothing happens.
  After the patch, the rfkill works as expected.

  [Where problems could occur]
  In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will 
not work but HP confirmed the new HP generation won't contain the HPQ6001 and 
also each DM still need to deal with multi-rfkill events because upstream 
changes[2].

  ---

  In the last year, HP mentions HP machines need to use hp-wireless
  (HPQ6001) as the rfkill source[1].

  However, HP confirms the HPQ6001 has been retired in the platforms
  since 2022.

  In the platforms after 2022, there are two sources of rkfill events 
(intel-hid, atkbd) and HP only guarantee the intel-hid works.
  Therefore, the upstream already accept the patch[2] to unmask intel-hid and 
mention this big change in the NEWS.

  This change makes the pre-2022 HP platforms meet the regression since they 
have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing 
function key.
  Thus, there is a patch[3] to make sure the GNOME could deal with this case 
smoothly.
  However, the systemd change will still cause other DEs meet the regression 
(xfce, KDE, lxde, etc..).
  Backport systemd change to make HP 2022 platforms work is not the best choice 
on stable version (focal in this case).

  We still need a solution to make airplane key works on 2022 HP platforms 
(intel-hid and atkbd only).
  The potential solution from my mind that is to maintain a whitelist to unmask 
intel-hid in ubuntu-patch in focal, something like:
  ```
  evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:*
   KEYBOARD_KEY_8=wlan # Use hp-wireless instead
  ```
  after "KEYBOARD_KEY_8=unkown".

  [1] https://bugs.launchpad.net/bugs/1883846
  [2] https://github.com/systemd/systemd/pull/20219
  [3] 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1955997/+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 1959013] Re: systemd test_exec_umask_namespace fails in privileged container

2022-01-25 Thread Lukas Märdian
No I don't think so. It is only setting: lxc profile set default
security.privileged "true"

See L60+:
https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/tests/tests-
in-lxd#n60

would security.nesting be required in this case?

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

Title:
  systemd test_exec_umask_namespace fails in privileged container

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

Bug description:
  systemd added a new test case to it's "test-execute", which is failing
  in privileged containers, while passing everywhere else.

  https://github.com/systemd/systemd-
  stable/commit/ae53f4b5e48860b473c4d05958486a77f84ecc6d

  exec-umask-namespace.service: Passing 0 fds to service
  exec-umask-namespace.service: About to execute /bin/ls -lahd /tmp/subdir
  exec-umask-namespace.service: Forked /bin/ls as 2485
  exec-umask-namespace.service: Changed dead -> start
  exec-umask-namespace.service: User lookup succeeded: uid=65534 gid=65534
  Received SIGCHLD from PID 2485 (ls).
  Child 2485 (ls) died (code=exited, status=2/INVALIDARGUMENT)
  exec-umask-namespace.service: Failed to read oom_kill field of memory.events 
cgroup attribute: No such file or directory
  exec-umask-namespace.service: Child 2485 belongs to 
exec-umask-namespace.service.
  exec-umask-namespace.service: Main process exited, code=exited, 
status=2/INVALIDARGUMENT
  exec-umask-namespace.service: Failed with result 'exit-code'.
  exec-umask-namespace.service: Service will not restart (restart setting)
  exec-umask-namespace.service: Changed start -> failed
  exec-umask-namespace.service: Unit entered failed state.
  src/test/test-execute.c:868:test_exec_umask_namespace: 
exec-umask-namespace.service: exit status 2, expected 0

  
  A full test-run / log is available at 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-slyon-testing/jammy/amd64/s/systemd/20220125_143301_25947@/log.gz

  I'll be skipping this test case fow now, to be able to move forward
  with systemd 249.9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1959013/+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 1959013] [NEW] systemd test_exec_umask_namespace fails in privileged container

2022-01-25 Thread Lukas Märdian
Public bug reported:

systemd added a new test case to it's "test-execute", which is failing
in privileged containers, while passing everywhere else.

https://github.com/systemd/systemd-
stable/commit/ae53f4b5e48860b473c4d05958486a77f84ecc6d

exec-umask-namespace.service: Passing 0 fds to service
exec-umask-namespace.service: About to execute /bin/ls -lahd /tmp/subdir
exec-umask-namespace.service: Forked /bin/ls as 2485
exec-umask-namespace.service: Changed dead -> start
exec-umask-namespace.service: User lookup succeeded: uid=65534 gid=65534
Received SIGCHLD from PID 2485 (ls).
Child 2485 (ls) died (code=exited, status=2/INVALIDARGUMENT)
exec-umask-namespace.service: Failed to read oom_kill field of memory.events 
cgroup attribute: No such file or directory
exec-umask-namespace.service: Child 2485 belongs to 
exec-umask-namespace.service.
exec-umask-namespace.service: Main process exited, code=exited, 
status=2/INVALIDARGUMENT
exec-umask-namespace.service: Failed with result 'exit-code'.
exec-umask-namespace.service: Service will not restart (restart setting)
exec-umask-namespace.service: Changed start -> failed
exec-umask-namespace.service: Unit entered failed state.
src/test/test-execute.c:868:test_exec_umask_namespace: 
exec-umask-namespace.service: exit status 2, expected 0


A full test-run / log is available at 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-slyon-testing/jammy/amd64/s/systemd/20220125_143301_25947@/log.gz

I'll be skipping this test case fow now, to be able to move forward with
systemd 249.9

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

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

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

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

Title:
  systemd test_exec_umask_namespace fails in privileged container

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

Bug description:
  systemd added a new test case to it's "test-execute", which is failing
  in privileged containers, while passing everywhere else.

  https://github.com/systemd/systemd-
  stable/commit/ae53f4b5e48860b473c4d05958486a77f84ecc6d

  exec-umask-namespace.service: Passing 0 fds to service
  exec-umask-namespace.service: About to execute /bin/ls -lahd /tmp/subdir
  exec-umask-namespace.service: Forked /bin/ls as 2485
  exec-umask-namespace.service: Changed dead -> start
  exec-umask-namespace.service: User lookup succeeded: uid=65534 gid=65534
  Received SIGCHLD from PID 2485 (ls).
  Child 2485 (ls) died (code=exited, status=2/INVALIDARGUMENT)
  exec-umask-namespace.service: Failed to read oom_kill field of memory.events 
cgroup attribute: No such file or directory
  exec-umask-namespace.service: Child 2485 belongs to 
exec-umask-namespace.service.
  exec-umask-namespace.service: Main process exited, code=exited, 
status=2/INVALIDARGUMENT
  exec-umask-namespace.service: Failed with result 'exit-code'.
  exec-umask-namespace.service: Service will not restart (restart setting)
  exec-umask-namespace.service: Changed start -> failed
  exec-umask-namespace.service: Unit entered failed state.
  src/test/test-execute.c:868:test_exec_umask_namespace: 
exec-umask-namespace.service: exit status 2, expected 0

  
  A full test-run / log is available at 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-slyon-testing/jammy/amd64/s/systemd/20220125_143301_25947@/log.gz

  I'll be skipping this test case fow now, to be able to move forward
  with systemd 249.9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1959013/+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 1958284] Re: shutdown hangs at "Waiting for process: ..." for 90s, ignoring DefaultTimeoutStopSec

2022-01-20 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Focal)
   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/1958284

Title:
  shutdown hangs at "Waiting for process: ..." for 90s, ignoring
  DefaultTimeoutStopSec

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Focal:
  Confirmed

Bug description:
  With systemd v245 as shipped with 20.04, the shutdown sequence does
  not use the value of `DefaultTimeoutStopSec` to wait for remaining
  processes, it instead uses the compiled in default of 90s.

  This is most visible with services that use `KillMode=process`
  (docker, k8s, k3s, etc...), especially if the remaining processes do
  not handle `SIGTERM` or choose to ignore it.

  For example:
  ```
  [ OK ] Finished Reboot.
  [ OK ] Reached target Reboot.
  [ 243.652848 ] systemd-shutdown[1]: Waiting for process: containerd-shim, 
containerd-shim, containerd-shim, fluent-bit

  --- hangs here for 90s even if DefaultTimeoutStopSec is set to a lower
  value ---

  ```

  The bug has been fixed upstream here:
  https://github.com/systemd/systemd/commit/7d9eea2bd3d4f83668c7a78754d201b22

  Marc was kind enough to package the patch for 20.04 so I could test it
  
(https://launchpad.net/~mdeslaur/+archive/ubuntu/testing/+sourcepub/13210617/+listing-
  archive-extra) and with that package, I can confirm that it indeed
  fixes the issue.

  Here's a few github issues I stumbled upon while trying to debug this,
  along with a short writeup of the workaround I ended up using:

  - https://github.com/moby/moby/issues/41831
  - https://github.com/k3s-io/k3s/issues/2400
  - https://github.com/systemd/systemd/issues/16991
  - https://raby.sh/debugging-90s-hangs-during-shutdown-on-ubuntu-2004.html

  Of course, it would be much better if all the processes would properly
  handle `SIGTERM`, but having a way to enforce a maximum wait time at
  shutdown is a decent workaround.

  Given that the patch is relatively simple, would it be possible to add
  it the package for 20.04?

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1958284/+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 1958284] Re: shutdown hangs at "Waiting for process: ..." for 90s, ignoring DefaultTimeoutStopSec

2022-01-20 Thread Lukas Märdian
** Tags added: rls-ff-incoming

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

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

Title:
  shutdown hangs at "Waiting for process: ..." for 90s, ignoring
  DefaultTimeoutStopSec

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Focal:
  New

Bug description:
  With systemd v245 as shipped with 20.04, the shutdown sequence does
  not use the value of `DefaultTimeoutStopSec` to wait for remaining
  processes, it instead uses the compiled in default of 90s.

  This is most visible with services that use `KillMode=process`
  (docker, k8s, k3s, etc...), especially if the remaining processes do
  not handle `SIGTERM` or choose to ignore it.

  For example:
  ```
  [ OK ] Finished Reboot.
  [ OK ] Reached target Reboot.
  [ 243.652848 ] systemd-shutdown[1]: Waiting for process: containerd-shim, 
containerd-shim, containerd-shim, fluent-bit

  --- hangs here for 90s even if DefaultTimeoutStopSec is set to a lower
  value ---

  ```

  The bug has been fixed upstream here:
  https://github.com/systemd/systemd/commit/7d9eea2bd3d4f83668c7a78754d201b22

  Marc was kind enough to package the patch for 20.04 so I could test it
  
(https://launchpad.net/~mdeslaur/+archive/ubuntu/testing/+sourcepub/13210617/+listing-
  archive-extra) and with that package, I can confirm that it indeed
  fixes the issue.

  Here's a few github issues I stumbled upon while trying to debug this,
  along with a short writeup of the workaround I ended up using:

  - https://github.com/moby/moby/issues/41831
  - https://github.com/k3s-io/k3s/issues/2400
  - https://github.com/systemd/systemd/issues/16991
  - https://raby.sh/debugging-90s-hangs-during-shutdown-on-ubuntu-2004.html

  Of course, it would be much better if all the processes would properly
  handle `SIGTERM`, but having a way to enforce a maximum wait time at
  shutdown is a decent workaround.

  Given that the patch is relatively simple, would it be possible to add
  it the package for 20.04?

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1958284/+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 1958415] Re: Sync libdatrie 0.2.13-2 from Debian unstable

2022-01-20 Thread Lukas Märdian
This bug was fixed in the package libdatrie - 0.2.13-2
Sponsored for Dave Jones (waveform)

---
libdatrie (0.2.13-2) unstable; urgency=medium

  * d/tests/build: Make build test cross-testable.
Change adapted from Sebastien Bacher's patch for libthai in bug #983522.
Thanks Julian Andres Klode for first rasing this with initial patch.
(Closes: #982540)
  * Trim trailing whitespace [lintian-brush].
  * Declare compliance with Debian Policy 4.6.0 (no changes)
  * Remove 1 obsolete maintscript entry [lintian-brush].
- libdatrie-dev.maintscript: No longer need to make doc symlink
  in libdatrie-dev as once required in stretch (oldoldstable).

 -- Theppitak Karoonboonyanan   Sun, 17 Oct 2021
12:48:12 +0700

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

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

Title:
  Sync libdatrie 0.2.13-2 from Debian unstable

Status in libdatrie package in Ubuntu:
  Fix Released

Bug description:
  Please sync libdatrie 0.2.13-2 (main) from Debian unstable.

  Explanation of the Ubuntu delta and why it can be dropped:

* debian/tests/build: Make build test cross-testable

  This change was introduced in libdatrie 0.2.13-1ubuntu1. Upstream
  incorporated a variation on this patch in 0.2.13-2; from
  
https://salsa.debian.org/debian/libdatrie/-/commit/9d0be356dbc5586fc913a27529807c0bd975ec8f:

* d/tests/build: Make build test cross-testable.
  Change adapted from Sebastien Bacher's patch for libthai in bug #983522.
  Thanks Julian Andres Klode for first rasing this with initial patch.
  (Closes: #982540)

  The later 0.2.13-1ubuntu2 and 0.2.13-1ubuntu3 versions were no-change
  rebuilds and can be ignored. All Ubuntu deltas are present upstream;
  no significant or unwanted changes in Debian packaging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdatrie/+bug/1958415/+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 1958244] Re: Sync acl 2.3.1-1 (main) from Debian unstable (main)

2022-01-20 Thread Lukas Märdian
This bug was fixed in the package acl - 2.3.1-1
Sponsored for Simon Chopin (schopin)

---
acl (2.3.1-1) unstable; urgency=medium

  * New upstream release.
- Remove upstream patches included in this release.
- Refresh remaining patches.
- Update upstream signing key.
  * Add support for the noudeb build profile.

 -- Guillem Jover   Sun, 29 Aug 2021 16:26:27 +0200

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

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

Title:
  Sync acl 2.3.1-1 (main) from Debian unstable (main)

Status in acl package in Ubuntu:
  Fix Released

Bug description:
  Please sync acl 2.3.1-1 (main) from Debian unstable (main)

  Explanation of the Ubuntu delta and why it can be dropped:
* No-change rebuild to build packages with zstd compression.
* Build with -fno-strict-aliasing
* No-change rebuild to drop the udeb package.

  The aliasing issue has been fixed upstream, see
  
https://git.savannah.nongnu.org/cgit/acl.git/commit/?id=cad5d69545765e00715d0cb0c88a3b4c20a59c1e

  Changelog entries since current jammy version 2.2.53-10ubuntu2:

  acl (2.3.1-1) unstable; urgency=medium

* New upstream release.
  - Remove upstream patches included in this release.
  - Refresh remaining patches.
  - Update upstream signing key.
* Add support for the noudeb build profile.

   -- Guillem Jover   Sun, 29 Aug 2021 16:26:27
  +0200

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/acl/+bug/1958244/+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 1958131] Re: Sync cpio 2.13+dfsg-7 (main) from Debian sid (main)

2022-01-20 Thread Lukas Märdian
This bug was fixed in the package cpio - 2.13+dfsg-7
Sponsored for Heinrich Schuchardt (xypron)

---
cpio (2.13+dfsg-7) unstable; urgency=medium

  [ Salvatore Bonaccorso ]
  * Fix dynamic string reallocations (Closes: #992192)

 -- Anibal Monsalve Salazar   Sun, 22 Aug 2021
15:21:53 +1000

cpio (2.13+dfsg-6) unstable; urgency=high

  * Fix regression of original fix for CVE-2021-38185
Add patch 992098-regression-of-orig-fix-for-CVE-2021-38185 
Closes: #992098

 -- Anibal Monsalve Salazar   Fri, 13 Aug 2021
13:06:27 +1000

cpio (2.13+dfsg-5) unstable; urgency=medium

  * Fix CVE-2021-38185
Add patch 992045-CVE-2021-38185-rewrite-dynamic-string-support
Closes: #992045

 -- Anibal Monsalve Salazar   Wed, 11 Aug 2021
01:18:33 +1000

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

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-38185

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

Title:
  Sync cpio 2.13+dfsg-7 (main) from Debian sid (main)

Status in cpio package in Ubuntu:
  Fix Released

Bug description:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256

   affects ubuntu/cpio
   status new
   importance wishlist
   subscribe ubuntu-sponsors
   done

  Please sync cpio 2.13+dfsg-7 (main) from Debian sid (main)

  Explanation of the Ubuntu delta and why it can be dropped:
* SECURITY UPDATE: arbitrary code execution via crafted pattern file
  - debian/patches/CVE-2021-38185.patch: rewrite dynamic string support
in src/copyin.c, src/copyout.c, src/copypass.c, src/dstring.c,
src/dstring.h, src/util.c.
  - debian/patches/CVE-2021-38185.2.patch: don't call ds_resize in a loop
in src/dstring.c.
  - debian/patches/CVE-2021-38185.3.patch: fix dynamic string
reallocations in src/dstring.c.
  - CVE-2021-38185
* Back out CVE-2021-381185 patches for now as they appear to be causing a
  regression when building the kernel
  - debian/patches/CVE-2021-38185.patch: disabled
  - debian/patches/CVE-2021-38185.2.patch: disabled
* SECURITY UPDATE: arbitrary code execution via crafted pattern file
  - debian/patches/CVE-2021-38185.2.patch: don't call ds_resize in a loop
in src/dstring.c.
  - CVE-2021-38185
* SECURITY UPDATE: arbitrary code execution via crafted pattern file
  - debian/patches/CVE-2021-38185.patch: rewrite dynamic string support
in src/copyin.c, src/copyout.c, src/copypass.c, src/dstring.c,
src/dstring.h, src/util.c.
  - CVE-2021-38185

  The code changes by the patch series in Ubuntu and Debian are the same.
  The patches are just name differently:

  d/992045-CVE-2021-38185-rewrite-dynamic-string-support 
u/patches/CVE-2021-38185.patch
  d/992098-regression-of-orig-fix-for-CVE-2021-38185 u/CVE-2021-38185.2.patch
  d/992192-Fix-dynamic-string-reallocations.patch 
u/patches/CVE-2021-38185.3.patch
  -BEGIN PGP SIGNATURE-

  iQIzBAEBCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmHlU6oACgkQhO4vgnE3
  U0s83g//e0P9zbgAB77m0zHcBpyiAYrIDfaWHGGXOARuRd7T5GXrrYFEo1ldGSqy
  eq9MrcQmFjEjy+0O7AGzmMVoQL0zyjze4OKIEb/8Hv2z9asyscJkI8zkTH7oO+Sg
  GWER6yP66MCOvTCseGMdlrCWng93GAyJbJSOhVFh1t0Pssl3QJ3txPdNU5j6jKwS
  b7NKnAMLvxBUHpftayFMHUtbZ/RpTzJavnQlperzN9W9OBbVccwSWwBJ3rjPoj1D
  LOaXxeuWBDcHi9k7bB/HtDIitkQDvFSqCB0otn14F3I5BUCiM3xqT7kiGZAeP6TP
  jny3IElHXDdepZOjqZ+UTJ0oTldKxRErz3XXWl32gVB0dOUgF7GgSoPSKckCp5hG
  P7f7stsc3Cout+jo88AUEDmsV9GX5kLLGFfC8kGlXnIS9S7lH+yd1xfNd6WmZkyd
  79pZAXZXAO/wrcD+g2U4OaD5a+LPYDxul6aA2l8hykN9OcN5Q+/F/r5DT2Oa4GeV
  vCvpbXrs+WGOPfU50qwofB0lhBScsHZ9Yuga6l3VWBrFnbgT0G1ceYqc5X/ym4is
  fTEBCthtTq7mDVzuSCGe21Ar4TwQtSPhwCu5RRLphmkIREFbFhBLDzSS8wQyyz2V
  OJuv38UGAmhOMajhmt504BBb/ssMf5ItdRX1+imF0MTQrX4YSbg=
  =2bpu
  -END PGP SIGNATURE-

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cpio/+bug/1958131/+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 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-18 Thread Lukas Märdian
** Changed in: systemd (Ubuntu)
   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/1957086

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1957086/+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 1957086] Re: Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

2022-01-18 Thread Lukas Märdian
Thank you for all the investigation, Christian!
I was planning to upgrade to >= v249.6 for Jammy anyway (probably 249.9). Will 
check the logs/patches for anything suspicious and verify if this solves this 
issue.

There is a bileto PPA that contains a 249.7 prototype:
https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4704/+packages

It might be worth a try copying the dnsmasq package into there and see
if the tests pass. Let me check that.

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

Title:
  Autopkgtest systemd fail against dnsmasq 2.86 (22.04)

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

Bug description:
  Full log (same on all architectures):
  
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/s/systemd/20220106_214401_24d29@/log.gz

  The test is from systemd:
  https://github.com/systemd/systemd/blob/main/test/networkd-test.py#L619

  Tail of the log:
  ```
  ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
  resolved: domain-restricted DNS servers
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.NdIvJq/build.fBQ/src/test/networkd-test.py", line 
678, in test_resolved_domain_restricted_dns
  out = subprocess.check_output(['resolvectl', 'query', 'math.lab'])
File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.9/subprocess.py", line 528, in run
  raise CalledProcessError(retcode, process.args,
  subprocess.CalledProcessError: Command '['resolvectl', 'query', 'math.lab']' 
returned non-zero exit status 1.
  ```

  
  Tagging update-excuse to be shown in excuses

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1957086/+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 1955997] Re: The airplane hotkey has no function on a HP platform

2022-01-11 Thread Lukas Märdian
Okay, so the current patch is for Focal? Please also provide debdiffs
for Jammy and Impish, as we'll stick with v249 (in Jammy) for the LTS
and Impish will not see a systemd update either. We need to fix it in
Jammy first, before we can start SRUing the change.

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

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

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

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

Title:
  The airplane hotkey has no function on a HP platform

Status in OEM Priority Project:
  Triaged
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]
  The airplane hokey doesn't work on HP new generation machines.

  [Test Plan]
  Press airplane hokey.

  Before the patch, nothing happens.
  After the patch, the rfkill works as expected.

  [Where problems could occur]
  In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will 
not work but HP confirmed the new HP generation won't contain the HPQ6001 and 
also each DM still need to deal with multi-rfkill events because upstream 
changes[2].

  ---

  In the last year, HP mentions HP machines need to use hp-wireless
  (HPQ6001) as the rfkill source[1].

  However, HP confirms the HPQ6001 has been retired in the platforms
  since 2022.

  In the platforms after 2022, there are two sources of rkfill events 
(intel-hid, atkbd) and HP only guarantee the intel-hid works.
  Therefore, the upstream already accept the patch[2] to unmask intel-hid and 
mention this big change in the NEWS.

  This change makes the pre-2022 HP platforms meet the regression since they 
have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing 
function key.
  Thus, there is a patch[3] to make sure the GNOME could deal with this case 
smoothly.
  However, the systemd change will still cause other DEs meet the regression 
(xfce, KDE, lxde, etc..).
  Backport systemd change to make HP 2022 platforms work is not the best choice 
on stable version (focal in this case).

  We still need a solution to make airplane key works on 2022 HP platforms 
(intel-hid and atkbd only).
  The potential solution from my mind that is to maintain a whitelist to unmask 
intel-hid in ubuntu-patch in focal, something like:
  ```
  evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:*
   KEYBOARD_KEY_8=wlan # Use hp-wireless instead
  ```
  after "KEYBOARD_KEY_8=unkown".

  [1] https://bugs.launchpad.net/bugs/1883846
  [2] https://github.com/systemd/systemd/pull/20219
  [3] 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1955997/+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 1955997] Re: The airplane hotkey has no function on a HP platform

2022-01-10 Thread Lukas Märdian
What series is this needed for? Does it already work as expected in
Jammy?

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

Title:
  The airplane hotkey has no function on a HP platform

Status in OEM Priority Project:
  Triaged
Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]
  The airplane hokey doesn't work on HP new generation machines.

  [Test Plan]
  Press airplane hokey.

  Before the patch, nothing happens.
  After the patch, the rfkill works as expected.

  [Where problems could occur]
  In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will 
not work but HP confirmed the new HP generation won't contain the HPQ6001 and 
also each DM still need to deal with multi-rfkill events because upstream 
changes[2].

  ---

  In the last year, HP mentions HP machines need to use hp-wireless
  (HPQ6001) as the rfkill source[1].

  However, HP confirms the HPQ6001 has been retired in the platforms
  since 2022.

  In the platforms after 2022, there are two sources of rkfill events 
(intel-hid, atkbd) and HP only guarantee the intel-hid works.
  Therefore, the upstream already accept the patch[2] to unmask intel-hid and 
mention this big change in the NEWS.

  This change makes the pre-2022 HP platforms meet the regression since they 
have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing 
function key.
  Thus, there is a patch[3] to make sure the GNOME could deal with this case 
smoothly.
  However, the systemd change will still cause other DEs meet the regression 
(xfce, KDE, lxde, etc..).
  Backport systemd change to make HP 2022 platforms work is not the best choice 
on stable version (focal in this case).

  We still need a solution to make airplane key works on 2022 HP platforms 
(intel-hid and atkbd only).
  The potential solution from my mind that is to maintain a whitelist to unmask 
intel-hid in ubuntu-patch in focal, something like:
  ```
  evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:*
   KEYBOARD_KEY_8=wlan # Use hp-wireless instead
  ```
  after "KEYBOARD_KEY_8=unkown".

  [1] https://bugs.launchpad.net/bugs/1883846
  [2] https://github.com/systemd/systemd/pull/20219
  [3] 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1955997/+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 1943561] Re: Add ACCEL_LOCATION=base property for 6 Dell clamshell models

2022-01-05 Thread Lukas Märdian
We cannot prepare & verify an SRU for Hirsute within the two weeks left
before EOL, so I'm marking this task wontfix.

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

Title:
  Add ACCEL_LOCATION=base property for 6 Dell clamshell models

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Fix Released
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  This hwdb update is to avoid unwanted screen rotation when tilting the
  laptop.

  This is the update to the previously rolled back SRU LP: #1938259

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A36, 0A3E, 0B09, 0B0B, 0B0D, 0B11, install 
this package and ensure the kernel is updated to the latest.
   * Screen should be correct side up in login screen and desktop.
   * Tilt the laptop and the screen should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * Only models with the same Dell SKU would be affected.

  [scope]

  this is needed for all releases

  this is being added to upstream by
  https://github.com/systemd/systemd/pull/20314 and
  https://github.com/systemd/systemd/pull/20661

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1943561/+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 1952599] Re: virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

2022-01-05 Thread Lukas Märdian
We cannot prepare & verify an SRU for Hirsute within the two weeks left
before EOL, so I'm marking this task wontfix.

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

Title:
  virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

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 Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Fix Released
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [Impact]

   * The detection of Microsoft Hyper-V VMs is done by cpuid currently,
  however there is no cpuid on ARM64. And since ARM64 is now a supported
  architecture for Microsoft Hyper-V guests[0], then introduce a more
  generic way to detect whether a guest is running as a Hyper-V guest: check 
  if /sys/class/dmi/id/product_version starts with "Hyper-V".

   * This bug has already been fixed upstream[1][2]

  [Test Plan]

   * While changes have been made in the kernel for ARM64 on Hyper-V,
  there is no way to start an ARM64 VM on Hyper-V at the moment. Thus we
  just want to make sure no regression is introduced.

   * start an Hyper-V amd64 VM and make sure "systemd-detect-virt" still
  return MSFT (should still rely on cpuid here)

  [Where problems could occur]

   * The main risk is for the system to detect Hyper-V virt erroneously.
  An issue was reported upstream after the first commit was merged[3].
  For this reason, systemd is now looking for "Hyper-V" (in
  /sys/class/dmi/id/product_version) and not "Microsoft" (in
  /sys/class/dmi/id/bios_vendor)

   * This change might also break virt detection on hyper-v AMD64.
  That's why we need testing. However, AMD64 virt detection should still
  rely on cpuid instead of DMI as cpuid takes priority over DMI.

  [0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7aff79e297ee1aa0126924921fd87a4ae59d2467
  [1] https://github.com/systemd/systemd/pull/20998/files
  [2] https://github.com/systemd/systemd/pull/21475/files
  [3] https://github.com/systemd/systemd/issues/21468

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1952599/+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 1952733] Re: Add Dell Privacy Mic Mute Key mapping for another Dell machine

2022-01-05 Thread Lukas Märdian
We cannot prepare & verify an SRU for Hirsute within the two weeks left
before EOL, so I'm marking this task wontfix.

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

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

Title:
  Add Dell Privacy Mic Mute Key mapping for another Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Fix Released
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952733/+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 1952735] Re: Add Microphone mute key mapping for Dell machine

2022-01-05 Thread Lukas Märdian
We cannot prepare & verify an SRU for Hirsute within the two weeks left
before EOL, so I'm marking this task wontfix.

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

Title:
  Add Microphone mute key mapping for Dell machine

Status in OEM Priority Project:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Fix Released
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [Impact]

   * Dell machine add new microphone mute key on keyboard, add this key mapping 
to make it work.
  [Test Plan]

   * Use a Dell machine, which has this microphone mute key, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952735/+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 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2022-01-05 Thread Lukas Märdian
There is some news about this issue at systemd:
https://github.com/systemd/systemd/issues/15316#issuecomment-1000842001

Could people try to place this systemd override config for dbus and
observe if it avoids the issue?

```
$ cat /etc/systemd/system/dbus.service.d/override.conf
[Service]
Environment=SYSTEMD_NSS_DYNAMIC_BYPASS=1
```

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in D-Bus:
  Unknown
Status in systemd:
  New
Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Incomplete
Status in gnome-shell package in Ubuntu:
  Invalid
Status in accountsservice source package in Focal:
  Invalid
Status in dbus source package in Focal:
  Incomplete
Status in gnome-shell source package in Focal:
  Invalid
Status in accountsservice source package in Groovy:
  Invalid
Status in dbus source package in Groovy:
  Incomplete
Status in gnome-shell source package in Groovy:
  Invalid
Status in accountsservice source package in Hirsute:
  Invalid
Status in dbus source package in Hirsute:
  Incomplete
Status in gnome-shell source package in Hirsute:
  Invalid
Status in accountsservice source package in Impish:
  Invalid
Status in dbus source package in Impish:
  Incomplete
Status in gnome-shell source package in Impish:
  Invalid

Bug description:
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  
  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time 
threads.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via 
systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=>
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request 
repeated too quickly.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit 
Scheduling Policy Service.
  Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53

  
  But that already was only triggered by a gnome restart that kicked of earlier:

  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on 
Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
is initialized.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Wayland 
Session.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
(session: gnome-login).

  
  X was recycleing before:
  Apr 08 06:09:19 Keschdeichel systemd[10683]: Stopping GNOME Shell on X11...
  ...
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (EE) 
systemd-logind: ReleaseControl failed: Unknown object 
'/org/freedesktop/login1/session/_32'.
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (II) Server 
terminated successfully (0). Closing log file.

  
  It seems like some internal service broke and everything that followed was a 
secondary issue to 

[Touch-packages] [Bug 1944711] Re: restarting systemd-logind loses all existing sessions

2022-01-04 Thread Lukas Märdian
Thank you Michael for the verification. I can confirm this is working as
expected as of systemd 245.4-4ubuntu3.14 from (focal-proposed)

slyon@ff:~$ dpkg -l | grep systemd
[...]
ii  systemd245.4-4ubuntu3.14 amd64
slyon@ff:~$ loginctl list-sessions
SESSION  UID USER  SEAT TTY  
 c2 1001 slyon  pts/1

1 sessions listed.

root@ff:~# systemctl restart systemd-logind

slyon@ff:~$ loginctl list-sessions
SESSION  UID USER  SEAT TTY  
 c2 1001 slyon  pts/1

1 sessions listed.

The networking after resume issue indeed seems to be unrelated.

** Tags removed: verification-needed-focal
** Tags added: 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/1944711

Title:
  restarting systemd-logind loses all existing sessions

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

Bug description:
  [impact]

  restarting the systemd-logind service loses all existing sessions

  [test case]

  ubuntu@test-f:~$ loginctl list-sessions
  SESSION  UID USER   SEAT TTY
     3789 1000 ubuntu  pts/0

  1 sessions listed.
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  ubuntu@test-f:~$ sudo systemctl restart systemd-logind
  ubuntu@test-f:~$ journalctl -b -u systemd-logind
  -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 
UTC. --
  Sep 23 11:22:51 test-f systemd[1]: Starting Login Service...
  Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0.
  Sep 23 11:22:51 test-f systemd[1]: Started Login Service.
  Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu.
  Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service...
  Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded.
  Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service.
  Sep 23 11:23:07 test-f systemd[1]: Starting Login Service...
  Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 
1000, ignoring: Invalid argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid 
argument
  Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known.
  Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No 
such file or directory
  Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0.
  Sep 23 11:23:07 test-f systemd[1]: Started Login Service.
  ubuntu@test-f:~$ loginctl list-sessions
  No sessions.

  [regression potential]

  any regression would likely occur during a systemd-logind restart,
  likely causing a loss of current login sessions.

  [scope]

  this is needed only in f

  this is fixed upstream by commit
  ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246, so
  this is fixed in h and later already.

  in b, the function used to parse the /run/systemd/users/* files allows
  either usernames or uids, so this bug does not exist there

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1944711/+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 1650688] Re: timedatectl set-timezone fails on UC16

2021-12-16 Thread Lukas Märdian
Thank you very much Ratchanan for the verification on Bionic & Focal. I
re-triggered those autopkgtest and they are now resolved.

** Tags removed: verification-needed-bionic verification-needed-focal
** Tags added: 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/1650688

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
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 Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The timedated itself is likely used by the programs that involves
  in time-related functions. If a crash occur, in the worst case users
  won't be able to set time or timezone via timedated. However, users
  should still be able to e.g. set time using `date` or set timezone
  using /etc/localtime (assuming online guides still consider systems
  without systemd). Timedated is DBus-activated, and thus a crash should
  be self-healing.

   * The set part would also affects the clasic systems. However, I
  believe nothing else actually rely on /etc/localtime being a relative
  path, otherwise the /etc/writable redirection would causes even more
  problem, and would have been reported.

  [3] Yes, I'm surprised that there's a DHCP server inside systemd
  codebase.

  [Other Info]

   * This is also useful for UBports's Ubuntu Touch. We continue using
  system-image system where the rootfs is read-only, and thus is
  affected by this bug similarly to Ubuntu Core. I've tested the Focal
  version of the package on our (currently in development) Focal Ubuntu
  Touch image, and the fix works.

  

  [Original bug description]

  On a system running UC16, the file /etc/localtime is a link that
  points to /etc/writable/localtime.

  On a freshly installed system, /etc/writable/localtime is a fully-
  qualified link that points at /usr/share/zoneinfo/UTC.

  If timedatectl is used to set the timezone to something else,
  timedated updates the 

[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16

2021-12-13 Thread Lukas Märdian
The investigation started just recently. I do not expect a fix to be
landed soon.

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

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
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 Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The timedated itself is likely used by the programs that involves
  in time-related functions. If a crash occur, in the worst case users
  won't be able to set time or timezone via timedated. However, users
  should still be able to e.g. set time using `date` or set timezone
  using /etc/localtime (assuming online guides still consider systems
  without systemd). Timedated is DBus-activated, and thus a crash should
  be self-healing.

   * The set part would also affects the clasic systems. However, I
  believe nothing else actually rely on /etc/localtime being a relative
  path, otherwise the /etc/writable redirection would causes even more
  problem, and would have been reported.

  [3] Yes, I'm surprised that there's a DHCP server inside systemd
  codebase.

  [Other Info]

   * This is also useful for UBports's Ubuntu Touch. We continue using
  system-image system where the rootfs is read-only, and thus is
  affected by this bug similarly to Ubuntu Core. I've tested the Focal
  version of the package on our (currently in development) Focal Ubuntu
  Touch image, and the fix works.

  

  [Original bug description]

  On a system running UC16, the file /etc/localtime is a link that
  points to /etc/writable/localtime.

  On a freshly installed system, /etc/writable/localtime is a fully-
  qualified link that points at /usr/share/zoneinfo/UTC.

  If timedatectl is used to set the timezone to something else,
  timedated updates the localtime symbolic link with a relative path to
  the zoneinfo directory, which results in an invalid link.

  $ sudo timedatectl set-timezone America/Detroit

  $ sudo timedatectl
  

[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16

2021-12-10 Thread Lukas Märdian
The workarounds for read-only /etc/ are only needed in Ubuntu Core /
system-image / UBports environments (/etc/writable doesn't exist on
classic systems), that are based on the LTS releases. Therefore, I'm
marking the Hirsute and Impish tasks as WONTFIX.

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

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

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The timedated itself is likely used by the programs that involves
  in time-related functions. If a crash occur, in the worst case users
  won't be able to set time or timezone via timedated. However, users
  should still be able to e.g. set time using `date` or set timezone
  using /etc/localtime (assuming online guides still consider systems
  without systemd). Timedated is DBus-activated, and thus a crash should
  be self-healing.

   * The set part would also affects the clasic systems. However, I
  believe nothing else actually rely on /etc/localtime being a relative
  path, otherwise the /etc/writable redirection would causes even more
  problem, and would have been reported.

  [3] Yes, I'm surprised that there's a DHCP server inside systemd
  codebase.

  [Other Info]

   * This is also useful for UBports's Ubuntu Touch. We continue using
  system-image system where the rootfs is read-only, and thus is
  affected by this bug similarly to Ubuntu Core. I've tested the Focal
  version of the package on our (currently in development) Focal Ubuntu
  Touch image, and the fix works.

  

  [Original bug description]

  On a system running UC16, the file /etc/localtime is a link that
  points to /etc/writable/localtime.

  On a freshly installed system, /etc/writable/localtime is a fully-
  qualified link that points 

[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16

2021-12-09 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
   Status: Confirmed => In Progress

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

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

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The timedated itself is likely used by the programs that involves
  in time-related functions. If a crash occur, in the worst case users
  won't be able to set time or timezone via timedated. However, users
  should still be able to e.g. set time using `date` or set timezone
  using /etc/localtime (assuming online guides still consider systems
  without systemd). Timedated is DBus-activated, and thus a crash should
  be self-healing.

   * The set part would also affects the clasic systems. However, I
  believe nothing else actually rely on /etc/localtime being a relative
  path, otherwise the /etc/writable redirection would causes even more
  problem, and would have been reported.

  [3] Yes, I'm surprised that there's a DHCP server inside systemd
  codebase.

  [Other Info]

   * This is also useful for UBports's Ubuntu Touch. We continue using
  system-image system where the rootfs is read-only, and thus is
  affected by this bug similarly to Ubuntu Core. I've tested the Focal
  version of the package on our (currently in development) Focal Ubuntu
  Touch image, and the fix works.

  

  [Original bug description]

  On a system running UC16, the file /etc/localtime is a link that
  points to /etc/writable/localtime.

  On a freshly installed system, /etc/writable/localtime is a fully-
  qualified link that points at /usr/share/zoneinfo/UTC.

  If timedatectl is used to set the timezone to something else,
  timedated updates the localtime symbolic link with a relative path to
  the zoneinfo directory, which results in an invalid link.

  $ sudo timedatectl 

[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16

2021-12-07 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Lukas Märdian (slyon)

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

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

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

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

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

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  Confirmed

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The timedated itself is likely used by the programs that involves
  in time-related functions. If a crash occur, in the worst case users
  won't be able to set time or timezone via timedated. However, users
  should still be able to e.g. set time using `date` or set timezone
  using /etc/localtime (assuming online guides still consider systems
  without systemd). Timedated is DBus-activated, and thus a crash should
  be self-healing.

   * The set part would also affects the clasic systems. However, I
  believe nothing else actually rely on /etc/localtime being a relative
  path, otherwise the /etc/writable redirection would causes even more
  problem, and would have been reported.

  [3] Yes, I'm surprised that there's a DHCP server inside systemd
  codebase.

  [Other Info]

   * This is also useful for UBports's Ubuntu Touch. We continue using
  system-image system where the rootfs is read-only, and thus is
  affected by this bug similarly to Ubuntu Core. I've tested the Focal
  version of the package on our (currently in development) Focal Ubuntu
  Touch image, and the fix works.

  

  [Original bug description]

  On a system running UC16, the file /etc/localtime is a link that
  points to /etc/writable/localtime.

  On a freshly installed system, /etc/writable/localtime is a fully-
  qualif

[Touch-packages] [Bug 1952733] Re: Add Dell Privacy Mic Mute Key mapping for another Dell machine

2021-12-07 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Lukas Märdian (slyon)

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

Title:
  Add Dell Privacy Mic Mute Key mapping for another Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952733/+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 1943561] Re: Add ACCEL_LOCATION=base property for 6 Dell clamshell models

2021-12-07 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Lukas Märdian (slyon)

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

Title:
  Add ACCEL_LOCATION=base property for 6 Dell clamshell models

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  This hwdb update is to avoid unwanted screen rotation when tilting the
  laptop.

  This is the update to the previously rolled back SRU LP: #1938259

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A36, 0A3E, 0B09, 0B0B, 0B0D, 0B11, install 
this package and ensure the kernel is updated to the latest.
   * Screen should be correct side up in login screen and desktop.
   * Tilt the laptop and the screen should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * Only models with the same Dell SKU would be affected.

  [scope]

  this is needed for all releases

  this is being added to upstream by
  https://github.com/systemd/systemd/pull/20314 and
  https://github.com/systemd/systemd/pull/20661

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1943561/+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 1952735] Re: Add Microphone mute key mapping for Dell machine

2021-12-07 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Lukas Märdian (slyon)

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

Title:
  Add Microphone mute key mapping for Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

   * Dell machine add new microphone mute key on keyboard, add this key mapping 
to make it work.
  [Test Plan]

   * Use a Dell machine, which has this microphone mute key, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952735/+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 1952599] Re: virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

2021-12-07 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Lukas Märdian (slyon)

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

Title:
  virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

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

Bug description:
  [Impact]

   * The detection of Microsoft Hyper-V VMs is done by cpuid currently,
  however there is no cpuid on ARM64. And since ARM64 is now a supported
  architecture for Microsoft Hyper-V guests[0], then introduce a more
  generic way to detect whether a guest is running as a Hyper-V guest: check 
  if /sys/class/dmi/id/product_version starts with "Hyper-V".

   * This bug has already been fixed upstream[1][2]

  [Test Plan]

   * While changes have been made in the kernel for ARM64 on Hyper-V,
  there is no way to start an ARM64 VM on Hyper-V at the moment. Thus we
  just want to make sure no regression is introduced.

   * start an Hyper-V amd64 VM and make sure "systemd-detect-virt" still
  return MSFT (should still rely on cpuid here)

  [Where problems could occur]

   * The main risk is for the system to detect Hyper-V virt erroneously.
  An issue was reported upstream after the first commit was merged[3].
  For this reason, systemd is now looking for "Hyper-V" (in
  /sys/class/dmi/id/product_version) and not "Microsoft" (in
  /sys/class/dmi/id/bios_vendor)

   * This change might also break virt detection on hyper-v AMD64.
  That's why we need testing. However, AMD64 virt detection should still
  rely on cpuid instead of DMI as cpuid takes priority over DMI.

  [0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7aff79e297ee1aa0126924921fd87a4ae59d2467
  [1] https://github.com/systemd/systemd/pull/20998/files
  [2] https://github.com/systemd/systemd/pull/21475/files
  [3] https://github.com/systemd/systemd/issues/21468

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1952599/+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 1650688] Re: timedatectl set-timezone fails on UC16

2021-12-03 Thread Lukas Märdian
I'm pretty much with @ddstreet here, introducing another hack to handle
Ubuntu Core quirks is not nice, as those hacks will make our systemd
more unstable over time and will break regularly after merging upstream
changes.

As stated before, we already carry such hacks since 2014 and I just want
to give a brief quote from that long standing patch: "Forwarded: OMGno,
this is a rather nasty hack until we fix system-image to get a writable
/etc" – I do not know a lot about Ubuntu Core's file system hierarchy
and why it deviates from the common setup, but maybe getting a writable
/etc is the core problem to solve here, as stated by @pitti in 2014
already.

IIUC we currently have a workaround by @ogra in place that only applies to the 
"timedatectl" CLI, the proposed MRs would fix this for the "timedatectl" CLI 
and the systemd-timedated DBus API. But what about other tools that assume 
/etc/localtime to be handled like on most other common systems? Do we start 
patching every application now and teach them about Ubuntu Core's /etc/writable 
quirks, e.g. glibc's "tzset(3)"?
That cannot be the correct path forward...

OTOH those MRs are rather small and clear and they solve an issue for
our users NOW (tho only one part of the issue that is related to
systemd-timedate).

As a compromise I guess I would be willing to accept the current patches
into Jammy (so they can be SRUed afterwards), IF we have a clear path
forward about solving this problem properly and replacing the hack with
an upstream solution in the not too distant future – hopefully dropping
the other long-standing /etc/writable patch at the same time.

The snapd team (Michael/Valentin) recently started investigating proper
upstream solutions to this problem (thanks for that!) and I asked
Valentin to create a tracking bug for us, that we can reference
alongside those new hacks, so we can drop them once a better solution is
in place: https://bugs.launchpad.net/snappy/+bug/1953172

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

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Jammy:
  Confirmed

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The 

[Touch-packages] [Bug 1943561] Re: Add ACCEL_LOCATION=base property for 6 Dell clamshell models

2021-12-02 Thread Lukas Märdian
Thanks for the clarification. Now it all makes sense to me (as Impish is
on kernel >= 3.13) and it means that the revert wasn't actually needed
for Impish.

So on Impish I will apply the same patch as in Jammy, which is basically
the same that was reverted before due to a mistake in SRU verification.
In addition to the new commit, adding 4 additional matches.

That will remove the 2 modalias name matches and replace them by 6 new
SKU matches that can be detected on kernel >= 3.13.

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

Title:
  Add ACCEL_LOCATION=base property for 6 Dell clamshell models

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  This hwdb update is to avoid unwanted screen rotation when tilting the
  laptop.

  This is the update to the previously rolled back SRU LP: #1938259

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A36, 0A3E, 0B09, 0B0B, 0B0D, 0B11, install 
this package and ensure the kernel is updated to the latest.
   * Screen should be correct side up in login screen and desktop.
   * Tilt the laptop and the screen should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * Only models with the same Dell SKU would be affected.

  [scope]

  this is needed for all releases

  this is being added to upstream by
  https://github.com/systemd/systemd/pull/20314 and
  https://github.com/systemd/systemd/pull/20661

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1943561/+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 1952733] Re: Add Dell Privacy Mic Mute Key mapping for another Dell machine

2021-12-02 Thread Lukas Märdian
Thanks! I'm taking the upstream commit
https://github.com/systemd/systemd/commit/5ed0ea29287621fb3c51b7917c34c7b8ac280eba
(LP: #1926547) instead of squeezing that change into the Impish/systemd
v248 debdiff. Otherwise this LGTM!

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

Title:
  Add Dell Privacy Mic Mute Key mapping for another Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952733/+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 1943561] Re: Add ACCEL_LOCATION=base property for 6 Dell clamshell models

2021-12-02 Thread Lukas Märdian
Hey, thank you for providing an updated patch!

I've included it in todays systemd v249 upload in jammy:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-jammy=9f99081482b76a7b717e39ef4380f08093e4359a

Jammy uses kernel 5.15 so it is fine to drop the modalias names and rely
on SKU alone (as is done upstream).

For Focal and Hirsute you're only adding the new SKU matches, which
should be fine, too.

But I'm wondering what exactly is the situation on Impish? Impish uses
kernel 3.13 so the SKU kernel change should be included and the same fix
as posted above for Jammy should apply. But OTOH in
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1938259/comments/15
you mentioned that the SRU uploaded last time (that removes the modalias
names) regressed in Impish.

Could you please clarify this situation for Impish, or ideally provide a
debdiff as you did for the other series? Thanks!

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

Title:
  Add ACCEL_LOCATION=base property for 6 Dell clamshell models

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  This hwdb update is to avoid unwanted screen rotation when tilting the
  laptop.

  This is the update to the previously rolled back SRU LP: #1938259

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A36, 0A3E, 0B09, 0B0B, 0B0D, 0B11, install 
this package and ensure the kernel is updated to the latest.
   * Screen should be correct side up in login screen and desktop.
   * Tilt the laptop and the screen should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * Only models with the same Dell SKU would be affected.

  [scope]

  this is needed for all releases

  this is being added to upstream by
  https://github.com/systemd/systemd/pull/20314 and
  https://github.com/systemd/systemd/pull/20661

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1943561/+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 1926547] Re: Add Dell Privacy Mic Mute Key mapping

2021-12-02 Thread Lukas Märdian
This affects Impish as well. The commit was included in upstream v249.

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

Title:
  Add Dell Privacy Mic Mute Key mapping

Status in OEM Priority Project:
  Fix Released
Status in OEM Priority Project focal series:
  Fix Released
Status in systemd package in Ubuntu:
  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
Status in systemd source package in Impish:
  New

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
     GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * The change can only work with kernel commit on some specific hardware, ex. 
Latitude 9520. The commit series is 
"hardware-privacy-implementation-for-dell-laptop" in alsa-devel kernel tree.
     https://patchwork.kernel.org/project/alsa-devel/list/?series=465445
   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1926547/+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 1926547] Re: Add Dell Privacy Mic Mute Key mapping

2021-12-02 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

Title:
  Add Dell Privacy Mic Mute Key mapping

Status in OEM Priority Project:
  Fix Released
Status in OEM Priority Project focal series:
  Fix Released
Status in systemd package in Ubuntu:
  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
Status in systemd source package in Impish:
  New

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
     GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * The change can only work with kernel commit on some specific hardware, ex. 
Latitude 9520. The commit series is 
"hardware-privacy-implementation-for-dell-laptop" in alsa-devel kernel tree.
     https://patchwork.kernel.org/project/alsa-devel/list/?series=465445
   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1926547/+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 1952733] Re: Add Dell Privacy Mic Mute Key mapping for another Dell machine

2021-12-02 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

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

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

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

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

Title:
  Add Dell Privacy Mic Mute Key mapping for another Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952733/+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 1952735] Re: Add Microphone mute key mapping for Dell machine

2021-12-02 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

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

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

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

Title:
  Add Microphone mute key mapping for Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

   * Dell machine add new microphone mute key on keyboard, add this key mapping 
to make it work.
  [Test Plan]

   * Use a Dell machine, which has this microphone mute key, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952735/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers

2021-12-02 Thread Lukas Märdian
Yes.. LXD's system containers and systemd/udev have a special kind of
relationship and we should strive to resolve that situation properly
long-term. I already talked to stgraber about that, but I guess we
should lay out a proper path forward as continuously patching more and
more components of systemd is not a sustainable approach.

I'll leave that new revert-patch in for now, tho, as we do not have
another short-term solution.

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1943561] Re: Add ACCEL_LOCATION=base property for 6 Dell clamshell models

2021-12-02 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

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

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

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

Title:
  Add ACCEL_LOCATION=base property for 6 Dell clamshell models

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  New
Status in systemd source package in Hirsute:
  New
Status in systemd source package in Impish:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  This hwdb update is to avoid unwanted screen rotation when tilting the
  laptop.

  This is the update to the previously rolled back SRU LP: #1938259

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A36, 0A3E, 0B09, 0B0B, 0B0D, 0B11, install 
this package and ensure the kernel is updated to the latest.
   * Screen should be correct side up in login screen and desktop.
   * Tilt the laptop and the screen should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * Only models with the same Dell SKU would be affected.

  [scope]

  this is needed for all releases

  this is being added to upstream by
  https://github.com/systemd/systemd/pull/20314 and
  https://github.com/systemd/systemd/pull/20661

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1943561/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950511] Re: FTBFS due to meson disallowing + for bools

2021-12-02 Thread Lukas Märdian
released in 249.5-2ubuntu1

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

Title:
  FTBFS due to meson disallowing + for bools

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

Bug description:
  FTBFS with new meson:

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950511/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-12-02 Thread Lukas Märdian
** Changed in: systemd (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1952733] Re: Add Dell Privacy Mic Mute Key mapping for another Dell machine

2021-12-01 Thread Lukas Märdian
** Tags added: fr-1896

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

Title:
  Add Dell Privacy Mic Mute Key mapping for another Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]

   * Dell introduces new function called Dell Privacy, it utilizes
  hardware mute to control audio and camera. The commit map the reported
  key event to mic mute for making userspace can work as before, "Mic
  Mute" dialog pop-up while the mic mute button is pressed.

  [Test Plan]

   * Use a Dell machine, which has Dell privacy function, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952733/+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 1952735] Re: Add Microphone mute key mapping for Dell machine

2021-12-01 Thread Lukas Märdian
** Tags added: fr-1897

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

Title:
  Add Microphone mute key mapping for Dell machine

Status in OEM Priority Project:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]

   * Dell machine add new microphone mute key on keyboard, add this key mapping 
to make it work.
  [Test Plan]

   * Use a Dell machine, which has this microphone mute key, and press mic mute 
key.
 GUI will pop up "Mic Mute" icon.

  [Where problems could occur]

   * This change adds key event mapping in hwdb, which won't impact
  other hardware.

   any regression would likely cause problems with key(s) from the
  specific dell kb matching the modified listing in the hw db.

  [Other Info]

   * This change has been verified on Dell machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1952735/+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 1943561] Re: Add ACCEL_LOCATION=base property for 6 Dell clamshell models

2021-12-01 Thread Lukas Märdian
** Tags added: fr-1895

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

Title:
  Add ACCEL_LOCATION=base property for 6 Dell clamshell models

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This hwdb update is to avoid unwanted screen rotation when tilting the
  laptop.

  This is the update to the previously rolled back SRU LP: #1938259

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A36, 0A3E, 0B09, 0B0B, 0B0D, 0B11, install 
this package and ensure the kernel is updated to the latest.
   * Screen should be correct side up in login screen and desktop.
   * Tilt the laptop and the screen should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * Only models with the same Dell SKU would be affected.

  [scope]

  this is needed for all releases

  this is being added to upstream by
  https://github.com/systemd/systemd/pull/20314 and
  https://github.com/systemd/systemd/pull/20661

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1943561/+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 1951653] Re: can't use NM for ethernet device on 20.04 LTS because it is 'strictly unmanaged'

2021-11-29 Thread Lukas Märdian
Yes, indeed. NetworkManager tries to control all interfaces that are
available by default and netplan implemented some quirks in the past to
avoid this. But we should review those quirks and rather implement a
per-interface/netdef deny- or accept-list.

** Tags added: fr-1888

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

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

Title:
  can't use NM for ethernet device on 20.04 LTS because it is 'strictly
  unmanaged'

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

Bug description:
  I have tried to tell netplan to let my ethernet device be managed by
  NetworkManager, so that I can then configure a pppoe connection on top
  of this device.

  This fails with:

  # nmcli c up netplan-wan
  Error: Connection activation failed: No suitable device found for this 
connection (device lo not available because device is strictly unmanaged).
  #

  I don't know why it mentions 'lo' in that message, but the wan
  interface is unmanaged (as are all devices on the system, but this one
  is supposed to be managed):

  # nmcli d status | grep wan
  wan   ethernet  unmanaged  -- 
  #

  After much searching, I've figured out that this comes from
  /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf:

  keyfile]
  unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma

  Even though I've told netplan to use the NM renderer for this device,
  the configuration emitted by netplan is insufficient to override this.

  Using the workaround from
  https://askubuntu.com/questions/71159/network-manager-says-device-not-
  managed (sudo touch /etc/NetworkManager/conf.d/10-globally-managed-
  devices.conf) doesn't work, but if I set NetworkManager as the
  toplevel renderer in /etc/netplan,
  /run/NetworkManager/conf.d/10-globally-managed-devices.conf is
  emitted, which evidently DOES work.  But I only have one device that I
  want rendered by NM, so I shouldn't have to declare NM at the top
  level of the yaml with a lot of duplication in order to get this
  result.

  I would argue that the 10-globally-managed-devices.conf should not be
  there at all.  But if it is going to be, then netplan needs to
  consistently override it whenever there is any use of the
  NetworkManager backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1951653/+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 1952599] Re: virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

2021-11-29 Thread Lukas Märdian
** Tags added: fr-1886

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

Title:
  virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

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

Bug description:
  [Impact]

   * The detection of Microsoft Hyper-V VMs is done by cpuid currently,
  however there is no cpuid on ARM64. And since ARM64 is now a supported
  architecture for Microsoft Hyper-V guests[0], then introduce a more
  generic way to detect whether a guest is running as a Hyper-V guest: check 
  if /sys/class/dmi/id/product_version starts with "Hyper-V".

   * This bug has already been fixed upstream[1][2]

  [Test Plan]

   * While changes have been made in the kernel for ARM64 on Hyper-V,
  there is no way to start an ARM64 VM on Hyper-V at the moment. Thus we
  just want to make sure no regression is introduced.

   * start an Hyper-V amd64 VM and make sure "systemd-detect-virt" still
  return MSFT (should still rely on cpuid here)

  [Where problems could occur]

   * The main risk is for the system to detect Hyper-V virt erroneously.
  An issue was reported upstream after the first commit was merged[3].
  For this reason, systemd is now looking for "Hyper-V" (in
  /sys/class/dmi/id/product_version) and not "Microsoft" (in
  /sys/class/dmi/id/bios_vendor)

   * This change might also break virt detection on hyper-v AMD64.
  That's why we need testing. However, AMD64 virt detection should still
  rely on cpuid instead of DMI as cpuid takes priority over DMI.

  [0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7aff79e297ee1aa0126924921fd87a4ae59d2467
  [1] https://github.com/systemd/systemd/pull/20998/files
  [2] https://github.com/systemd/systemd/pull/21475/files
  [3] https://github.com/systemd/systemd/issues/21468

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1952599/+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 1952599] Re: virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

2021-11-29 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

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

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

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

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

Title:
  virt: Support detection for ARM64 Hyper-V guests (fixed upstream)

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

Bug description:
  [Impact]

   * The detection of Microsoft Hyper-V VMs is done by cpuid currently,
  however there is no cpuid on ARM64. And since ARM64 is now a supported
  architecture for Microsoft Hyper-V guests[0], then introduce a more
  generic way to detect whether a guest is running as a Hyper-V guest: check 
  if /sys/class/dmi/id/product_version starts with "Hyper-V".

   * This bug has already been fixed upstream[1][2]

  [Test Plan]

   * While changes have been made in the kernel for ARM64 on Hyper-V,
  there is no way to start an ARM64 VM on Hyper-V at the moment. Thus we
  just want to make sure no regression is introduced.

   * start an Hyper-V amd64 VM and make sure "systemd-detect-virt" still
  return MSFT (should still rely on cpuid here)

  [Where problems could occur]

   * The main risk is for the system to detect Hyper-V virt erroneously.
  An issue was reported upstream after the first commit was merged[3].
  For this reason, systemd is now looking for "Hyper-V" (in
  /sys/class/dmi/id/product_version) and not "Microsoft" (in
  /sys/class/dmi/id/bios_vendor)

   * This change might also break virt detection on hyper-v AMD64.
  That's why we need testing. However, AMD64 virt detection should still
  rely on cpuid instead of DMI as cpuid takes priority over DMI.

  [0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7aff79e297ee1aa0126924921fd87a4ae59d2467
  [1] https://github.com/systemd/systemd/pull/20998/files
  [2] https://github.com/systemd/systemd/pull/21475/files
  [3] https://github.com/systemd/systemd/issues/21468

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1952599/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950511] Re: FTBFS due to meson disallowing + for bools

2021-11-26 Thread Lukas Märdian
This is already included in v249.5 stable, that is to be uploaded soon.
(https://git.launchpad.net/~slyon/ubuntu/+source/systemd/log/?h=ubuntu-
jammy-249)

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

Title:
  FTBFS due to meson disallowing + for bools

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

Bug description:
  FTBFS with new meson:

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950511/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1650688] Re: timedatectl set-timezone fails on UC16

2021-11-25 Thread Lukas Märdian
** Tags added: fr-1885

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

Title:
  timedatectl set-timezone fails on UC16

Status in Snappy:
  Triaged
Status in systemd package in Ubuntu:
  New

Bug description:
  SRU
  ===

  [Impact]

   * The bug prevents timedated from recognizing and correctly set the
  system's timezone when running Ubuntu Core 16, 18 and 20.

   * This causes by timedated fails to take Ubuntu Core's /etc/writable
  redirection into account.

   * The recognizing part is fixed by making the code take writable
  redirection into account.

   * The set part is fixed by making the code link to the absolute path
  instead of a relative one.

   * Currently core snaps worked around the set part by providing a
  wrapper script which re-create /etc/writable/localtime afterward.
  However this does not cover DBus users.

  [Test Plan]

   * On classics systems: ensure the proposed systemd package is installed.
     On Ubuntu Core systems: build a new core snap including proposed package, 
and install it. Replaces timedatectl with timedatectl.real to test skipping the 
wrapper.

  (Note that one can simulate core snap's /etc/writable redirection by
  running this image creation hook [1] on the system.)

  [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-
  core/hooks/08-etc-writable.chroot?h=ubuntu/focal

   * On freshly boot system: query the timezone using `timedatectl`. The
  timezone should corresponds to `readlink -f /etc/localtime` and does
  not show `n/a`.

   * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`.
  `readlink -f /etc/localtime` should points to an existing file.

   * Run `sudo systemctl restart systemd-timedated.service`. Then, query
  the timezone again: `timedatectl`. It should show the previously set
  timezone and not `n/a`.

   * Run `sudo systemctl status systemd-timedated.service`. This should
  show no sign of timedated crashing.

  [Where problems could occur]

   * It's possible that the redirection handling code will be sub-par
  and causes crash. However, it's not likely because the similar pieces
  of code is in the previous patch since Ubuntu 16.04.

   * If it does: the patched `get_timezone()` function is used in 2
  places: the networkd's DHCP server [3] and the timedated itself.

     - Networkd is used primarily on servers where NetworkManage is
  absent. It's possible that this patch causes the user to loss access
  to the server due to networkd crash when setting up network
  interfaces, and requires physical access to fix. However, the code
  path is executed when DHCP is enabled only. I think it's not common
  for users to have networkd's DHCP server enabled: the feature seems to
  gear towards desktop users wanting to share internet connection, and
  in those cases they're more likely to use NetworkManager.

     - The timedated itself is likely used by the programs that involves
  in time-related functions. If a crash occur, in the worst case users
  won't be able to set time or timezone via timedated. However, users
  should still be able to e.g. set time using `date` or set timezone
  using /etc/localtime (assuming online guides still consider systems
  without systemd). Timedated is DBus-activated, and thus a crash should
  be self-healing.

   * The set part would also affects the clasic systems. However, I
  believe nothing else actually rely on /etc/localtime being a relative
  path, otherwise the /etc/writable redirection would causes even more
  problem, and would have been reported.

  [3] Yes, I'm surprised that there's a DHCP server inside systemd
  codebase.

  [Other Info]

   * This is also useful for UBports's Ubuntu Touch. We continue using
  system-image system where the rootfs is read-only, and thus is
  affected by this bug similarly to Ubuntu Core. I've tested the Focal
  version of the package on our (currently in development) Focal Ubuntu
  Touch image, and the fix works.

  

  [Original bug description]

  On a system running UC16, the file /etc/localtime is a link that
  points to /etc/writable/localtime.

  On a freshly installed system, /etc/writable/localtime is a fully-
  qualified link that points at /usr/share/zoneinfo/UTC.

  If timedatectl is used to set the timezone to something else,
  timedated updates the localtime symbolic link with a relative path to
  the zoneinfo directory, which results in an invalid link.

  $ sudo timedatectl set-timezone America/Detroit

  $ sudo timedatectl
    Local time: Fri 2016-12-16 18:18:49 EST
    Universal time: Fri 2016-12-16 23:18:49 UTC
  RTC time: Fri 2016-12-16 23:18:49
     Time zone: America/Detroit (EST, -0500)
   Network time on: yes
  NTP synchronized: yes
   RTC in local TZ: no

  $ ls -l /etc/writable/localtime
  /etc/writable/localtime --> 

[Touch-packages] [Bug 1951214] Re: ubuntu-bug isn't opening firefox (snap) on jammy, instead gedit gets data

2021-11-25 Thread Lukas Märdian
** Tags added: fr-1884

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

Title:
  ubuntu-bug isn't opening firefox (snap) on jammy, instead gedit gets
  data

Status in apport package in Ubuntu:
  Confirmed

Bug description:
  This has been reported before on Ubuntu Community Hub, but I want/need
  a bug report filed on launchpad to report/track on iso.qa.ubuntu.com

  On a `ubuntu-bug` or apport opening up a bug report; a gedit window
  opens with

  ---
  
  
OpenID transaction in progress
  
  
  https://login.launchpad.net/+openid; method="post" 
accept-charset="UTF-8" enctype="application/x-www-form-urlencoded">http://openid.net/extensions/sreg/1.1"/>https://launchpad.net/+openid-callback?starting_url=https%3A%2F%2Fbugs.launchpad.net%2Fsubiquity%2F%2Bfilebug%2Ff55a6274-4767-11ec-a1ce-d485646cd9a4%3Ffield.title%3Dinstall%2Bfailed%2Bcrashed%2Bwith%2BCalledProcessErrorjanrain_nonce=2021-11-17T05%3A34%3A05Zo24b46"/>https://launchpad.net/"/>http://specs.openid.net/auth/2.0/identifier_select"/>http://specs.openid.net/auth/2.0"/>http://specs.openid.net/auth/2.0/identifier_select"/>
  
  var elements = document.forms[0].elements;
  for (var i = 0; i < elements.length; i++) {
elements[i].style.display = "none";
  }
  
  
  
  ---

  this is detail that belongs in `firefox` and not `gedit` ... ie. bug.

  This issue is NOT new.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: apport 2.20.11-0ubuntu73
  ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
  Uname: Linux 5.13.0-19-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportLog:
   ERROR: apport (pid 2820) Wed Nov 17 16:33:33 2021: called for pid 2593, 
signal 11, core limit 0, dump mode 1
   ERROR: apport (pid 2820) Wed Nov 17 16:33:33 2021: executable: 
/snap/ubuntu-desktop-installer/171/bin/ubuntu_desktop_installer (command line 
"/snap/ubuntu-desktop-installer/171/bin/ubuntu_desktop_installer")
   ERROR: apport (pid 2820) Wed Nov 17 16:33:33 2021: executable does not 
belong to a package, ignoring
  ApportVersion: 2.20.11-0ubuntu73
  Architecture: amd64
  CasperMD5CheckResult: pass
  CasperVersion: 1.465+canary3.3
  CrashReports:
   644:0:0:30:2021-11-17 16:33:08.496906043 +1100:2021-11-17 16:33:08.496906043 
+1100:/var/crash/1637127188.494807005.install_fail.meta
   640:0:0:726809:2021-11-17 16:33:41.277731657 +1100:2021-11-17 
16:33:42.277731657 +1100:/var/crash/1637127188.494807005.install_fail.crash
   644:0:0:0:2021-11-17 16:33:45.953817607 +1100:2021-11-17 16:33:45.953817607 
+1100:/var/crash/1637127188.494807005.install_fail.upload
   600:116:123:5:2021-11-17 16:48:24.898416884 +1100:2021-11-17 
16:33:45.953817607 +1100:/var/crash/1637127188.494807005.install_fail.uploaded
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov 17 16:52:32 2021
  LiveMediaBuild: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (2026)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1951214/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers

2021-11-22 Thread Lukas Märdian
** Changed in: systemd (Ubuntu)
   Status: New => Fix Committed

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2021-11-18 Thread Lukas Märdian
I'm still suspecting dbus to be at fault here. We might need to bisect
dbus in order to find out more about this, but that is hard without a
reliable reproducer.

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in D-Bus:
  Unknown
Status in systemd:
  New
Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Incomplete
Status in gnome-shell package in Ubuntu:
  Invalid
Status in accountsservice source package in Focal:
  Invalid
Status in dbus source package in Focal:
  Incomplete
Status in gnome-shell source package in Focal:
  Invalid
Status in accountsservice source package in Groovy:
  Invalid
Status in dbus source package in Groovy:
  Incomplete
Status in gnome-shell source package in Groovy:
  Invalid
Status in accountsservice source package in Hirsute:
  Invalid
Status in dbus source package in Hirsute:
  Incomplete
Status in gnome-shell source package in Hirsute:
  Invalid
Status in accountsservice source package in Impish:
  Invalid
Status in dbus source package in Impish:
  Incomplete
Status in gnome-shell source package in Impish:
  Invalid

Bug description:
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  
  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time 
threads.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via 
systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=>
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request 
repeated too quickly.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit 
Scheduling Policy Service.
  Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53

  
  But that already was only triggered by a gnome restart that kicked of earlier:

  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on 
Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
is initialized.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Wayland 
Session.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
(session: gnome-login).

  
  X was recycleing before:
  Apr 08 06:09:19 Keschdeichel systemd[10683]: Stopping GNOME Shell on X11...
  ...
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (EE) 
systemd-logind: ReleaseControl failed: Unknown object 
'/org/freedesktop/login1/session/_32'.
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (II) Server 
terminated successfully (0). Closing log file.

  
  It seems like some internal service broke and everything that followed was a 
secondary issue to that:
  Apr 08 06:09:19 Keschdeichel systemd[1]: NetworkManager.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel 

[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-18 Thread Lukas Märdian
Thanks ddstreet, I agree 918e6f1c0151429f5095355f4f3f74f16e79724a could
be related as well, but unfortunately that commit produced quite some
fall-out.

Nevertheless, I've prepared a new systemd build in my PPA and the
"core18_2028_amd64.snap" at https://people.ubuntu.com/~slyon/uc18/
cherry-picking the changes from

https://github.com/systemd/systemd/pull/8675 (incl. 918e6f1c)

As I said, there are quite some other PRs related to this, in order to clean-up 
after it
https://github.com/systemd/systemd/pull/8798
https://github.com/systemd/systemd/pull/9200
https://github.com/systemd/systemd/pull/9229
https://github.com/systemd/systemd/pull/9366

In total that should be approx. 1000 changed LOC... So I'm not sure how
suitable this is for SRU. But let's first give this newest build a try
and check if the initial commit/PR changes anything wrt to our core
problem here, if so we can into the details of those backports (and
hopefully skip manny commits of those).

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers

2021-11-17 Thread Lukas Märdian
Reverting this upstream commit seems to fix the problem:
https://github.com/systemd/systemd/commit/0299deab53d2a087727a5d04c1500c322c48b63e

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers

2021-11-17 Thread Lukas Märdian
Turns out dropping "debian/patches/units-Don-t-start-systemd-udev-
trigger.service-in-a-conta.patch" (that we want to drop anyway) makes a
difference here, i.e. removing the "ConditionVirtualization=!container"
line from /usr/lib/systemd/service/systemd-udev-trigger.service.

# apt install systemd udev # upgrade systemd & udev to v249
# systemctl restart systemd-udev-trigger # run the 'udevadm trigger' commands
# systemctl restart systemd-networkd # restart networkd to re-run the DHCPv4 
client.


That is even though the systemd-udev-trigger.service fails to execute 
successfully:
# systemctl status systemd-udev-trigger.service
● systemd-udev-trigger.service - Coldplug All udev Devices
 Loaded: loaded (/lib/systemd/system/systemd-udev-trigger.service; static)
 Active: active (exited) since Wed 2021-11-17 09:39:01 UTC; 37s ago
   Docs: man:udev(7)
 man:systemd-udevd.service(8)
Process: 74 ExecStart=udevadm trigger --type=subsystems --action=add 
(code=exited, status=1/FAILURE)
Process: 101 ExecStart=udevadm trigger --type=devices --action=add 
(code=exited, status=1/FAILURE)
   Main PID: 101 (code=exited, status=1/FAILURE)
CPU: 160ms

Nov 17 09:39:01 jj2 udevadm[101]: nvme-delete-wq: Failed to write 'add' to 
'/sys/devices/virtual/workqueue/nvme-delete-wq/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: nvme-reset-wq: Failed to write 'add' to 
'/sys/devices/virtual/workqueue/nvme-reset-wq/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: nvme-wq: Failed to write 'add' to 
'/sys/devices/virtual/workqueue/nvme-wq/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: raid5wq: Failed to write 'add' to 
'/sys/devices/virtual/workqueue/raid5wq/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: scsi_tmf_0: Failed to write 'add' to 
'/sys/devices/virtual/workqueue/scsi_tmf_0/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: writeback: Failed to write 'add' to 
'/sys/devices/virtual/workqueue/writeback/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: dm-0: Failed to write 'add' to 
'/sys/devices/virtual/block/dm-0/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: dm-1: Failed to write 'add' to 
'/sys/devices/virtual/block/dm-1/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: dm-2: Failed to write 'add' to 
'/sys/devices/virtual/block/dm-2/uevent': Permission denied
Nov 17 09:39:01 jj2 udevadm[101]: dm-3: Failed to write 'add' to 
'/sys/devices/virtual/block/dm-3/uevent': Permission denied

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-15 Thread Lukas Märdian
Thank you, having a reliable reproducer is very helpful! I can confirm
this reproduces locally for me on QEMU.

I prepared a new systemd package [0], containing backports from the
above mentioned PR that indeed sounds very related (I wonder why the
issue didn't happen before, tho, as this is unrelated to any recent
SRU). Using this package, I prepared a new '2025' core18 base snap
[1] and a corresponding UC18 image [2] for further testing.

With this systemd version the reproducer passes for me with no problem.
So I guess it's worth giving this another try with the full spread test.

[0] https://launchpad.net/~slyon/+archive/ubuntu/lp1949089
[1] https://people.ubuntu.com/~slyon/uc18/core18_2025_amd64.snap
[2] https://people.ubuntu.com/~slyon/uc18/uc18-2025+systemd+3G.img.xz

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Lukas Märdian
I've implemented the workaround in systemd's debian/test/tests-in-lxd.

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

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

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

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950794] [NEW] DHCPv4 (IAID+DUID) networking broken in LXC containers

2021-11-12 Thread Lukas Märdian
Public bug reported:

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

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

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

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

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

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

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

** Attachment added: "debug.log"
   https://bugs.launchpad.net/bugs/1950794/+attachment/5540425/+files/debug.log

** Summary changed:

- DHCPv4 networking broken in LXC containers (IAID+DUID / ClientIdentifier=duid)
+ DHCPv4 (IAID+DUID) networking broken in LXC containers

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

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Lukas Märdian
This commit seems to be related:
https://github.com/lxc/distrobuilder/commit/33a4302ca5a62ed9eb9009dcc5059aecfb55ba41
But why does it not work in privileged containers?

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

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

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Lukas Märdian
** Attachment added: "debug.log"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950787/+attachment/5540415/+files/debug.log

** Description changed:

  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
+ ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
+ ```
  
  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"
  
  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=
  
  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

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

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] [NEW] systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Lukas Märdian
Public bug reported:

systemd-sysusers.service/systemd.exec fails to start in privileged containers, 
due to being unable to properly mount /dev for passing credentials, caused by 
the following config in the .service unit:
```
# Optionally, pick up a root password and shell for the root user from a
# credential passed to the service manager. This is useful for importing this
# data from nspawn's --set-credential= switch.
LoadCredential=passwd.hashed-password.root
LoadCredential=passwd.plaintext-password.root
LoadCredential=passwd.shell.root
```

Reproducer:
$ lxc profile set default security.privileged "true"
$ lxc launch ubuntu-daily:jammy test
$ lxc exec test bash
# add-apt-repository ppa:ci-train-ppa-service/4704
# apt install systemd # install systemd 249.5-2ubuntu1
# systemctl restart systemd-sysusers
# systemctl status systemd-sysusers
# system --status=failed
$ lxc profile set default security.privileged "false"

A workaround is to disable it via:
$ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
[Service]
LoadCredential=

Interesting logs:
Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) to 
fd store.
Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

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

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

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

** Description changed:

  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  
  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"
  
  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=
  
  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning
- 
- Debug logs:
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Job 350 
systemd-sysusers.service/restart finished, result=done
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Converting job 
systemd-sysusers.service/restart -> systemd-sysusers.service/start
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: 
ConditionNeedsUpdate=/etc succeeded.
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Passing 0 fds to 
service
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: About to execute 
systemd-sysusers
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Forked 
systemd-sysusers as 430
- Nov 12 12:09:44 test systemd[430]: Successfully forked off '(sd-mkdcreds)' as 
PID 431.
- Nov 12 12:09:44 test systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/systemd_2dsysusers_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
- Nov 12 12:09:44 test systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/systemd_2dsysusers_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=8 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
- Nov 12 12:09:44 test 

[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-08 Thread Lukas Märdian
** No longer affects: systemd (Ubuntu Jammy)

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-08 Thread Lukas Märdian
That's certainly possible. In the first attempt (that failed according
to mvo's tests) I only backported

https://github.com/systemd/systemd-stable/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0
and
https://github.com/systemd/systemd-stable/commit/cc6271f17d3c5c200e8a391f10d0afb71403fc28
 (as a dependency)

It is quite possible that we need to backport even more commits to fix
this without reverting LP: #1934147

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-08 Thread Lukas Märdian
Thank you for testing the revert!
Do we know if the same issue happens in Focal/UC20 as well? Or can we somehow 
falsify that? The regressing patches had been introduced to 
Hirsute/Focal/Bionic to fix LP: #1934147

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-08 Thread Lukas Märdian
** Merge proposal linked:
   
https://code.launchpad.net/~slyon/ubuntu/+source/systemd/+git/systemd/+merge/411528

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-05 Thread Lukas Märdian
Sounds like we cannot have an easy fix by simply applying
04eb582acc203eab0bc5c2cc5e13986f16e09df0 (and its dependencies).

So let's first try to pinpoint if f0831ed2a03fcef582660be1c3b1a9f3e267e656 
really introduced the regression. I've built a new core18 snap with my previous 
work and the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 (and 
dependencies) reverted:
https://people.ubuntu.com/~slyon/uc18/core18_20211105_amd64.snap

Could you please give this another try?

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-05 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

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

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1948476] Re: [SRU] Allow target units to fail

2021-11-05 Thread Lukas Märdian
Thank you Alfonso, I staged this patch for the next Focal SRU:
https://git.launchpad.net/~ubuntu-core-
dev/ubuntu/+source/systemd/commit/?h=ubuntu-
focal=fe0cb0bd66baea89d8bbe47cb47d88540f46d470

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

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

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

Title:
  [SRU] Allow target units to fail

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

Bug description:
  [Impact]

  A systemd regression in focal made it think that target units cannot
  fail, which produced warnings like:

  emergency.target: Requested dependency OnFailure=reboot.target ignored
  (target units cannot fail).

  So the OnFailure settings are ignored for targets (see
  https://github.com/snapcore/core-initrd/issues/33 for details).
  Upstream fixed the issue in v246:
  
https://github.com/systemd/systemd/commit/94d1ddbd7cd15b1073757eb5ae0645c83f0b414c

  [Test Plan]

  Test on a UC system and check that the above warnings are not shown
  anymore. Check that when a target service type fails, the OnFailure
  setting is used and the mentioned service is run.

  [Where problems could occur]

  Issues might happen if some target has an OnFailure setting that was
  never run in the past because of this bug, and the behavior is not
  really right because it was never tested. However, OnFailure is not
  used that much on 20.04 in target services:

  /lib/systemd $ find . -name \*.target | xargs grep OnFailure
  /lib/systemd $ 
  /etc/systemd $ find . -name \*.target | xargs grep OnFailure
  /etc/systemd $ 

  I've seen it only in emergency.target for UC20.

  [Other Info]
   
  None

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1948476/+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 1948476] Re: [SRU] Allow target units to fail

2021-11-05 Thread Lukas Märdian
** Also affects: systemd (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

Title:
  [SRU] Allow target units to fail

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

Bug description:
  [Impact]

  A systemd regression in focal made it think that target units cannot
  fail, which produced warnings like:

  emergency.target: Requested dependency OnFailure=reboot.target ignored
  (target units cannot fail).

  So the OnFailure settings are ignored for targets (see
  https://github.com/snapcore/core-initrd/issues/33 for details).
  Upstream fixed the issue in v246:
  
https://github.com/systemd/systemd/commit/94d1ddbd7cd15b1073757eb5ae0645c83f0b414c

  [Test Plan]

  Test on a UC system and check that the above warnings are not shown
  anymore. Check that when a target service type fails, the OnFailure
  setting is used and the mentioned service is run.

  [Where problems could occur]

  Issues might happen if some target has an OnFailure setting that was
  never run in the past because of this bug, and the behavior is not
  really right because it was never tested. However, OnFailure is not
  used that much on 20.04 in target services:

  /lib/systemd $ find . -name \*.target | xargs grep OnFailure
  /lib/systemd $ 
  /etc/systemd $ find . -name \*.target | xargs grep OnFailure
  /etc/systemd $ 

  I've seen it only in emergency.target for UC20.

  [Other Info]
   
  None

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1948476/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-04 Thread Lukas Märdian
Sure, I put that custom core18 snap into
https://people.ubuntu.com/~slyon/uc18/ as well.

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

Status in systemd package in Ubuntu:
  New

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18

2021-11-02 Thread Lukas Märdian
Not having a reliable reproducer is always a tricky situation to be
in...

Indeed that other commit might be related. I've backported the following
patches and created a custom systemd build in
https://launchpad.net/~slyon/+archive/ubuntu/lp1949089

https://github.com/systemd/systemd-stable/commit/cc6271f17d3c5c200e8a391f10d0afb71403fc28
https://github.com/systemd/systemd-stable/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

Can you confirm that the problems you observed are gone using this
systemd build?

There's also a custom UC18 image I assembled, that contains this version
of systemd: https://people.ubuntu.com/~slyon/uc18/

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

Title:
  systemd randomly fails to activate mount units in Ubuntu Core 18

Status in systemd package in Ubuntu:
  New

Bug description:
  Since a month or so, we've been seeing random failures in our snapd
  spread tests where systemd could not start the mount unit associated
  with a snap because of a failed dependency.

  The issue is described in the comments to PR
  https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
  here.

  When starting a snap, snapd creates a mount unit to mount the snap's
  squashfs (the template is
  
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
  The snapd asks systemd to reload the configuration, and starts the
  mount unit.

  The failure we've observed is that sometimes systemd decides to stop
  our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
  flip-flop" in the attached log), and then tries to reactivate it
  again, and at that point it fails.

  When I asked for help, Lukas pointed out that the latest update
  contains a patch that is related to reload handling and mount units:
  
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
  (the patch itself is better visible at
  
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
  When looking at the systemd git log, though, I noticed another patch
  that was applied shortly after this one, which also seems related but
  was not backported:
  
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0

  Since the stopping of our mount unit happens immediately after a
  systemd reload, it actually seems very likely that the inclusion of
  f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
  causes our woes (though, indeed, the issue is not reliably
  reproducible, so we cannot be sure).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1945969] Re: Update Vala to 0.52.6 in Impish

2021-10-21 Thread Lukas Märdian
** Changed in: libunity (Ubuntu Impish)
   Status: In Progress => Won't Fix

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

Title:
  Update Vala to 0.52.6 in Impish

Status in libunity package in Ubuntu:
  Fix Released
Status in vala package in Ubuntu:
  Fix Released
Status in libunity source package in Impish:
  Won't Fix
Status in vala source package in Impish:
  Fix Released

Bug description:
  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala

  Upstream changes since 0.52.5:

  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
    - codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
    - vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
    - valadoc: Correctly format background of inline @link's [#1226]

   * Bindings:
    - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
    - gio-2.0: Backport fixes from 0.54.2
    - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
    - glib-2.0: Add RefString since 2.58 [#723]
    - gtk4: Backport fixes from 0.54.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1945969/+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 1944741] Re: HiFive Unmatched partitions are named "Unleashed"

2021-10-18 Thread Lukas Märdian
** Also affects: util-linux (Ubuntu Jammy)
   Importance: Low
   Status: New

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

Title:
  HiFive Unmatched partitions are named "Unleashed"

Status in util-linux package in Ubuntu:
  New
Status in util-linux source package in Impish:
  Fix Committed
Status in util-linux source package in Jammy:
  New
Status in util-linux package in Debian:
  Confirmed

Bug description:
  [Impact]  
   

   
  Both HiFive Unleashed and HiFive Unmatched bootloaders seek for the same  
   
  UUIDs to load the next stage bootloader: the current name makes partitions
   
  on Unmatched board appear as 'Unleashed'. 
   

   
  This issue gives the feeling that the Ubuntu RISC-V images made specifically  
   
  for those 2 boards were assembled in a rushed manner. 
   

   
  The attached patch fixes this by removing the 'Unleashed' part of the current 
   
  name so that it fits both, it was build againt all architectures here:
   
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+sourcepub/12783067/+listing-archive-extra

   
  [Test Plan]   
   

   
  1. Download the SiFive Unmatched image here: 
https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/pending/impish-preinstalled-server-riscv64+unmatched.img.xz
  2. Follow instructions here to launch a riscv64 VM: 
https://wiki.ubuntu.com/RISC-V
  3. Execute the following command: 
   
  ubuntu@ubuntu:~$ sudo fdisk -l
   
  Disk /dev/vda: 40 GiB, 42949672960 bytes, 83886080 sectors
   
  Units: sectors of 1 * 512 = 512 bytes 
   
  Sector size (logical/physical): 512 bytes / 512 bytes 
   
  I/O size (minimum/optimal): 512 bytes / 512 bytes 
   
  Disklabel type: gpt   
   
  Disk identifier: 0F66C0C3-A5E4-439B-907E-ABAD106FE4A7 
   

   
  Device  Start  End  Sectors  Size Type
   
  /dev/vda1  235554 83886046 83650493 39.9G Linux filesystem
   
  /dev/vda12 227362   235553 81924M Linux filesystem
   
  /dev/vda13 34 2081 20481M HiFive Unleashed FSBL   
   
  /dev/vda14   208210273 81924M HiFive Unleashed BBL
   
  /dev/vda15  10274   227361   217088  106M EFI System  
   

   
  Partition table entries are not in disk order.
   
  4. Download and install the new packages that contain the fix here:   
   
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+files/libfdisk1_2.36.1-8ubuntu4_riscv64.deb
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+files/libfdisk-dev_2.36.1-8ubuntu4_riscv64.deb
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+files/fdisk_2.36.1-8ubuntu4_riscv64.deb
  5. Re-execute the same command as above:  
   
  ubuntu@ubuntu:~$ sudo fdisk -l
   
  Disk /dev/vda: 40 GiB, 42949672960 bytes, 83886080 sectors
   
  Units: sectors of 1 * 512 = 512 bytes 
   
  Sector size (logical/physical): 512 bytes / 512 bytes 
   
  I/O size (minimum/optimal): 512 bytes / 512 bytes 
   
  Disklabel type: gpt   
   
  Disk identifier: 0F66C0C3-A5E4-439B-907E-ABAD106FE4A7 
   

   
  Device  Start  End  Sectors  Size Type
   
  /dev/vda1  235554 83886046 83650493 39.9G Linux filesystem
   
  /dev/vda12 227362   235553 81924M Linux filesystem
   
  

[Touch-packages] [Bug 1945969] Re: Update to 0.52.6 in impish

2021-10-13 Thread Lukas Märdian
No need for 0-day SRU. This has been sponsored into Debian unstable and
will be synced to Ubuntu. Thanks @seb128!

https://tracker.debian.org/news/1266939/accepted-
libunity-714190420190319-6-source-into-unstable/

** Summary changed:

- FTBFS with valac 0.52.6 in impish
+ Update to 0.52.6 in impish

** Description changed:

- [Impact]
- 
-  * libunity FTBFS using valac 0.52.6, which makes it hard to apply any
- (security) updates in a timely manner.
- 
- [Test Plan]
- 
-  * Check the Launchpad build logs to make sure that libunity
- 7.1.4+19.04.20190319-6 built successfully
-  * Attach build logs to this bug
- 
- [Where problems could occur]
- 
-  * The build could still fail for some reason and we would be back to
- status quo.
- 
- [Other Info]
- 
-  * I'm hijacking this valac bug for the libunity 0-day SRU
-  * PPA pre-testing has been done here: 
https://launchpad.net/~slyon/+archive/ubuntu/testing/+sourcepub/12784335/+listing-archive-extra
- 
- 
- === Original Bug Description ===
- 
  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala
  
  Upstream changes since 0.52.5:
  
  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
    - codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
    - vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
    - valadoc: Correctly format background of inline @link's [#1226]
  
   * Bindings:
    - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
    - gio-2.0: Backport fixes from 0.54.2
    - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
    - glib-2.0: Add RefString since 2.58 [#723]
    - gtk4: Backport fixes from 0.54.2

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

Title:
  Update to 0.52.6 in impish

Status in libunity package in Ubuntu:
  Fix Committed
Status in vala package in Ubuntu:
  Fix Released
Status in libunity source package in Impish:
  Fix Committed
Status in vala source package in Impish:
  Fix Released

Bug description:
  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala

  Upstream changes since 0.52.5:

  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
    - codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
    - vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
    - valadoc: Correctly format background of inline @link's [#1226]

   * Bindings:
    - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
    - gio-2.0: Backport fixes from 0.54.2
    - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
    - glib-2.0: Add RefString since 2.58 [#723]
    - gtk4: Backport fixes from 0.54.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1945969/+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 1945969] Re: FTBFS with valac 0.52.6 in impish

2021-10-13 Thread Lukas Märdian
** Summary changed:

- Update to 0.52.6 in impish
+ FTBFS with valac 0.52.6 in impish

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

Title:
  FTBFS with valac 0.52.6 in impish

Status in libunity package in Ubuntu:
  Fix Committed
Status in vala package in Ubuntu:
  Fix Released
Status in libunity source package in Impish:
  Fix Committed
Status in vala source package in Impish:
  Fix Released

Bug description:
  [Impact]

   * libunity FTBFS using valac 0.52.6, which makes it hard to apply any
  (security) updates in a timely manner.

  [Test Plan]

   * Check the Launchpad build logs to make sure that libunity
  7.1.4+19.04.20190319-6 built successfully
   * Attach build logs to this bug

  [Where problems could occur]

   * The build could still fail for some reason and we would be back to
  status quo.

  [Other Info]

   * I'm hijacking this valac bug for the libunity 0-day SRU
   * PPA pre-testing has been done here: 
https://launchpad.net/~slyon/+archive/ubuntu/testing/+sourcepub/12784335/+listing-archive-extra

  
  === Original Bug Description ===

  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala

  Upstream changes since 0.52.5:

  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
    - codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
    - vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
    - valadoc: Correctly format background of inline @link's [#1226]

   * Bindings:
    - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
    - gio-2.0: Backport fixes from 0.54.2
    - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
    - glib-2.0: Add RefString since 2.58 [#723]
    - gtk4: Backport fixes from 0.54.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1945969/+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 1945969] Re: Update to 0.52.6 in impish

2021-10-13 Thread Lukas Märdian
** Also affects: vala (Ubuntu Impish)
   Importance: High
 Assignee: Rico Tzschichholz (ricotz)
   Status: Fix Released

** Also affects: libunity (Ubuntu Impish)
   Importance: High
 Assignee: Lukas Märdian (slyon)
   Status: Fix Committed

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

Title:
  Update to 0.52.6 in impish

Status in libunity package in Ubuntu:
  Fix Committed
Status in vala package in Ubuntu:
  Fix Released
Status in libunity source package in Impish:
  Fix Committed
Status in vala source package in Impish:
  Fix Released

Bug description:
  [Impact]

   * libunity FTBFS using valac 0.52.6, which makes it hard to apply any
  (security) updates in a timely manner.

  [Test Plan]

   * Check the Launchpad build logs to make sure that libunity
  7.1.4+19.04.20190319-6 built successfully
   * Attach build logs to this bug

  [Where problems could occur]

   * The build could still fail for some reason and we would be back to
  status quo.

  [Other Info]

   * I'm hijacking this valac bug for the libunity 0-day SRU
   * PPA pre-testing has been done here: 
https://launchpad.net/~slyon/+archive/ubuntu/testing/+sourcepub/12784335/+listing-archive-extra

  
  === Original Bug Description ===

  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala

  Upstream changes since 0.52.5:

  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
    - codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
    - vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
    - valadoc: Correctly format background of inline @link's [#1226]

   * Bindings:
    - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
    - gio-2.0: Backport fixes from 0.54.2
    - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
    - glib-2.0: Add RefString since 2.58 [#723]
    - gtk4: Backport fixes from 0.54.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1945969/+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 1945969] Re: Update to 0.52.6 in impish

2021-10-13 Thread Lukas Märdian
This is a FTBFS fix for libunity that could become an impish 0-day SRU.

PPA pre-testing has been done here:
https://launchpad.net/~slyon/+archive/ubuntu/testing/+sourcepub/12784335/+listing-
archive-extra

** Description changed:

+ [Impact]
+ 
+  * libunity FTBFS using valac 0.52.6, which makes it hard to apply any
+ (security) updates in a timely manner.
+ 
+ [Test Plan]
+ 
+  * Check the Launchpad build logs to make sure that libunity
+ 7.1.4+19.04.20190319-6 built successfully
+  * Attach build logs to this bug
+ 
+ [Where problems could occur]
+ 
+  * The build could still fail for some reason and we would be back to
+ status quo.
+ 
+ [Other Info]
+ 
+  * I'm hijacking this valac bug for the libunity 0-day SRU
+  * PPA pre-testing has been done here: 
https://launchpad.net/~slyon/+archive/ubuntu/testing/+sourcepub/12784335/+listing-archive-extra
+ 
+ 
+ === Original Bug Description ===
+ 
  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala
  
  Upstream changes since 0.52.5:
  
  Vala 0.52.6
  ===
-  * Various improvements and bug fixes:
-   - codegen:
- + Fix property access inside opaque compact class
- + Add type declaration for implicit temporary local variable
-   - vala:
- + Warn about unsupported cast to void and drop it [#1070]
- + Don't restrict element type of GLib.Array [#1227]
- + Multi-dimensional params-array not allowed [#1230]
- + Accept NullType as generic type argument
- + Set source references of created DataType instances in OCE
-   - valadoc: Correctly format background of inline @link's [#1226]
+  * Various improvements and bug fixes:
+   - codegen:
+ + Fix property access inside opaque compact class
+ + Add type declaration for implicit temporary local variable
+   - vala:
+ + Warn about unsupported cast to void and drop it [#1070]
+ + Don't restrict element type of GLib.Array [#1227]
+ + Multi-dimensional params-array not allowed [#1230]
+ + Accept NullType as generic type argument
+ + Set source references of created DataType instances in OCE
+   - valadoc: Correctly format background of inline @link's [#1226]
  
-  * Bindings:
-   - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
-   - gio-2.0: Backport fixes from 0.54.2
-   - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
-   - glib-2.0: Add RefString since 2.58 [#723]
-   - gtk4: Backport fixes from 0.54.2
+  * Bindings:
+   - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
+   - gio-2.0: Backport fixes from 0.54.2
+   - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
+   - glib-2.0: Add RefString since 2.58 [#723]
+   - gtk4: Backport fixes from 0.54.2

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

Title:
  Update to 0.52.6 in impish

Status in libunity package in Ubuntu:
  Fix Committed
Status in vala package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

   * libunity FTBFS using valac 0.52.6, which makes it hard to apply any
  (security) updates in a timely manner.

  [Test Plan]

   * Check the Launchpad build logs to make sure that libunity
  7.1.4+19.04.20190319-6 built successfully
   * Attach build logs to this bug

  [Where problems could occur]

   * The build could still fail for some reason and we would be back to
  status quo.

  [Other Info]

   * I'm hijacking this valac bug for the libunity 0-day SRU
   * PPA pre-testing has been done here: 
https://launchpad.net/~slyon/+archive/ubuntu/testing/+sourcepub/12784335/+listing-archive-extra

  
  === Original Bug Description ===

  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala

  Upstream changes since 0.52.5:

  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
    - codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
    - vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
    - valadoc: Correctly format background of inline @link's [#1226]

   * Bindings:
    - gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
    - gio-2.0: Backport fixes from 0.54.2
    - glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
    - glib-2.0: Add RefString since 2.58 [#723]
    - gtk4: Backport fixes from 0.54.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1945969/+subscriptions


-- 

[Touch-packages] [Bug 1944741] Re: HiFive Unmatched partitions are named "Unleashed"

2021-10-12 Thread Lukas Märdian
Thank you! You changes LGTM.
The first patch resembles the upstream commit, the 2nd patch (that touches the 
translation files) is not yet merged upstream, but makes sense.

With all builds passing in a PPA and a successful autopkgtest run, I'll
stage this to be a 0-day SRU, as discussed with the release team.

$ dput ubuntu ../util-linux_2.36.1-8ubuntu2_source.changes 
D: Setting host argument.
Checking signature on .changes
gpg: ../util-linux_2.36.1-8ubuntu2_source.changes: Valid signature from 
5889C17AB1C8D890
Checking signature on .dsc
gpg: ../util-linux_2.36.1-8ubuntu2.dsc: Valid signature from 5889C17AB1C8D890
Uploading to ubuntu (via sftp to upload.ubuntu.com):
  Uploading util-linux_2.36.1-8ubuntu2.dsc: done.
  Uploading util-linux_2.36.1-8ubuntu2.debian.tar.xz: done.
  Uploading util-linux_2.36.1-8ubuntu2_source.buildinfo: done. 
  Uploading util-linux_2.36.1-8ubuntu2_source.changes: done.
Successfully uploaded packages.

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

Title:
  HiFive Unmatched partitions are named "Unleashed"

Status in util-linux package in Ubuntu:
  New
Status in util-linux source package in Impish:
  New
Status in util-linux package in Debian:
  Confirmed

Bug description:
  [Impact]  
   

   
  Both HiFive Unleashed and HiFive Unmatched bootloaders seek for the same  
   
  UUIDs to load the next stage bootloader: the current name makes partitions
   
  on Unmatched board appear as 'Unleashed'. 
   

   
  This issue gives the feeling that the Ubuntu RISC-V images made specifically  
   
  for those 2 boards were assembled in a rushed manner. 
   

   
  The attached patch fixes this by removing the 'Unleashed' part of the current 
   
  name so that it fits both, it was build againt all architectures here:
   
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+sourcepub/12783067/+listing-archive-extra

   
  [Test Plan]   
   

   
  1. Download the SiFive Unmatched image here: 
https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/pending/impish-preinstalled-server-riscv64+unmatched.img.xz
  2. Follow instructions here to launch a riscv64 VM: 
https://wiki.ubuntu.com/RISC-V
  3. Execute the following command: 
   
  ubuntu@ubuntu:~$ sudo fdisk -l
   
  Disk /dev/vda: 40 GiB, 42949672960 bytes, 83886080 sectors
   
  Units: sectors of 1 * 512 = 512 bytes 
   
  Sector size (logical/physical): 512 bytes / 512 bytes 
   
  I/O size (minimum/optimal): 512 bytes / 512 bytes 
   
  Disklabel type: gpt   
   
  Disk identifier: 0F66C0C3-A5E4-439B-907E-ABAD106FE4A7 
   

   
  Device  Start  End  Sectors  Size Type
   
  /dev/vda1  235554 83886046 83650493 39.9G Linux filesystem
   
  /dev/vda12 227362   235553 81924M Linux filesystem
   
  /dev/vda13 34 2081 20481M HiFive Unleashed FSBL   
   
  /dev/vda14   208210273 81924M HiFive Unleashed BBL
   
  /dev/vda15  10274   227361   217088  106M EFI System  
   

   
  Partition table entries are not in disk order.
   
  4. Download and install the new packages that contain the fix here:   
   
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+files/libfdisk1_2.36.1-8ubuntu4_riscv64.deb
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+files/libfdisk-dev_2.36.1-8ubuntu4_riscv64.deb
  
https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+files/fdisk_2.36.1-8ubuntu4_riscv64.deb
  5. Re-execute the same command as above:  
   
  ubuntu@ubuntu:~$ sudo fdisk -l
   
  Disk /dev/vda: 40 GiB, 42949672960 bytes, 

[Touch-packages] [Bug 1944741] Re: HiFive Unmatched partitions are named "Unleashed"

2021-10-11 Thread Lukas Märdian
** Also affects: util-linux (Ubuntu Impish)
   Importance: Low
   Status: New

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

Title:
  HiFive Unmatched partitions are named "Unleashed"

Status in util-linux package in Ubuntu:
  New
Status in util-linux source package in Impish:
  New
Status in util-linux package in Debian:
  Confirmed

Bug description:
  Both HiFive Unleashed and HiFive Unmatched bootloaders seek for the same
  UUIDs to load the next stage bootloader: the current name makes partitions
  on Unmatched board appear as 'Unleashed'.
  
  Fix that by removing the 'Unleashed' part of the current name so that it
  fits both.

  The attached debdiff contains the patch that was merged upstream
  (https://github.com/karelzak/util-
  linux/commit/10fd91d389497d8be435cc66abbdeb2eb6ea2f07).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1944741/+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 1945969] Re: Update to 0.52.6 in impish

2021-10-11 Thread Lukas Märdian
** Also affects: libunity (Ubuntu)
   Importance: Undecided
   Status: New

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

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

Title:
  Update to 0.52.6 in impish

Status in libunity package in Ubuntu:
  New
Status in vala package in Ubuntu:
  Fix Released

Bug description:
  The 0.52.x series is receiving further bug fix releases for GNOME 40.x.
  See https://wiki.gnome.org/Projects/Vala

  Upstream changes since 0.52.5:

  Vala 0.52.6
  ===
   * Various improvements and bug fixes:
- codegen:
  + Fix property access inside opaque compact class
  + Add type declaration for implicit temporary local variable
- vala:
  + Warn about unsupported cast to void and drop it [#1070]
  + Don't restrict element type of GLib.Array [#1227]
  + Multi-dimensional params-array not allowed [#1230]
  + Accept NullType as generic type argument
  + Set source references of created DataType instances in OCE
- valadoc: Correctly format background of inline @link's [#1226]

   * Bindings:
- gio-2.0: Unhide a few usable symbols which are marked not introspectable 
[#1222]
- gio-2.0: Backport fixes from 0.54.2
- glib-2.0: Current constants in GLib.Math are part of glib.h [#1220]
- glib-2.0: Add RefString since 2.58 [#723]
- gtk4: Backport fixes from 0.54.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1945969/+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 1664818] Re: Not possible to render pre-up, pre-down, post-up, or post-down snippets

2021-10-05 Thread Lukas Märdian
There is some documentation around how to implement this with netplan
here: https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts

But its basically using the underlying renderer's (NM or networkd-
dispatcher) hooks, as netplan itself is not a networking daemon and
cannot easily listen to netlink changes.

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

Title:
  Not possible to render pre-up, pre-down, post-up, or post-down
  snippets

Status in netplan:
  New
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Many configurations require scripts to run before or after an
  interface comes up or down.

  Example: I had a situation where I needed to render a post-up script
  to monitor an interface with ifupdown (and with the interface set to
  manual mode, because if the link was down I didn't want to require
  DHCP to run before the system continued booting). This is similar to
  what NetworkManager does in order to launch (or kill) a DHCP client.

  Other use cases involve setting up custom routes (such as when complex
  logic involving metrics or source routing is required) or anything
  else the designers of the netplan rendering engine didn't think of,
  such as invoking workarounds or special settings required for a
  particular NIC or environment, iptables rules that should be added or
  removed, etc.

  A follow-on issue is, it should be possible to ask that custom scripts
  run if the *link* is detected to come up or down. But I'll be happy if
  netplan first can simply replicate the custom-script-invoking behavior
  of ifupdown.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1664818/+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 1934221] Re: systemd-resolve segfault

2021-10-05 Thread Lukas Märdian
Thank you for testing. The Focal backport might need some more work, as
that version of systemd is even older and the patches did not apply
cleanly.

For Hirsute it was a straightforward cherry-pick of patches from
systemd-stable v247 (MergeProposal attached to this bug report). So I
wonder if we can somehow confirm if those patches fix the root-cause in
Hirsute?

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

Title:
  systemd-resolve segfault

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

Bug description:
  [Impact]

   * systemd-resolved stops replying to clients on the local LAN.
   * logging segfault crashes in dmesg:
  [836786.046514] systemd-resolve[872009]: segfault at 399 ip 
0399 sp 7ffd7959a6d8 error 14 in 
systemd-resolved[556398695000+9000]
  [836786.046524] Code: Bad RIP value.
  [840887.303994] traps: systemd-resolve[877019] general protection fault 
ip:55ba402e2594 sp:7ffe8cb6bbb0 error:0 in systemd-resolved[55ba402b5000+4]
  [844395.313421] systemd-resolve[878503]: segfault at 208 ip 5557a249f5fa 
sp 7ffe686f5a90 error 6 in systemd-resolved[5557a2472000+4]
  [844395.313431] Code: 48 85 c0 74 0e 48 8b 8d 00 01 00 00 48 89 88 00 01 00 
00 48 8b 85 00 01 00 00 48 85 c0 0f 84 1d 01 00 00 48 8b 95 f8 00 00 00 <48> 89 
90 f8 00 00 00 48 c7 85 00 01 00 00 00 00 00 00 48 c7 85 f8

   * The upload backports the upstream fix
  (https://github.com/systemd/systemd/pull/18832) to Focal & Hirsute.

  [Test Plan]

   * Setup /etc/systemd/resolved.conf:
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.

   * wait for ~24-48 hours and observe if any crash happens

  [Where problems could occur]

   * Any regression would likely cause crashes in systemd-resolved,
  making it unresponsive to DNS network name requests to local
  applications.

  [Other Info]
   
   * Reported upstream: https://github.com/systemd/systemd/issues/18427
   * Fixed upstream in v248: https://github.com/systemd/systemd/pull/18832

  === Original description ===

  
  systemd-resolve keep crashing and it is very annoying as sometimes it 
severely interrupt normal dns resolving.

  Last uploaded report is 2d9e7378-d89b-11eb-9e14-fa163ee63de6
  Typical error in dmesg:
  systemd-resolve[1792202]: segfault at 564ff982f3e0 ip 564ff982f3e0 sp 
7ffe2fd0b758 error 15

  apport hints me that problem is related to mdns

  #3  0x7f3e903c2f11 in sd_event_dispatch () from
  /lib/systemd/libsystemd-shared-245.so

  It might be (or not) related that some hosts with mdns in my network
  have ipv6 enabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.7
  ProcVersionSignature: Ubuntu 5.4.0-75.84-generic 5.4.119
  Uname: Linux 5.4.0-75-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  1 08:22:51 2021
  InstallationDate: Installed on 2018-12-05 (938 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  MachineType: System manufacturer System Product Name
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-75-generic 
root=UUID=54b80d5c-3d61-4919-873f-0d308083e3b9 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-05-22 (405 days ago)
  dmi.bios.date: 05/12/2020
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1205
  dmi.board.asset.tag: Default string
  dmi.board.name: ROG STRIX X399-E GAMING
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1205:bd05/12/2020:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXX399-EGAMING:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: System Product Name
  dmi.product.sku: SKU
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1934221/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1938259] Re: Add ACCEL_LOCATION=base property for Dell clamshell models

2021-09-28 Thread Lukas Märdian
** Changed in: systemd (Ubuntu Impish)
   Status: Fix Released => Won't Fix

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

Title:
  Add ACCEL_LOCATION=base property for Dell clamshell models

Status in OEM Priority Project:
  Won't Fix
Status in systemd package in Ubuntu:
  Won't Fix
Status in systemd source package in Focal:
  Won't Fix
Status in systemd source package in Hirsute:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix

Bug description:
  We are planning to do SRU to systemd in focal, to avoid unwanted
  screen rotations on some Dell laptop models.

  [Impact]

   * This fixes unwanted rotations on certain Dell clamshell laptop
  models with accelerometer.

  [Test Plan]

   * On Dell laptops with model SKU 0A3E or 0E0E, install this package and 
kernel 5.13, or kernel with this patch backported:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e26f023e01ef26b4138bc1099af309bdc4523d23
   * Rotate the laptop and the display should not be rotated.

  [Where problems could occur]

   * This is to add parameters for certain models in hwdb, and does not
  affect any other part of systemd.

   * This fix would only take effect with kernel 5.13 or the above patch
  backported.

  [scope]

  this is needed for all releases

  this is being fixed upstream by
  https://github.com/systemd/systemd/pull/20314

  [Other info]

   * The patch mentioned above is going to have a separated SRU for
  linux-oem-5.10 and linux-hwe-5.11 (LP: #1938143)

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1938259/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1943982] Re: Revert resolved-disable-event-sources-before-unreffing-them.patch

2021-09-27 Thread Lukas Märdian
Closing, as agreed upon with the SRU team:
https://code.launchpad.net/~slyon/ubuntu/+source/systemd/+git/systemd/+merge/408816/comments/1079349

** Changed in: systemd (Ubuntu Focal)
   Status: New => Won't Fix

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

Title:
  Revert resolved-disable-event-sources-before-unreffing-them.patch

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

Bug description:
  [impact]

  The initial patch for LP: #1934221 was not sufficient to fix the root
  cause of the segfault, but rather moved it to a slightly different
  location in the code (still inside the on_query_timeout handler).

  [test case]

  this bug is only to revert the previous patch

  For verification we should keep systemd-resolved running for a while and 
observe that it does not crash, using the relevant configuration in addition to 
being able to resolve DNS queries as expected, e.g.:
  ```
  root@ff-vm:~# cat /etc/systemd/resolved.conf
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.
  root@ff-vm:~# dmesg | grep segfault
  root@ff-vm:~# dmesg | grep "systemd-resolve"
  root@ff-vm:~# resolvectl query google.com
  google.com: 2a00:1450:4001:809::200e -- link: enp5s0
  172.217.18.110 -- link: enp5s0

  -- Information acquired via protocol DNS in 177.4ms.
  -- Data is authenticated: no
  ```

  [regression potential]

  Any regression could cause crashes in systemd-resolved, making it
  unresponsive to DNS network name requests to local applications.

  
  [other info]

  this only reverts the patch that was added for LP: #1934221, as this
  patch was detected to still produce (slightly different) segfaults in
  on_query_timeout
  (https://errors.ubuntu.com/problem/c4e5be3f1c7af9483993c7e6007b9325ab5b78cd),
  similar to the original segfaults in on_query_timeout
  (https://errors.ubuntu.com/problem/bb0ce4ff8e6ef86041cfb5647b792823a20b44f7)

  We want to revert the patch in Focal (systemd v245) for now, while we'll try 
to fix the root cause in Hirsute (systemd v247), adding more relevant patches 
that were added to systemd-stable v247 (but not systemd-stable v245):
  
https://github.com/systemd/systemd-stable/commits/v247-stable/src/resolve/resolved-dns-query.c
  
https://github.com/systemd/systemd-stable/commit/64317106aed94a6fb758ab6b08ba490873fc5227
  
https://github.com/systemd/systemd-stable/commit/91ba2eac4b6b463026b3a93e5a139923e8f2cfe4
  
https://github.com/systemd/systemd-stable/commit/ab9f7e1a51005f12d3bac83b86716d9d33048eb7
  
https://github.com/systemd/systemd-stable/commit/78a43c33c8847ebbc2d3cf530ebe304924c58b32
  
https://github.com/systemd/systemd-stable/commit/c8d7fab2286384b19ff6328cece107c4c02d7bb8

  => Root-causing this issue will be done in the (re-opened) LP:
  #1934221

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1943982/+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 1940505] Re: monero FTBFS on riscv64

2021-09-27 Thread Lukas Märdian
** Changed in: binutils (Ubuntu)
   Status: Invalid => Confirmed

** Changed in: binutils (Ubuntu)
   Status: Confirmed => New

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

Title:
  monero FTBFS on riscv64

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  New
Status in monero package in Ubuntu:
  Fix Released

Bug description:
  monero FTBFS on riscv64 due to toolchain issues:

  [ 64%] Linking CXX executable signature_fuzz_tests
  cd "/<>/obj-riscv64-linux-gnu/tests/fuzz" && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/signature_fuzz_tests.dir/link.txt --verbose=1
  /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -DNO_AES  -fno-strict-aliasing -std=c++11 
-D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla -Wwrite-strings 
-Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter 
-Wno-unused-variable -Wno-error=unused-variable -Wno-error=undef 
-Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized 
-Wno-error=cpp -Wno-reorder -Wno-missing-field-initializers  -fPIC  -Wformat 
-Wformat-security -fstack-protector -fstack-protector-strong 
-fstack-clash-protection -fno-strict-aliasing -ftemplate-depth=900 
-Wl,-Bsymbolic-functions -Wl,-z,relro  -pie -Wl,-z,relro -Wl,-z,now 
-Wl,-z,noexecstack  -rdynamic 
CMakeFiles/signature_fuzz_tests.dir/signature.cpp.o 
CMakeFiles/signature_fuzz_tests.dir/fuzzer.cpp.o -o signature_fuzz_tests  
../../lib/libwallet.a ../../src/cryptonote_core/libcryptonote_core.a 
../../src/p2p/libp2p.a ../../contrib/epee/src/libepee.a 
../../src/device/libdevice.a -Wl,-Bstatic -lrt -Wl,-Bdynamic -ldl 
../../src/rpc/librpc_base.a ../../src/mnemonics/libmnemonics.a 
../../src/device_trezor/libdevice_trezor.a 
../../src/cryptonote_core/libcryptonote_core.a ../../src/multisig/libmultisig.a 
../../src/blockchain_db/libblockchain_db.a 
../../external/db_drivers/liblmdb/liblmdb.a ../../src/ringct/libringct.a 
../../src/cryptonote_basic/libcryptonote_basic.a ../../src/device/libdevice.a 
-lhidapi-libusb ../../src/ringct/libringct_basic.a ../../src/blocks/libblocks.a 
../../src/checkpoints/libcheckpoints.a ../../src/hardforks/libhardforks.a 
../../src/net/libnet.a ../../src/common/libcommon.a 
../../src/crypto/libcncrypto.a ../../contrib/epee/src/libepee.a 
../../external/easylogging++/libeasylogging.a -lrandomx -lunbound -lboost_regex 
-lboost_date_time -lssl -lcrypto -lzmq -lpgm -lnorm -lgssapi_krb5 -lsodium 
../../src/libversion.a -lminiupnpc -lboost_chrono -lboost_serialization 
-lboost_filesystem -lboost_system -lboost_thread -lboost_program_options 
-Wl,-Bstatic -lrt -Wl,-Bdynamic -ldl  -latomic 
  ../../external/db_drivers/liblmdb/liblmdb.a(mdb.c.o): in function 
`mdb_node_add':
  
./obj-riscv64-linux-gnu/external/db_drivers/liblmdb/./external/db_drivers/liblmdb/mdb.c:8245:(.text+0x44e6):
 relocation truncated to fit: R_RISCV_JAL against `mdb_assert_fail.constprop.0'
  collect2: error: ld returned 1 exit status
  make[3]: *** [tests/fuzz/CMakeFiles/signature_fuzz_tests.dir/build.make:166: 
tests/fuzz/signature_fuzz_tests] Error 1
  make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
  make[2]: *** [CMakeFiles/Makefile2:4165: 
tests/fuzz/CMakeFiles/signature_fuzz_tests.dir/all] Error 2
  make[2]: Leaving directory '/<>/obj-riscv64-linux-gnu'
  make[1]: *** [Makefile:163: all] Error 2
  make[1]: Leaving directory '/<>/obj-riscv64-linux-gnu'
  dh_auto_build: error: cd obj-riscv64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
  make: *** [debian/rules:47: binary-arch] Error 25
  dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1940505/+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 1944712] Re: systemd/237-3ubuntu10.52 ADT test failure with linux-aws-5.4/5.4.0-1057.60~18.04.1

2021-09-24 Thread Lukas Märdian
In more recent kernels (i.e. linux-meta-aws/azure 5.13) I can see
messages like this: " watchdog: BUG: soft lockup - CPU#3 stuck for
238s!" that seems to indicate the kernel is not giving back control to
the userspace/systemd.

Also a message about a missing autofs4 module, that might be related:
"systemd[1]: Failed to find module 'autofs4'"

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

Title:
  systemd/237-3ubuntu10.52 ADT test failure with linux-
  aws-5.4/5.4.0-1057.60~18.04.1

Status in linux-aws-5.4 package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This is a scripted bug report about ADT failures while running systemd
  tests for linux-aws-5.4/5.4.0-1057.60~18.04.1 on bionic. Whether this
  is caused by the dep8 tests of the tested source or the kernel has yet
  to be determined.

  Testing failed on:
  amd64: 
https://autopkgtest.ubuntu.com/results/autopkgtest-bionic/bionic/amd64/s/systemd/20210923_022411_52338@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-aws-5.4/+bug/1944712/+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 1940505] Re: monero FTBFS on riscv64

2021-09-22 Thread Lukas Märdian
** Changed in: binutils (Ubuntu)
   Status: New => Invalid

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

Title:
  monero FTBFS on riscv64

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Invalid
Status in monero package in Ubuntu:
  Fix Released

Bug description:
  monero FTBFS on riscv64 due to toolchain issues:

  [ 64%] Linking CXX executable signature_fuzz_tests
  cd "/<>/obj-riscv64-linux-gnu/tests/fuzz" && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/signature_fuzz_tests.dir/link.txt --verbose=1
  /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -DNO_AES  -fno-strict-aliasing -std=c++11 
-D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla -Wwrite-strings 
-Wno-error=extra -Wno-error=deprecated-declarations -Wno-unused-parameter 
-Wno-unused-variable -Wno-error=unused-variable -Wno-error=undef 
-Wno-error=uninitialized -Wlogical-op -Wno-error=maybe-uninitialized 
-Wno-error=cpp -Wno-reorder -Wno-missing-field-initializers  -fPIC  -Wformat 
-Wformat-security -fstack-protector -fstack-protector-strong 
-fstack-clash-protection -fno-strict-aliasing -ftemplate-depth=900 
-Wl,-Bsymbolic-functions -Wl,-z,relro  -pie -Wl,-z,relro -Wl,-z,now 
-Wl,-z,noexecstack  -rdynamic 
CMakeFiles/signature_fuzz_tests.dir/signature.cpp.o 
CMakeFiles/signature_fuzz_tests.dir/fuzzer.cpp.o -o signature_fuzz_tests  
../../lib/libwallet.a ../../src/cryptonote_core/libcryptonote_core.a 
../../src/p2p/libp2p.a ../../contrib/epee/src/libepee.a 
../../src/device/libdevice.a -Wl,-Bstatic -lrt -Wl,-Bdynamic -ldl 
../../src/rpc/librpc_base.a ../../src/mnemonics/libmnemonics.a 
../../src/device_trezor/libdevice_trezor.a 
../../src/cryptonote_core/libcryptonote_core.a ../../src/multisig/libmultisig.a 
../../src/blockchain_db/libblockchain_db.a 
../../external/db_drivers/liblmdb/liblmdb.a ../../src/ringct/libringct.a 
../../src/cryptonote_basic/libcryptonote_basic.a ../../src/device/libdevice.a 
-lhidapi-libusb ../../src/ringct/libringct_basic.a ../../src/blocks/libblocks.a 
../../src/checkpoints/libcheckpoints.a ../../src/hardforks/libhardforks.a 
../../src/net/libnet.a ../../src/common/libcommon.a 
../../src/crypto/libcncrypto.a ../../contrib/epee/src/libepee.a 
../../external/easylogging++/libeasylogging.a -lrandomx -lunbound -lboost_regex 
-lboost_date_time -lssl -lcrypto -lzmq -lpgm -lnorm -lgssapi_krb5 -lsodium 
../../src/libversion.a -lminiupnpc -lboost_chrono -lboost_serialization 
-lboost_filesystem -lboost_system -lboost_thread -lboost_program_options 
-Wl,-Bstatic -lrt -Wl,-Bdynamic -ldl  -latomic 
  ../../external/db_drivers/liblmdb/liblmdb.a(mdb.c.o): in function 
`mdb_node_add':
  
./obj-riscv64-linux-gnu/external/db_drivers/liblmdb/./external/db_drivers/liblmdb/mdb.c:8245:(.text+0x44e6):
 relocation truncated to fit: R_RISCV_JAL against `mdb_assert_fail.constprop.0'
  collect2: error: ld returned 1 exit status
  make[3]: *** [tests/fuzz/CMakeFiles/signature_fuzz_tests.dir/build.make:166: 
tests/fuzz/signature_fuzz_tests] Error 1
  make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
  make[2]: *** [CMakeFiles/Makefile2:4165: 
tests/fuzz/CMakeFiles/signature_fuzz_tests.dir/all] Error 2
  make[2]: Leaving directory '/<>/obj-riscv64-linux-gnu'
  make[1]: *** [Makefile:163: all] Error 2
  make[1]: Leaving directory '/<>/obj-riscv64-linux-gnu'
  dh_auto_build: error: cd obj-riscv64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
  make: *** [debian/rules:47: binary-arch] Error 25
  dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1940505/+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 1934221] Re: systemd-resolve segfault

2021-09-20 Thread Lukas Märdian
Thanks for confirming Denys, that's unfortunate...
Would you mind giving the version from this PPA a try 
https://launchpad.net/~slyon/+archive/ubuntu/lp1934221 (for Hirsute)?

And maybe also for Focal once the build is ready?

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

Title:
  systemd-resolve segfault

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

Bug description:
  [Impact]

   * systemd-resolved stops replying to clients on the local LAN.
   * logging segfault crashes in dmesg:
  [836786.046514] systemd-resolve[872009]: segfault at 399 ip 
0399 sp 7ffd7959a6d8 error 14 in 
systemd-resolved[556398695000+9000]
  [836786.046524] Code: Bad RIP value.
  [840887.303994] traps: systemd-resolve[877019] general protection fault 
ip:55ba402e2594 sp:7ffe8cb6bbb0 error:0 in systemd-resolved[55ba402b5000+4]
  [844395.313421] systemd-resolve[878503]: segfault at 208 ip 5557a249f5fa 
sp 7ffe686f5a90 error 6 in systemd-resolved[5557a2472000+4]
  [844395.313431] Code: 48 85 c0 74 0e 48 8b 8d 00 01 00 00 48 89 88 00 01 00 
00 48 8b 85 00 01 00 00 48 85 c0 0f 84 1d 01 00 00 48 8b 95 f8 00 00 00 <48> 89 
90 f8 00 00 00 48 c7 85 00 01 00 00 00 00 00 00 48 c7 85 f8

   * The upload backports the upstream fix
  (https://github.com/systemd/systemd/pull/18832) to Focal & Hirsute.

  [Test Plan]

   * Setup /etc/systemd/resolved.conf:
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.

   * wait for ~24-48 hours and observe if any crash happens

  [Where problems could occur]

   * Any regression would likely cause crashes in systemd-resolved,
  making it unresponsive to DNS network name requests to local
  applications.

  [Other Info]
   
   * Reported upstream: https://github.com/systemd/systemd/issues/18427
   * Fixed upstream in v248: https://github.com/systemd/systemd/pull/18832

  === Original description ===

  
  systemd-resolve keep crashing and it is very annoying as sometimes it 
severely interrupt normal dns resolving.

  Last uploaded report is 2d9e7378-d89b-11eb-9e14-fa163ee63de6
  Typical error in dmesg:
  systemd-resolve[1792202]: segfault at 564ff982f3e0 ip 564ff982f3e0 sp 
7ffe2fd0b758 error 15

  apport hints me that problem is related to mdns

  #3  0x7f3e903c2f11 in sd_event_dispatch () from
  /lib/systemd/libsystemd-shared-245.so

  It might be (or not) related that some hosts with mdns in my network
  have ipv6 enabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.7
  ProcVersionSignature: Ubuntu 5.4.0-75.84-generic 5.4.119
  Uname: Linux 5.4.0-75-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  1 08:22:51 2021
  InstallationDate: Installed on 2018-12-05 (938 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  MachineType: System manufacturer System Product Name
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-75-generic 
root=UUID=54b80d5c-3d61-4919-873f-0d308083e3b9 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-05-22 (405 days ago)
  dmi.bios.date: 05/12/2020
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1205
  dmi.board.asset.tag: Default string
  dmi.board.name: ROG STRIX X399-E GAMING
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1205:bd05/12/2020:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXX399-EGAMING:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: System Product Name
  dmi.product.sku: SKU
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1934221/+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 1943982] Re: Revert resolved-disable-event-sources-before-unreffing-them.patch

2021-09-17 Thread Lukas Märdian
** Merge proposal linked:
   
https://code.launchpad.net/~slyon/ubuntu/+source/systemd/+git/systemd/+merge/408816

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

Title:
  Revert resolved-disable-event-sources-before-unreffing-them.patch

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

Bug description:
  [impact]

  The initial patch for LP: #1934221 was not sufficient to fix the root
  cause of the segfault, but rather moved it to a slightly different
  location in the code (still inside the on_query_timeout handler).

  [test case]

  this bug is only to revert the previous patch

  For verification we should keep systemd-resolved running for a while and 
observe that it does not crash, using the relevant configuration in addition to 
being able to resolve DNS queries as expected, e.g.:
  ```
  root@ff-vm:~# cat /etc/systemd/resolved.conf
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.
  root@ff-vm:~# dmesg | grep segfault
  root@ff-vm:~# dmesg | grep "systemd-resolve"
  root@ff-vm:~# resolvectl query google.com
  google.com: 2a00:1450:4001:809::200e -- link: enp5s0
  172.217.18.110 -- link: enp5s0

  -- Information acquired via protocol DNS in 177.4ms.
  -- Data is authenticated: no
  ```

  [regression potential]

  Any regression could cause crashes in systemd-resolved, making it
  unresponsive to DNS network name requests to local applications.

  
  [other info]

  this only reverts the patch that was added for LP: #1934221, as this
  patch was detected to still produce (slightly different) segfaults in
  on_query_timeout
  (https://errors.ubuntu.com/problem/c4e5be3f1c7af9483993c7e6007b9325ab5b78cd),
  similar to the original segfaults in on_query_timeout
  (https://errors.ubuntu.com/problem/bb0ce4ff8e6ef86041cfb5647b792823a20b44f7)

  We want to revert the patch in Focal (systemd v245) for now, while we'll try 
to fix the root cause in Hirsute (systemd v247), adding more relevant patches 
that were added to systemd-stable v247 (but not systemd-stable v245):
  
https://github.com/systemd/systemd-stable/commits/v247-stable/src/resolve/resolved-dns-query.c
  
https://github.com/systemd/systemd-stable/commit/64317106aed94a6fb758ab6b08ba490873fc5227
  
https://github.com/systemd/systemd-stable/commit/91ba2eac4b6b463026b3a93e5a139923e8f2cfe4
  
https://github.com/systemd/systemd-stable/commit/ab9f7e1a51005f12d3bac83b86716d9d33048eb7
  
https://github.com/systemd/systemd-stable/commit/78a43c33c8847ebbc2d3cf530ebe304924c58b32
  
https://github.com/systemd/systemd-stable/commit/c8d7fab2286384b19ff6328cece107c4c02d7bb8

  => Root-causing this issue will be done in the (re-opened) LP:
  #1934221

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

2021-09-17 Thread Lukas Märdian
Unfortunately, this patch does not seem to be sufficient.

It produces very similar segfaults in on_query_timeout
(https://errors.ubuntu.com/problem/c4e5be3f1c7af9483993c7e6007b9325ab5b78cd)
that the segfault we could observe before
(https://errors.ubuntu.com/problem/bb0ce4ff8e6ef86041cfb5647b792823a20b44f7)


We want to revert the patch in Focal (systemd v245) for now (LP: #1943982), 
while we'll try to fix the root cause in Hirsute (systemd v247), adding more 
relevant patches that were added to systemd-stable v247 (but not systemd-stable 
v245):
https://github.com/systemd/systemd-stable/commits/v247-stable/src/resolve/resolved-dns-query.c
https://github.com/systemd/systemd-stable/commit/64317106aed94a6fb758ab6b08ba490873fc5227
https://github.com/systemd/systemd-stable/commit/91ba2eac4b6b463026b3a93e5a139923e8f2cfe4
https://github.com/systemd/systemd-stable/commit/ab9f7e1a51005f12d3bac83b86716d9d33048eb7
https://github.com/systemd/systemd-stable/commit/78a43c33c8847ebbc2d3cf530ebe304924c58b32
https://github.com/systemd/systemd-stable/commit/c8d7fab2286384b19ff6328cece107c4c02d7bb8

It root-causing is successful, we might back-port those patches to
Focal, too.

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

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

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

Title:
  systemd-resolve segfault

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

Bug description:
  [Impact]

   * systemd-resolved stops replying to clients on the local LAN.
   * logging segfault crashes in dmesg:
  [836786.046514] systemd-resolve[872009]: segfault at 399 ip 
0399 sp 7ffd7959a6d8 error 14 in 
systemd-resolved[556398695000+9000]
  [836786.046524] Code: Bad RIP value.
  [840887.303994] traps: systemd-resolve[877019] general protection fault 
ip:55ba402e2594 sp:7ffe8cb6bbb0 error:0 in systemd-resolved[55ba402b5000+4]
  [844395.313421] systemd-resolve[878503]: segfault at 208 ip 5557a249f5fa 
sp 7ffe686f5a90 error 6 in systemd-resolved[5557a2472000+4]
  [844395.313431] Code: 48 85 c0 74 0e 48 8b 8d 00 01 00 00 48 89 88 00 01 00 
00 48 8b 85 00 01 00 00 48 85 c0 0f 84 1d 01 00 00 48 8b 95 f8 00 00 00 <48> 89 
90 f8 00 00 00 48 c7 85 00 01 00 00 00 00 00 00 48 c7 85 f8

   * The upload backports the upstream fix
  (https://github.com/systemd/systemd/pull/18832) to Focal & Hirsute.

  [Test Plan]

   * Setup /etc/systemd/resolved.conf:
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.

   * wait for ~24-48 hours and observe if any crash happens

  [Where problems could occur]

   * Any regression would likely cause crashes in systemd-resolved,
  making it unresponsive to DNS network name requests to local
  applications.

  [Other Info]
   
   * Reported upstream: https://github.com/systemd/systemd/issues/18427
   * Fixed upstream in v248: https://github.com/systemd/systemd/pull/18832

  === Original description ===

  
  systemd-resolve keep crashing and it is very annoying as sometimes it 
severely interrupt normal dns resolving.

  Last uploaded report is 2d9e7378-d89b-11eb-9e14-fa163ee63de6
  Typical error in dmesg:
  systemd-resolve[1792202]: segfault at 564ff982f3e0 ip 564ff982f3e0 sp 
7ffe2fd0b758 error 15

  apport hints me that problem is related to mdns

  #3  0x7f3e903c2f11 in sd_event_dispatch () from
  /lib/systemd/libsystemd-shared-245.so

  It might be (or not) related that some hosts with mdns in my network
  have ipv6 enabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.7
  ProcVersionSignature: Ubuntu 5.4.0-75.84-generic 5.4.119
  Uname: Linux 5.4.0-75-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  1 08:22:51 2021
  InstallationDate: Installed on 2018-12-05 (938 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  MachineType: System manufacturer System Product Name
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-75-generic 
root=UUID=54b80d5c-3d61-4919-873f-0d308083e3b9 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-05-22 (405 days ago)
  dmi.bios.date: 05/12/2020
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1205
  dmi.board.asset.tag: Default string
  dmi.board.name: ROG STRIX X399-E GAMING
  dmi.board.vendor: ASUSTeK COMPUTER INC.
 

[Touch-packages] [Bug 1943982] [NEW] Revert resolved-disable-event-sources-before-unreffing-them.patch

2021-09-17 Thread Lukas Märdian
Public bug reported:

[impact]

The initial patch for LP: #1934221 was not sufficient to fix the root
cause of the segfault, but rather moved it to a slightly different
location in the code (still inside the on_query_timeout handler).

[test case]

this bug is only to revert the previous patch

For verification we should keep systemd-resolved running for a while and 
observe that it does not crash, using the relevant configuration in addition to 
being able to resolve DNS queries as expected, e.g.:
```
root@ff-vm:~# cat /etc/systemd/resolved.conf
[Resolve]
DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
DNSSEC=yes
DNSOverTLS=opportunistic
MulticastDNS=no
LLMNR=no
Cache=yes
DNSStubListener=yes
Domains=~.
root@ff-vm:~# dmesg | grep segfault
root@ff-vm:~# dmesg | grep "systemd-resolve"
root@ff-vm:~# resolvectl query google.com
google.com: 2a00:1450:4001:809::200e -- link: enp5s0
172.217.18.110 -- link: enp5s0

-- Information acquired via protocol DNS in 177.4ms.
-- Data is authenticated: no
```

[regression potential]

Any regression could cause crashes in systemd-resolved, making it
unresponsive to DNS network name requests to local applications.


[other info]

this only reverts the patch that was added for LP: #1934221, as this
patch was detected to still produce (slightly different) segfaults in
on_query_timeout
(https://errors.ubuntu.com/problem/c4e5be3f1c7af9483993c7e6007b9325ab5b78cd),
similar to the original segfaults in on_query_timeout
(https://errors.ubuntu.com/problem/bb0ce4ff8e6ef86041cfb5647b792823a20b44f7)

We want to revert the patch in Focal (systemd v245) for now, while we'll try to 
fix the root cause in Hirsute (systemd v247), adding more relevant patches that 
were added to systemd-stable v247 (but not systemd-stable v245):
https://github.com/systemd/systemd-stable/commits/v247-stable/src/resolve/resolved-dns-query.c
https://github.com/systemd/systemd-stable/commit/64317106aed94a6fb758ab6b08ba490873fc5227
https://github.com/systemd/systemd-stable/commit/91ba2eac4b6b463026b3a93e5a139923e8f2cfe4
https://github.com/systemd/systemd-stable/commit/ab9f7e1a51005f12d3bac83b86716d9d33048eb7
https://github.com/systemd/systemd-stable/commit/78a43c33c8847ebbc2d3cf530ebe304924c58b32
https://github.com/systemd/systemd-stable/commit/c8d7fab2286384b19ff6328cece107c4c02d7bb8

=> Root-causing this issue will be done in the (re-opened) LP: #1934221

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

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

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

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

Title:
  Revert resolved-disable-event-sources-before-unreffing-them.patch

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

Bug description:
  [impact]

  The initial patch for LP: #1934221 was not sufficient to fix the root
  cause of the segfault, but rather moved it to a slightly different
  location in the code (still inside the on_query_timeout handler).

  [test case]

  this bug is only to revert the previous patch

  For verification we should keep systemd-resolved running for a while and 
observe that it does not crash, using the relevant configuration in addition to 
being able to resolve DNS queries as expected, e.g.:
  ```
  root@ff-vm:~# cat /etc/systemd/resolved.conf
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.
  root@ff-vm:~# dmesg | grep segfault
  root@ff-vm:~# dmesg | grep "systemd-resolve"
  root@ff-vm:~# resolvectl query google.com
  google.com: 2a00:1450:4001:809::200e -- link: enp5s0
  172.217.18.110 -- link: enp5s0

  -- Information acquired via protocol DNS in 177.4ms.
  -- Data is authenticated: no
  ```

  [regression potential]

  Any regression could cause crashes in systemd-resolved, making it
  unresponsive to DNS network name requests to local applications.

  
  [other info]

  this only reverts the patch that was added for LP: #1934221, as this
  patch was detected to still produce (slightly different) segfaults in
  on_query_timeout
  (https://errors.ubuntu.com/problem/c4e5be3f1c7af9483993c7e6007b9325ab5b78cd),
  similar to the original segfaults in on_query_timeout
  (https://errors.ubuntu.com/problem/bb0ce4ff8e6ef86041cfb5647b792823a20b44f7)

  We want to revert the patch in Focal (systemd v245) for now, while we'll try 
to fix the root cause in Hirsute (systemd v247), adding more relevant patches 
that were added to systemd-stable v247 (but not systemd-stable v245):
  

[Touch-packages] [Bug 1943704] Re: lxc fails autopkgtests on (pure) cgroups v2 enabled system

2021-09-17 Thread Lukas Märdian
Some more findings after testing with systemd-run:

FAIL: lxc-tests: lxc-test-autostart (360s)
FAIL: lxc-tests: lxc-test-no-new-privs (361s)

This two tests fail during the (local) autopkgtest run. But after logging into 
the local autopkgtest VM via its debug shell (--shell-fail|-s parameter) and 
executing them manually `sudo src/tests/lxc-test-autostart` / `sudo 
src/tests/lxc-test-no-new-privs` they pass just fine.
(Well I needed to adopt from a "xenial" to a "focal" container for the 
"no-new-privs" test as the xenial container will fail with some apt fetch 
errors during `apt update`, maybe due to xenial EOL?)
So this is probably some intermittent networking failure or wrong/different 
proxy environment settings. – But seems to be rather unrelated to cgroupsv2.


FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
FAIL: lxc-tests: lxc-test-unpriv (0s)

The other two tests seem to need some more porting work to make them
compatible with cgroupsv2, as they are still making use of some
deprecated cgroupsv1 functionality, such as the `cgroup.clone_children`
or `tasks` files (see:
https://github.com/torvalds/linux/blob/master/Documentation/admin-
guide/cgroup-v2.rst#deprecated-v1-core-features).


So in order to unblock the systemd 248.3-1ubuntu7 release (in impish-proposed) 
we could move forward with cbrauner's suggestion of skipping these tests. 
Patch/Debdiff attached.
In the long run the tests should be fixed and made compatible with cgroupsv2, 
though.

** Patch added: "lxc-1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1943704/+attachment/5525945/+files/lxc-1.debdiff

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

Title:
  lxc fails autopkgtests on (pure) cgroups v2 enabled system

Status in lxc package in Ubuntu:
  New

Bug description:
  lxc fails 4 autopkgtests if ran on a cgroups v2 enabled systemd
  (248.3-1ubuntu7) using a pure unified hierarchy (in favor of the
  hybrid hierarchy used before).

  https://autopkgtest.ubuntu.com/packages/lxc

  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  FAIL: lxc-tests: lxc-test-autostart (360s)
  FAIL: lxc-tests: lxc-test-no-new-privs (361s)
  FAIL: lxc-tests: lxc-test-unpriv (0s)

  I needed to skip the "lxc-test-exit-code" test to avoid my local autopkgtest 
to hang but that seems to be working on the Ubuntu infrastructure, so its 
probably related to my local environment:
  diff --git a/debian/tests/exercise b/debian/tests/exercise
  index 4a22f33..70231ee 100755
  --- a/debian/tests/exercise
  +++ b/debian/tests/exercise
  @@ -88,6 +88,10 @@ for testbin in lxc-test-*; do
   echo "${testbin}" | grep -qv "\.in$" || continue
   STRING="lxc-tests: $testbin"

  +# Skip some tests because for testing
  +[ "$testbin" = "lxc-test-exit-code" ] && \
  +ignore "$STRING" && continue
  +
   # Some tests can't be run standalone
   [ "$testbin" = "lxc-test-may-control" ] && continue

  Reproducer (while being connected to the Canonical VPN, or setup another 
squid proxy):
  $ autopkgtest-buildvm-ubuntu-cloud -v -r impish
  $ autopkgtest lxc -s -U --apt-pocket=proposed=src:systemd --env 
"http_proxy=http://squid.internal:3128; --env 
"https_proxy=http://squid.internal:3128; --env 
"no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,launchpad.net,10.24.0.0/24"
 -- qemu autopkgtest-impish-amd64.img

  I used "../lxc_4.0.10-0ubuntu4+wip0_amd64.changes" instead of the
  "lxc" SRCPKG name, to use a custom package, skipping the additional
  "lxc-test-exit-code" test.

  Interestingly, the same set of tests fails if I run the test using the
  old (non cgroups v2) systemd (248.3-1ubuntu3), i.e. by leaving out the
  "--apt-pocket=proposed=src:systemd" parameter. Although, they fail in
  a slightly different way (see attached lxc-vs-old-systemd.log).
  Running a baseline test using the old systemd passed on the Ubuntu
  infrastructure. – I cannot really explain this infra-baseline vs
  local-autopkgtest difference... But it doesn't matter too much either,
  as we need to fix the situation for the new (cgroupv2) enabled
  systemd.


  Logs (full logs attached):

  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  ---
  /usr/sbin/deluser: The user `lxcunpriv' does not exist.
  ./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied
  lxc-destroy: tmp.6hX6BylHCU: tools/lxc_destroy.c: main: 242 Container is not 
defined
  umount: /sys/kernel/security/apparmor/features/mount: not mounted.
  sed: can't read /run/lxc/nics: No such file or directory
  ---
  => "./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied" seems to be 
relevant/related to unified cgroup hierarchy here.
  => fails in a different way with old (non 

[Touch-packages] [Bug 1943704] Re: lxc fails autopkgtests on (pure) cgroups v2 enabled system

2021-09-17 Thread Lukas Märdian
From a side-channel discussion:

 all the fully unprivileged tests need to be disabled on
cgroup v2. You can't run fully unprivileged containers on pure cgroup2
layouts. The delegation model doesn't allow it. Not without systemd
making a fully empty delegated cgroup hierarchy available.

 I think I'd prefer if those tests could figure out they're
running on a cgroup2 systemd system and then do the systemd-run wrapper
around lxc-start (or whatever it is) as that's realistically what users
of unpriv LXC would do. Something along those lines: `systemd-run
--unit=myshell --user --scope -p "Delegate=yes" lxc-start`

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

Title:
  lxc fails autopkgtests on (pure) cgroups v2 enabled system

Status in lxc package in Ubuntu:
  New

Bug description:
  lxc fails 4 autopkgtests if ran on a cgroups v2 enabled systemd
  (248.3-1ubuntu7) using a pure unified hierarchy (in favor of the
  hybrid hierarchy used before).

  https://autopkgtest.ubuntu.com/packages/lxc

  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  FAIL: lxc-tests: lxc-test-autostart (360s)
  FAIL: lxc-tests: lxc-test-no-new-privs (361s)
  FAIL: lxc-tests: lxc-test-unpriv (0s)

  I needed to skip the "lxc-test-exit-code" test to avoid my local autopkgtest 
to hang but that seems to be working on the Ubuntu infrastructure, so its 
probably related to my local environment:
  diff --git a/debian/tests/exercise b/debian/tests/exercise
  index 4a22f33..70231ee 100755
  --- a/debian/tests/exercise
  +++ b/debian/tests/exercise
  @@ -88,6 +88,10 @@ for testbin in lxc-test-*; do
   echo "${testbin}" | grep -qv "\.in$" || continue
   STRING="lxc-tests: $testbin"

  +# Skip some tests because for testing
  +[ "$testbin" = "lxc-test-exit-code" ] && \
  +ignore "$STRING" && continue
  +
   # Some tests can't be run standalone
   [ "$testbin" = "lxc-test-may-control" ] && continue

  Reproducer (while being connected to the Canonical VPN, or setup another 
squid proxy):
  $ autopkgtest-buildvm-ubuntu-cloud -v -r impish
  $ autopkgtest lxc -s -U --apt-pocket=proposed=src:systemd --env 
"http_proxy=http://squid.internal:3128; --env 
"https_proxy=http://squid.internal:3128; --env 
"no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,launchpad.net,10.24.0.0/24"
 -- qemu autopkgtest-impish-amd64.img

  I used "../lxc_4.0.10-0ubuntu4+wip0_amd64.changes" instead of the
  "lxc" SRCPKG name, to use a custom package, skipping the additional
  "lxc-test-exit-code" test.

  Interestingly, the same set of tests fails if I run the test using the
  old (non cgroups v2) systemd (248.3-1ubuntu3), i.e. by leaving out the
  "--apt-pocket=proposed=src:systemd" parameter. Although, they fail in
  a slightly different way (see attached lxc-vs-old-systemd.log).
  Running a baseline test using the old systemd passed on the Ubuntu
  infrastructure. – I cannot really explain this infra-baseline vs
  local-autopkgtest difference... But it doesn't matter too much either,
  as we need to fix the situation for the new (cgroupv2) enabled
  systemd.


  Logs (full logs attached):

  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  ---
  /usr/sbin/deluser: The user `lxcunpriv' does not exist.
  ./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied
  lxc-destroy: tmp.6hX6BylHCU: tools/lxc_destroy.c: main: 242 Container is not 
defined
  umount: /sys/kernel/security/apparmor/features/mount: not mounted.
  sed: can't read /run/lxc/nics: No such file or directory
  ---
  => "./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied" seems to be 
relevant/related to unified cgroup hierarchy here.
  => fails in a different way with old (non cgroup v2) systemd, locally

  FAIL: lxc-tests: lxc-test-autostart (21s)
  ---
  Setting up the GPG keyring
  Downloading the image index
  ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
  lxc-create: lxc-test-auto: lxccontainer.c: create_run_template: 1621 Failed 
to create container from template
  lxc-create: lxc-test-auto: tools/lxc_create.c: main: 319 Failed to create 
container lxc-test-auto
  FAIL
  ---
  => fails in the same way with old (non cgroup v2) systemd, locally.

  FAIL: lxc-tests: lxc-test-no-new-privs (22s)
  ---
  + DONE=0
  + trap cleanup EXIT SIGHUP SIGINT SIGTERM
  + '[' '!' -d /etc/lxc ']'
  + ARCH=i386
  + type dpkg
  ++ dpkg --print-architecture
  + ARCH=amd64
  + lxc-create -t download -n c1 -- -d ubuntu -r xenial -a amd64
  Setting up the GPG keyring
  Downloading the image index
  ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
  lxc-create: c1: lxccontainer.c: create_run_template: 

[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2021-09-16 Thread Lukas Märdian
Addressed in FR-1460

** Tags removed: rls-ii-incoming

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in D-Bus:
  Unknown
Status in systemd:
  New
Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Incomplete
Status in gnome-shell package in Ubuntu:
  Invalid
Status in accountsservice source package in Focal:
  Invalid
Status in dbus source package in Focal:
  Incomplete
Status in gnome-shell source package in Focal:
  Invalid
Status in accountsservice source package in Groovy:
  Invalid
Status in dbus source package in Groovy:
  Incomplete
Status in gnome-shell source package in Groovy:
  Invalid
Status in accountsservice source package in Hirsute:
  Invalid
Status in dbus source package in Hirsute:
  Incomplete
Status in gnome-shell source package in Hirsute:
  Invalid
Status in accountsservice source package in Impish:
  Invalid
Status in dbus source package in Impish:
  Incomplete
Status in gnome-shell source package in Impish:
  Invalid

Bug description:
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  
  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time 
threads.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via 
systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=>
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request 
repeated too quickly.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit 
Scheduling Policy Service.
  Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53

  
  But that already was only triggered by a gnome restart that kicked of earlier:

  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on 
Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
is initialized.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Wayland 
Session.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
(session: gnome-login).

  
  X was recycleing before:
  Apr 08 06:09:19 Keschdeichel systemd[10683]: Stopping GNOME Shell on X11...
  ...
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (EE) 
systemd-logind: ReleaseControl failed: Unknown object 
'/org/freedesktop/login1/session/_32'.
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (II) Server 
terminated successfully (0). Closing log file.

  
  It seems like some internal service broke and everything that followed was a 
secondary issue to that:
  Apr 08 06:09:19 Keschdeichel systemd[1]: NetworkManager.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel systemd[1]: wpa_supplicant.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  

[Touch-packages] [Bug 1850667] Re: Switch to "unified" cgroup hierarchy (cgroupv2)

2021-09-15 Thread Lukas Märdian
** Changed in: snapd
   Status: Confirmed => Fix Committed

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

Title:
  Switch to "unified" cgroup hierarchy (cgroupv2)

Status in lxc:
  Fix Released
Status in lxd:
  Fix Released
Status in snapd:
  Fix Committed
Status in docker.io package in Ubuntu:
  Fix Released
Status in lxc package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Confirmed
Status in lxc package in Debian:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  Systemd upstream switched the default cgroup hierarchy to unified with
  v243. This change is reverted by the Ubuntu systemd packages, but as
  unified is the way to go per upstream support should be added to all
  relevant Ubuntu packges (and snaps):

  https://github.com/systemd/systemd/blob/v243/NEWS#L56

  * systemd now defaults to the "unified" cgroup hierarchy setup during
build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
default. Previously, -Ddefault-hierarchy=hybrid was the default. 
This
change reflects the fact that cgroupsv2 support has matured
substantially in both systemd and in the kernel, and is clearly the
way forward. Downstream production distributions might want to
continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
their builds as unfortunately the popular container managers have 
not
caught up with the kernel API changes.

  
  Systemd is rebuilt using the new default and is available from the following 
PPA for testing:

  https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh

  The autopkgtest results against other packges are available here:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-cgh/?format=plain

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  focal-rbalint-systemd-unified-cgh/?format=plain

  lxc autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz

  snapd autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz

  
  docker.io autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxc/+bug/1850667/+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 1943704] Re: lxc fails autopkgtests on (pure) cgroups v2 enabled system

2021-09-15 Thread Lukas Märdian
** Attachment added: "lxc-vs-old-systemd.log"
   
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1943704/+attachment/5525407/+files/lxc-vs-old-systemd.log

** Description changed:

  lxc fails 4 autopkgtests if ran on a cgroups v2 enabled systemd
  (248.3-1ubuntu7) using a pure unified hierarchy (in favor of the hybrid
  hierarchy used before).
  
  https://autopkgtest.ubuntu.com/packages/lxc
  
  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  FAIL: lxc-tests: lxc-test-autostart (360s)
  FAIL: lxc-tests: lxc-test-no-new-privs (361s)
  FAIL: lxc-tests: lxc-test-unpriv (0s)
  
  I needed to skip the "lxc-test-exit-code" test to avoid my local autopkgtest 
to hang but that seems to be working on the Ubuntu infrastructure, so its 
probably related to my local environment:
  diff --git a/debian/tests/exercise b/debian/tests/exercise
  index 4a22f33..70231ee 100755
  --- a/debian/tests/exercise
  +++ b/debian/tests/exercise
  @@ -88,6 +88,10 @@ for testbin in lxc-test-*; do
-  echo "${testbin}" | grep -qv "\.in$" || continue
-  STRING="lxc-tests: $testbin"
-  
+  echo "${testbin}" | grep -qv "\.in$" || continue
+  STRING="lxc-tests: $testbin"
+ 
  +# Skip some tests because for testing
  +[ "$testbin" = "lxc-test-exit-code" ] && \
  +ignore "$STRING" && continue
  +
-  # Some tests can't be run standalone
-  [ "$testbin" = "lxc-test-may-control" ] && continue
-  
+  # Some tests can't be run standalone
+  [ "$testbin" = "lxc-test-may-control" ] && continue
  
- Reproducer:
+ Reproducer (while being connected to the Canonical VPN, or setup another 
squid proxy):
  $ autopkgtest-buildvm-ubuntu-cloud -v -r impish
  $ autopkgtest lxc -s -U --apt-pocket=proposed=src:systemd --env 
"http_proxy=http://squid.internal:3128; --env 
"https_proxy=http://squid.internal:3128; --env 
"no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,launchpad.net,10.24.0.0/24"
 -- qemu autopkgtest-impish-amd64.img
  
  I used "../lxc_4.0.10-0ubuntu4+wip0_amd64.changes" instead of the "lxc"
  SRCPKG name, to use a custom package, skipping the additional "lxc-test-
  exit-code" test.
+ 
+ Interestingly, the same set of tests fails if I run the test using the
+ old (non cgroups v2) systemd (248.3-1ubuntu3), i.e. by leaving out the "
+ --apt-pocket=proposed=src:systemd" parameter. Although, they fail in a
+ slightly different way (see attached lxc-vs-old-systemd.log). Running a
+ baseline test using the old systemd passed on the Ubuntu infrastructure.
+ – I cannot really explain this infra-baseline vs local-autopkgtest
+ difference... But it doesn't matter too much either, as we need to fix
+ the situation for the new (cgroupv2) enabled systemd.
  
  
  Logs (full logs attached):
  
  FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
  ---
  /usr/sbin/deluser: The user `lxcunpriv' does not exist.
  ./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied
  lxc-destroy: tmp.6hX6BylHCU: tools/lxc_destroy.c: main: 242 Container is not 
defined
  umount: /sys/kernel/security/apparmor/features/mount: not mounted.
  sed: can't read /run/lxc/nics: No such file or directory
  ---
  => "./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied" seems to be 
relevant/related to unified cgroup hierarchy here.
  => fails in a different way with old (non cgroup v2) systemd, locally
- 
  
  FAIL: lxc-tests: lxc-test-autostart (21s)
  ---
  Setting up the GPG keyring
  Downloading the image index
  ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
  lxc-create: lxc-test-auto: lxccontainer.c: create_run_template: 1621 Failed 
to create container from template
  lxc-create: lxc-test-auto: tools/lxc_create.c: main: 319 Failed to create 
container lxc-test-auto
  FAIL
  ---
  => fails in the same way with old (non cgroup v2) systemd, locally.
  
  FAIL: lxc-tests: lxc-test-no-new-privs (22s)
  ---
  + DONE=0
  + trap cleanup EXIT SIGHUP SIGINT SIGTERM
  + '[' '!' -d /etc/lxc ']'
  + ARCH=i386
  + type dpkg
  ++ dpkg --print-architecture
  + ARCH=amd64
  + lxc-create -t download -n c1 -- -d ubuntu -r xenial -a amd64
  Setting up the GPG keyring
  Downloading the image index
  ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
  lxc-create: c1: lxccontainer.c: create_run_template: 1621 Failed to create 
container from template
  lxc-create: c1: tools/lxc_create.c: main: 319 Failed to create container c1
  + cleanup
  + cd /
  + lxc-destroy -n c1 -f
  lxc-destroy: c1: tools/lxc_destroy.c: main: 242 Container is not defined
  + true
  + '[' 0 -eq 0 ']'
  + echo FAIL
  FAIL
  + exit 1
  ---
  => fails in the same way with old (non cgroup v2) systemd, locally.
  
  FAIL: lxc-tests: lxc-test-unpriv (0s)
  ---
  ./lxc-test-unpriv: line 163: 

[Touch-packages] [Bug 1943704] [NEW] lxc fails autopkgtests on (pure) cgroups v2 enabled system

2021-09-15 Thread Lukas Märdian
Public bug reported:

lxc fails 4 autopkgtests if ran on a cgroups v2 enabled systemd
(248.3-1ubuntu7) using a pure unified hierarchy (in favor of the hybrid
hierarchy used before).

https://autopkgtest.ubuntu.com/packages/lxc

FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
FAIL: lxc-tests: lxc-test-autostart (360s)
FAIL: lxc-tests: lxc-test-no-new-privs (361s)
FAIL: lxc-tests: lxc-test-unpriv (0s)

I needed to skip the "lxc-test-exit-code" test to avoid my local autopkgtest to 
hang but that seems to be working on the Ubuntu infrastructure, so its probably 
related to my local environment:
diff --git a/debian/tests/exercise b/debian/tests/exercise
index 4a22f33..70231ee 100755
--- a/debian/tests/exercise
+++ b/debian/tests/exercise
@@ -88,6 +88,10 @@ for testbin in lxc-test-*; do
 echo "${testbin}" | grep -qv "\.in$" || continue
 STRING="lxc-tests: $testbin"

+# Skip some tests because for testing
+[ "$testbin" = "lxc-test-exit-code" ] && \
+ignore "$STRING" && continue
+
 # Some tests can't be run standalone
 [ "$testbin" = "lxc-test-may-control" ] && continue

Reproducer (while being connected to the Canonical VPN, or setup another squid 
proxy):
$ autopkgtest-buildvm-ubuntu-cloud -v -r impish
$ autopkgtest lxc -s -U --apt-pocket=proposed=src:systemd --env 
"http_proxy=http://squid.internal:3128; --env 
"https_proxy=http://squid.internal:3128; --env 
"no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,launchpad.net,10.24.0.0/24"
 -- qemu autopkgtest-impish-amd64.img

I used "../lxc_4.0.10-0ubuntu4+wip0_amd64.changes" instead of the "lxc"
SRCPKG name, to use a custom package, skipping the additional "lxc-test-
exit-code" test.

Interestingly, the same set of tests fails if I run the test using the
old (non cgroups v2) systemd (248.3-1ubuntu3), i.e. by leaving out the "
--apt-pocket=proposed=src:systemd" parameter. Although, they fail in a
slightly different way (see attached lxc-vs-old-systemd.log). Running a
baseline test using the old systemd passed on the Ubuntu infrastructure.
– I cannot really explain this infra-baseline vs local-autopkgtest
difference... But it doesn't matter too much either, as we need to fix
the situation for the new (cgroupv2) enabled systemd.


Logs (full logs attached):

FAIL: lxc-tests: lxc-test-apparmor-mount (0s)
---
/usr/sbin/deluser: The user `lxcunpriv' does not exist.
./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied
lxc-destroy: tmp.6hX6BylHCU: tools/lxc_destroy.c: main: 242 Container is not 
defined
umount: /sys/kernel/security/apparmor/features/mount: not mounted.
sed: can't read /run/lxc/nics: No such file or directory
---
=> "./lxc-test-apparmor-mount: 152: cannot create 
/sys/fs/cgroup/-.mount/lxctest/tasks: Permission denied" seems to be 
relevant/related to unified cgroup hierarchy here.
=> fails in a different way with old (non cgroup v2) systemd, locally

FAIL: lxc-tests: lxc-test-autostart (21s)
---
Setting up the GPG keyring
Downloading the image index
ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
lxc-create: lxc-test-auto: lxccontainer.c: create_run_template: 1621 Failed to 
create container from template
lxc-create: lxc-test-auto: tools/lxc_create.c: main: 319 Failed to create 
container lxc-test-auto
FAIL
---
=> fails in the same way with old (non cgroup v2) systemd, locally.

FAIL: lxc-tests: lxc-test-no-new-privs (22s)
---
+ DONE=0
+ trap cleanup EXIT SIGHUP SIGINT SIGTERM
+ '[' '!' -d /etc/lxc ']'
+ ARCH=i386
+ type dpkg
++ dpkg --print-architecture
+ ARCH=amd64
+ lxc-create -t download -n c1 -- -d ubuntu -r xenial -a amd64
Setting up the GPG keyring
Downloading the image index
ERROR: Failed to download 
http://images.linuxcontainers.org//meta/1.0/index-system
lxc-create: c1: lxccontainer.c: create_run_template: 1621 Failed to create 
container from template
lxc-create: c1: tools/lxc_create.c: main: 319 Failed to create container c1
+ cleanup
+ cd /
+ lxc-destroy -n c1 -f
lxc-destroy: c1: tools/lxc_destroy.c: main: 242 Container is not defined
+ true
+ '[' 0 -eq 0 ']'
+ echo FAIL
FAIL
+ exit 1
---
=> fails in the same way with old (non cgroup v2) systemd, locally.

FAIL: lxc-tests: lxc-test-unpriv (0s)
---
./lxc-test-unpriv: line 163: /sys/fs/cgroup/-.mount/lxctest/tasks: Permission 
denied
cat: /tmp/tmp.w4zIOZHyAA: No such file or directory
---
=> "./lxc-test-unpriv: line 163: /sys/fs/cgroup/-.mount/lxctest/tasks: 
Permission denied" seems to be relevant/related to unified cgroup hierarchy 
here.
=> fails in a different way with old (non cgroup v2) systemd, locally.

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


** Tags: update-excuse

** Attachment added: "lxc-vs-new-systemd.log"
   
https://bugs.launchpad.net/bugs/1943704/+attachment/5525406/+files/lxc-vs-new-systemd.log

-- 
You received this bug 

[Touch-packages] [Bug 1850667] Re: Switch to "unified" cgroup hierarchy (cgroupv2)

2021-09-15 Thread Lukas Märdian
snapd landed the support in upstream git as of yesterday
(https://github.com/snapcore/snapd) and it is expected to be shipped
with snapd v2.53

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

Title:
  Switch to "unified" cgroup hierarchy (cgroupv2)

Status in lxc:
  Fix Released
Status in lxd:
  Fix Released
Status in snapd:
  Confirmed
Status in docker.io package in Ubuntu:
  Fix Released
Status in lxc package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Confirmed
Status in lxc package in Debian:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  Systemd upstream switched the default cgroup hierarchy to unified with
  v243. This change is reverted by the Ubuntu systemd packages, but as
  unified is the way to go per upstream support should be added to all
  relevant Ubuntu packges (and snaps):

  https://github.com/systemd/systemd/blob/v243/NEWS#L56

  * systemd now defaults to the "unified" cgroup hierarchy setup during
build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
default. Previously, -Ddefault-hierarchy=hybrid was the default. 
This
change reflects the fact that cgroupsv2 support has matured
substantially in both systemd and in the kernel, and is clearly the
way forward. Downstream production distributions might want to
continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
their builds as unfortunately the popular container managers have 
not
caught up with the kernel API changes.

  
  Systemd is rebuilt using the new default and is available from the following 
PPA for testing:

  https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh

  The autopkgtest results against other packges are available here:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-cgh/?format=plain

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  focal-rbalint-systemd-unified-cgh/?format=plain

  lxc autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz

  snapd autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz

  
  docker.io autopkgtest failing:

  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-
  eoan-rbalint-systemd-unified-
  cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxc/+bug/1850667/+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 1934221] Re: systemd-resolve segfault

2021-09-14 Thread Lukas Märdian
I've tested systemd 245.4-4ubuntu3.13 from focal-proposed in a VM and
can verify it is working as expected.

I used the configuration provided and kept the VM running for several days 
without any crash:
```
root@ff-vm:~# cat /etc/systemd/resolved.conf
[Resolve]
DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
DNSSEC=yes
DNSOverTLS=opportunistic
MulticastDNS=no
LLMNR=no
Cache=yes
DNSStubListener=yes
Domains=~.
root@ff-vm:~# dmesg | grep segfault
root@ff-vm:~# dmesg | grep "systemd-resolve"
root@ff-vm:~# resolvectl query google.com
google.com: 2a00:1450:4001:809::200e   -- link: enp5s0
172.217.18.110 -- link: enp5s0

-- Information acquired via protocol DNS in 177.4ms.
-- Data is authenticated: no
```

DNS requests are working as expected and I could not provoke a crash by
disconnecting the network interface midway through a DNS request,
forcing a timeout.


** Tags removed: verification-needed-focal
** Tags added: 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/1934221

Title:
  systemd-resolve segfault

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

Bug description:
  [Impact]

   * systemd-resolved stops replying to clients on the local LAN.
   * logging segfault crashes in dmesg:
  [836786.046514] systemd-resolve[872009]: segfault at 399 ip 
0399 sp 7ffd7959a6d8 error 14 in 
systemd-resolved[556398695000+9000]
  [836786.046524] Code: Bad RIP value.
  [840887.303994] traps: systemd-resolve[877019] general protection fault 
ip:55ba402e2594 sp:7ffe8cb6bbb0 error:0 in systemd-resolved[55ba402b5000+4]
  [844395.313421] systemd-resolve[878503]: segfault at 208 ip 5557a249f5fa 
sp 7ffe686f5a90 error 6 in systemd-resolved[5557a2472000+4]
  [844395.313431] Code: 48 85 c0 74 0e 48 8b 8d 00 01 00 00 48 89 88 00 01 00 
00 48 8b 85 00 01 00 00 48 85 c0 0f 84 1d 01 00 00 48 8b 95 f8 00 00 00 <48> 89 
90 f8 00 00 00 48 c7 85 00 01 00 00 00 00 00 00 48 c7 85 f8

   * The upload backports the upstream fix
  (https://github.com/systemd/systemd/pull/18832) to Focal & Hirsute.

  [Test Plan]

   * Setup /etc/systemd/resolved.conf:
  [Resolve]
  DNS=46.182.19.48#dns2.digitalcourage.de 1.1.1.1#cloudflare-dns.com 
9.9.9.9#dns.quad9.net
  DNSSEC=yes
  DNSOverTLS=opportunistic
  MulticastDNS=no
  LLMNR=no
  Cache=yes
  DNSStubListener=yes
  Domains=~.

   * wait for ~24-48 hours and observe if any crash happens

  [Where problems could occur]

   * Any regression would likely cause crashes in systemd-resolved,
  making it unresponsive to DNS network name requests to local
  applications.

  [Other Info]
   
   * Reported upstream: https://github.com/systemd/systemd/issues/18427
   * Fixed upstream in v248: https://github.com/systemd/systemd/pull/18832

  === Original description ===

  
  systemd-resolve keep crashing and it is very annoying as sometimes it 
severely interrupt normal dns resolving.

  Last uploaded report is 2d9e7378-d89b-11eb-9e14-fa163ee63de6
  Typical error in dmesg:
  systemd-resolve[1792202]: segfault at 564ff982f3e0 ip 564ff982f3e0 sp 
7ffe2fd0b758 error 15

  apport hints me that problem is related to mdns

  #3  0x7f3e903c2f11 in sd_event_dispatch () from
  /lib/systemd/libsystemd-shared-245.so

  It might be (or not) related that some hosts with mdns in my network
  have ipv6 enabled.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.7
  ProcVersionSignature: Ubuntu 5.4.0-75.84-generic 5.4.119
  Uname: Linux 5.4.0-75-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jul  1 08:22:51 2021
  InstallationDate: Installed on 2018-12-05 (938 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  MachineType: System manufacturer System Product Name
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-75-generic 
root=UUID=54b80d5c-3d61-4919-873f-0d308083e3b9 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to focal on 2020-05-22 (405 days ago)
  dmi.bios.date: 05/12/2020
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1205
  dmi.board.asset.tag: Default string
  dmi.board.name: ROG STRIX X399-E GAMING
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 

[Touch-packages] [Bug 1942113] Re: systemd unit test regression in autopkgtest (oomd-utils)

2021-09-13 Thread Lukas Märdian
Merged upstream and staged in: https://git.launchpad.net/~ubuntu-core-
dev/ubuntu/+source/systemd/log/?h=ubuntu-impish

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

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

Title:
  systemd unit test regression in autopkgtest (oomd-utils)

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

Bug description:
  The latest systemd upload fails its tests against glibc 2.34. The
  failing test is test-oomd-util within the unit-tests, with the
  following logs:

  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Bus n/a: changing state UNSET → OPENING
  sd-bus: starting bus by connecting to /run/dbus/system_bus_socket...
  Bus n/a: changing state OPENING → AUTHENTICATING
  Bus n/a: changing state AUTHENTICATING → HELLO
  Sent message type=method_call sender=n/a destination=org.freedesktop.DBus 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 
reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
  Sent message type=method_call sender=n/a destination=org.freedesktop.DBus 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch 
cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a
  Got message type=method_return sender=org.freedesktop.DBus destination=:1.23 
path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s 
error-name=n/a error-message=n/a
  Bus n/a: changing state HELLO → RUNNING
  Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=StartTransientUnit cookie=3 reply_cookie=0 signature=ssa(sv)a(sa(sv)) 
error-name=n/a error-message=n/a
  Got message type=method_return sender=:1.0 destination=:1.23 path=n/a 
interface=n/a member=n/a cookie=299 reply_cookie=3 signature=o error-name=n/a 
error-message=n/a
  Got message type=signal sender=org.freedesktop.DBus destination=:1.23 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired 
cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a
  Got message type=method_return sender=org.freedesktop.DBus destination=:1.23 
path=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 signature=n/a 
error-name=n/a error-message=n/a
  Match 
type='signal',sender='org.freedesktop.systemd1',path='/org/freedesktop/systemd1',interface='org.freedesktop.systemd1.Manager',member='JobRemoved'
 successfully installed.
  Got message type=signal sender=:1.0 destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobRemoved cookie=304 reply_cookie=0 signature=uoss error-name=n/a 
error-message=n/a
  Got result done/Success for job test-oomd-util-9beb716b2ffb3d99.scope
  Bus n/a: changing state RUNNING → CLOSED
  Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
  test-oomd-util: Cannot set user xattrs, skipping tests.
  Error getting memory.current from 
/system.slice/test-oomd-util-9beb716b2ffb3d99.scope: No data available
  Assertion 'oomd_cgroup_context_acquire(cgroup, ) == 0' failed at 
src/oom/test-oomd-util.c:117, function 
test_oomd_cgroup_context_acquire_and_insert(). Aborting.

  I wasn't able to reproduce the failure, either using autopkgtest-virt-
  lxd or manually in an armhf VM. You'll find below the test logs of the
  VM run for this particular test, as a comparison point.

  ubuntu@autopkgtest:~$ sudo /usr/lib/systemd/tests/test-oomd-util 
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 2 for /zupa.slice. Using last 
pgscan of zero.
  Last pgscan 33 greater than current pgscan 1 for /herp.slice/derp.scope. 
Using last pgscan of zero.
  Bus n/a: 

  1   2   >