$ reverse-depends -b -r xenial libseccomp-dev
Reverse-Build-Depends
=
* golang-github-seccomp-libseccomp-golang
* lxc
* ocserv
* qemu
* systemd
* tor
* ubuntu-core-launcher
none of these appear to reference pkey_mprotect, so none should need a
rebuild with the xenial-hwe
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag
to close this out, the latest systemd build, version 237-3ubuntu10.25,
picked up the correct pkey_mprotect value from the updated kernel and
now does not fail the test.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
This bug was fixed in the package linux - 4.15.0-55.60
---
linux (4.15.0-55.60) bionic; urgency=medium
* linux: 4.15.0-55.60 -proposed tracker (LP: #1834954)
* Request backport of ceph commits into bionic (LP: #1834235)
- ceph: use atomic_t for ceph_inode_info::i_shared_gen
I agree with the analysis in comment #13 about stress-ng.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1821625
Title:
systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el
$ reverse-depends -l -r bionic -b libseccomp-dev |& xargs
apt chrony docker.io flatpak gnome-desktop3
golang-github-seccomp-libseccomp-golang kscreenlocker lxc man-db ocserv
qemu snapd stenographer systemd tor tracker-miners usbguard
none of those packages reference pkey_mprotect except systemd,
> Per [1] this symbol is present in: firejail, elogind, valgrind, glibc, musl,
> linux,
> systemd, strace, stress-ng, libseccomp, qemu
tl;dr: it looks like glibc and stress-ng are the only packages from that
list that might need a rebuild, but as with systemd, neither seem
important enough to
Marking this bug as Invalid for libseccomp; I still disagree with their
upstream decision re: their header file, but it doesn't appear any
rebuild or SRU code change is needed for it for this bug.
--
You received this bug notification because you are a member of Kernel
Packages, which is
> @Dan did that already contain the fix you expect or would considering
a seccomp be useful?
For libseccomp, it looks like it doesn't need a rebuild; it appears to
only reference the symbol in its header (which is what causes this
problem for other packages that pull in that header); in its code,
Per [1] this symbol is present in: firejail, elogind, valgrind, glibc,
musl, linux, systemd, strace, stress-ng, libseccomp, qemu
At least for qemu I checked and those are only references in the
embedded linux headers. No rebuild needed for that, most of the others
seem safe as well - maybe
systemd will require a rebuild to pick up this fix in the kernel
headers, but that happens often enough I don't think a no-change rebuild
is needed.
Also, these packages reverse-dep on the libseccomp-dev package (that
provides the faulty __NR_pkey_mprotect define) so they might need
rebuilding as
I rebuilt systemd using the 4.15.0-55 kernel headers:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1821625.2
and the test now passes:
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag
** Changed in: linux (Ubuntu Bionic)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1821625
Title:
systemd 237-3ubuntu10.14 ADT test failure
FYI, please note that seccomp 2.4.1 was pushed to bionic in
https://usn.ubuntu.com/4001-1/ on 2019/05/30. It shouldn't affect this
bug report AFAICT because while the 2.4.1 Ubuntu packaging drops these
patches, the upstream commits for lp-1815415-arch-update-syscalls-for-
Linux-4.9.patch and
I'm leaving this as marked against libseccomp, as I don't understand why
it is redefining kernel header values as invalid numbers in its public
header file (so that other programs using its header files pull in those
invalid syscall numbers). I don't think it should but I'll leave the
decision to
> After these patches are applied to bionic, both libseccomp and systemd
> will need to be rebuilt - libseccomp rebuilt against the kernel
> headers, and systemd against the libseccomp headers.
technically both will need to be rebuilt against the new kernel headers,
but systemd doesn't need to
coverletter explanation as sent to kernel-team list:
In bionic, all archs provided by Ubuntu either define __NR_pkey_mprotect
i marked this as against both libseccomp and the kernel, but as I
mentioned in the last comment, only 1 of them needs fixing. My
suggestion for the best approach is to add pkey_mprotect support to the
bionic ppc64el kernel.
--
You received this bug notification because you are a member of
This is not a bug in systemd.
The problem is that libseccomp was patched at version
2.3.1-2.1ubuntu4.1, in d/p/lp-1815415-arch-update-syscalls-for-
Linux-4.9.patch, to add a definition for the pkey_mprotect syscall. The
systemd test case checks for the definition of this syscall, and uses it
if
20 matches
Mail list logo
