Bug 1027032

Summary:	iceccd fails to start with capng error
Product:	[Fedora] Fedora	Reporter:	Jesse Barnes <jbarnes>
Component:	icecream	Assignee:	Michal Schmidt <mschmidt>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	20	CC:	mschmidt, sgrubb
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-19 10:23:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:	895105
Bug Blocks:

Description Jesse Barnes 2013-11-05 23:23:23 UTC

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 23:23:57 UTC

Oh and I have SElinux disabled as I figured that might be the culprit at first.

Comment 2 Jesse Barnes 2013-11-05 23:27:34 UTC

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 09:22:09 UTC

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 15:55:32 UTC

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 10:23:20 UTC

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 ***