2020-11-23 08:16:08 |
Gary van der Merwe |
bug |
|
|
added bug |
2020-11-23 20:17:55 |
Matthieu Clemenceau |
tags |
|
rls-bb-incoming rls-ff-incoming |
|
2020-11-23 20:34:27 |
Dan Streetman |
description |
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap, so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
TBD
[scope]
this is needed only in focal (and possibly bionic).
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle.
For b, unless a kernel is added that includes a new capability, this patch is not needed.
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
|
2020-11-23 20:34:35 |
Dan Streetman |
nominated for series |
|
Ubuntu Bionic |
|
2020-11-23 20:34:35 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Bionic) |
|
2020-11-23 20:34:35 |
Dan Streetman |
nominated for series |
|
Ubuntu Focal |
|
2020-11-23 20:34:35 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Focal) |
|
2020-11-23 20:34:39 |
Dan Streetman |
systemd (Ubuntu): status |
New |
Fix Released |
|
2020-11-23 20:35:52 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
2020-11-23 21:05:03 |
Dan Streetman |
description |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap, so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
TBD
[scope]
this is needed only in focal (and possibly bionic).
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle.
For b, unless a kernel is added that includes a new capability, this patch is not needed.
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in focal (and possibly bionic).
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle.
For b, unless a kernel is added that includes a new capability, this patch is not needed.
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
|
2020-11-23 21:57:33 |
Dan Streetman |
systemd (Ubuntu Focal): assignee |
|
Dan Streetman (ddstreet) |
|
2020-11-23 21:57:35 |
Dan Streetman |
systemd (Ubuntu Focal): importance |
Undecided |
Medium |
|
2020-11-23 21:57:38 |
Dan Streetman |
systemd (Ubuntu Focal): status |
New |
In Progress |
|
2020-11-24 14:22:28 |
Matthieu Clemenceau |
tags |
rls-bb-incoming rls-ff-incoming |
fr-963 rls-bb-incoming rls-ff-incoming |
|
2020-12-10 16:33:31 |
Matthieu Clemenceau |
tags |
fr-963 rls-bb-incoming rls-ff-incoming |
fr-963 |
|
2020-12-10 21:43:15 |
Dan Streetman |
systemd (Ubuntu Bionic): assignee |
|
Dan Streetman (ddstreet) |
|
2020-12-10 21:43:16 |
Dan Streetman |
systemd (Ubuntu Bionic): importance |
Undecided |
Medium |
|
2020-12-10 21:43:18 |
Dan Streetman |
systemd (Ubuntu Bionic): status |
New |
In Progress |
|
2020-12-15 15:09:52 |
Dan Streetman |
description |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in focal (and possibly bionic).
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle.
For b, unless a kernel is added that includes a new capability, this patch is not needed.
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in b and f.
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
Though b is unlikely to have the 5.8 kernel backported directly during its remaining lifetime, this bug is reproducable when running a b container on a host system with the 5.8 kernel, so this is needed for b.
This bug was introduced upstream with commit dd1f5bd0aa584c5e5e10fddc735155c3501eb21e which was first included in v235, so this bug does not exist in x.
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
|
2020-12-15 15:14:36 |
Dan Streetman |
description |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in b and f.
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
Though b is unlikely to have the 5.8 kernel backported directly during its remaining lifetime, this bug is reproducable when running a b container on a host system with the 5.8 kernel, so this is needed for b.
This bug was introduced upstream with commit dd1f5bd0aa584c5e5e10fddc735155c3501eb21e which was first included in v235, so this bug does not exist in x.
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in focal (and possibly bionic).
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle.
For b, unless a kernel is added that includes a new capability, this patch is not needed.
[other info]
there is a testcase-only related bug 1905044
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
|
2020-12-29 20:10:25 |
Christopher M. Fuhrman |
bug |
|
|
added subscriber Christopher M. Fuhrman |
2021-01-10 01:50:06 |
Trevor Green |
bug |
|
|
added subscriber Trevor Green |
2021-01-11 20:20:14 |
Dan Streetman |
systemd (Ubuntu Focal): importance |
Medium |
High |
|
2021-01-11 20:20:23 |
Dan Streetman |
systemd (Ubuntu Bionic): importance |
Medium |
High |
|
2021-01-11 20:58:55 |
Dan Streetman |
description |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in focal (and possibly bionic).
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
this was introduced externally from systemd, with the new capability in the kernel, so this fix technically is needed in x/b/f. However, x is unlikely to get a new kernel capability during the rest of its life cycle.
For b, unless a kernel is added that includes a new capability, this patch is not needed.
[other info]
there is a testcase-only related bug 1905044
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
[impact]
newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show'
[test case]
install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel.
Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it:
ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor
Failed to parse bus message: Invalid argument
the command should correctly show the value, e.g.:
$ systemctl show -p CapabilityBoundingSet apparmor
CapabilityBoundingSet=cap_chown cap_dac_override ...etc...
[regression potential]
a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services.
[scope]
this is needed only in focal and bionic.
This is fixed upstream by PR 16424:
https://github.com/systemd/systemd/pull/16424
which was first included in v246, so this is already fixed in groovy and later.
This was introduced upstream in systemd by commit 52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in v235, so this bug does not exist in Xenial.
This bug will reproduce on any system running under the 5.8 kernel, with the new capability, if the systemd binary was compiled with kernel headers that do not include the new capability. This means this is reproducable on bare-metal/vm instances running 5.8, as well as containers on hosts running 5.8. Therefore, while bionic may not ever receive a new kernel with added capability, it still needs to be patched to avoid the bug on a bionic container running on a host with the 5.8 kernel.
[other info]
there is a testcase-only related bug 1905044
[original description]
When I run `systemctl show myservice.service`, I get the following error message:
Failed to parse bus message: Invalid argument
systemd version: 245.4-4ubuntu3.3
linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge)
This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926
Please can we port the fix to the ubuntu 20.04 version. |
|
2021-01-11 22:06:33 |
Chris Halse Rogers |
systemd (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
2021-01-11 22:06:37 |
Chris Halse Rogers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2021-01-11 22:06:41 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
2021-01-11 22:06:50 |
Chris Halse Rogers |
tags |
fr-963 |
fr-963 verification-needed verification-needed-focal |
|
2021-01-11 22:24:01 |
Chris Halse Rogers |
systemd (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
2021-01-11 22:24:12 |
Chris Halse Rogers |
tags |
fr-963 verification-needed verification-needed-focal |
fr-963 verification-needed verification-needed-bionic verification-needed-focal |
|
2021-01-13 19:59:32 |
Dan Streetman |
tags |
fr-963 verification-needed verification-needed-bionic verification-needed-focal |
fr-963 verification-done verification-done-bionic verification-done-focal |
|
2021-01-15 23:30:57 |
Andrew Hayzen |
bug |
|
|
added subscriber Andrew Hayzen |
2021-01-18 09:48:38 |
Launchpad Janitor |
systemd (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
2021-01-18 09:49:09 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2021-01-18 10:40:45 |
Launchpad Janitor |
systemd (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|