Description of problem: iceccd fails to start Version-Release number of selected component (if applicable): icecream-1.0.1-5.fc20.x86_64 How reproducible: Everytime Steps to Reproduce: 1. iceccd -vvv -u icecream Actual results: Error: capng_change_id failed: -8 Expected results: iceccd starting and printing info about the cluster. Additional info:
Oh and I have SElinux disabled as I figured that might be the culprit at first.
Also found that icecream-0.9.7-3.fc18.x86_64.rpm from Fedora 18/19 works ok.
strace shows: ... prctl(PR_CAPBSET_DROP, 0x20, 0, 0, 0) = 0 prctl(PR_CAPBSET_DROP, 0x21, 0, 0, 0) = 0 prctl(PR_CAPBSET_DROP, 0x22, 0, 0, 0) = 0 prctl(PR_CAPBSET_DROP, 0x23, 0, 0, 0) = 0 prctl(PR_CAPBSET_DROP, 0x24, 0, 0, 0) = 0 prctl(PR_CAPBSET_DROP, 0x25, 0, 0, 0) = -1 EINVAL (Invalid argument) write(2, "Error: capng_change_id failed: ", 31Error: capng_change_id failed: ) = 31 There used to be a capability 0x25 == 37 defined in Fedora kernels for a while. It was CAP_COMPROMISE_KERNEL (it came from Secure Boot patches). This was later removed. I suspect we have libcap-ng built against the older kernel-headers. (As a workaround you could try doing a local rebuild of libcap-ng). This wouldn't be a problem if libcap-ng detected the set of capabilities supported by the kernel at runtime. This is bug 895105.
The problem in libcap-ng was fixed under bz 1030457. Everything should work fine using libcap-ng-0.7.3-6.fc20.
Thanks. It works for me. And I see that a fix for bug 895105 is also being implemented, which will prevent a similar problem from happening in the future. *** This bug has been marked as a duplicate of bug 1030457 ***