Comments
mjw
Needs to go together with annobin
@kdudka ok lets remove that bug from the advisory then. It did seem to work for me with 3.18.1. So could you update the bug with some more info? Thanks,
Sorry for messing up the versioning. There is now a elfutils-0.185-3.fc35.
This update has been unpushed.
Sorry, found an issue. This build enables debuginfod.fedoraproject.org by default. It works, but we agreed to only do that for rawhide/f35. I'll cancel this build and submit a new one with the debuginfod URL disabled by default for f34.
We found an issue with the aarch64 fma fix. But good news is we have a better fix. Will respin a build with the fixed fix.
This update has been unpushed.
Thanks! With this update all the valgrind gdbserver_tests PASS.
== 26 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
With this I could rebuild elfutils on ppc64le again with all tests passing. Thanks.
Works for me, fixing the slowdown.
The f23 and f24 branches are currently equal. The code should compile with both gcc5 and gcc6.
That fixes the bug for me. Thanks.
sigh, messed up the symbols in the new bodhi. Sorry.
Thanks this fixes bug #1253926 for me.
Filed a bug report with a simple reproducer that doesn't require any updated package: https://bugzilla.redhat.com/show_bug.cgi?id=1253926 It is strange though. I am sure this used to work. It must be some other update that triggered this change in behavior.
This comes from the fact that elfutils-libs now pulls in default-yama-scope which installs /usr/lib/sysctl.d/10-default-yama-scope.conf which systemd-sysctl tries to execute. But systemd-sysctl is blocked by selinux from setting that sysctl. I assume this was only tested with selinux disabled. Hohum. Not good. With selinux enabled you can easily reproduce: $ systemctl start systemd-sysctl.service Job for systemd-sysctl.service failed. See "systemctl status systemd-sysctl.service" and "journalctl -xe" for details. $ systemctl status systemd-sysctl.service â systemd-sysctl.service - Apply Kernel Variables Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2015-08-15 15:59:19 CEST; 35min ago Docs: man:systemd-sysctl.service(8) man:sysctl.d(5) Process: 728 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE) Main PID: 728 (code=exited, status=1/FAILURE) Aug 15 15:59:19 blokker systemd[1]: Starting Apply Kernel Variables... Aug 15 15:59:19 blokker systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE Aug 15 15:59:19 blokker systemd[1]: Failed to start Apply Kernel Variables. Aug 15 15:59:19 blokker systemd[1]: Unit systemd-sysctl.service entered failed state. Aug 15 15:59:19 blokker systemd[1]: systemd-sysctl.service failed. The logs also show a workaround: Aug 15 16:36:11 blokker python[2930]: SELinux is preventing /usr/lib/systemd/systemd-sysctl from using the sys_ptrace capability. * Plugin catchall (100. confidence) suggests ****** If you believe that systemd-sysctl should have the sys_ptrace capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-sysctl /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp That policy allows things to work again. So it would
be good to get this fixed in the selinux policy for systemd_sysctl_exec_t. But before that is fixed it might be good to comment out the setting in the default-yama-scope
Needs to go together with gcc