Red Hat Bugzilla – Bug 1027032
iceccd fails to start with capng error
Last modified: 2013-11-19 05:23:20 EST
Description of problem:
iceccd fails to start
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. iceccd -vvv -u icecream
Error: capng_change_id failed: -8
iceccd starting and printing info about the cluster.
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.
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 ***