Bug 1027032 - iceccd fails to start with capng error
iceccd fails to start with capng error
Status: CLOSED DUPLICATE of bug 1030457
Product: Fedora
Classification: Fedora
Component: icecream (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Michal Schmidt
Fedora Extras Quality Assurance
:
Depends On: 895105
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-05 18:23 EST by Jesse Barnes
Modified: 2013-11-19 05:23 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-19 05:23:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jesse Barnes 2013-11-05 18:23:23 EST
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:
Comment 1 Jesse Barnes 2013-11-05 18:23:57 EST
Oh and I have SElinux disabled as I figured that might be the culprit at first.
Comment 2 Jesse Barnes 2013-11-05 18:27:34 EST
Also found that icecream-0.9.7-3.fc18.x86_64.rpm from Fedora 18/19 works ok.
Comment 3 Michal Schmidt 2013-11-08 04:22:09 EST
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.
Comment 4 Steve Grubb 2013-11-15 10:55:32 EST
The problem in libcap-ng was fixed under bz 1030457. Everything should work fine using libcap-ng-0.7.3-6.fc20.
Comment 5 Michal Schmidt 2013-11-19 05:23:20 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.