jjelen pointed to bug 1077115 which seems to be same issue.
Beah services run with bad context unconfined_service_t. Current fedora's package doesn't contain fix. It isn't possible to load module from package. # rpm -q beah beah-0.7.8-1.fc21.1.noarch # rpm -ql beah | grep "\.pp" /usr/share/selinux/packages/beah/beah.pp # semodule -i /usr/share/selinux/packages/beah/beah.pp libsepol.permission_copy_callback: Module beah depends on permission kill in class service, not satisfied (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed!
I find same bug for RHEL7 (bug 1077115). On Fedora 22 all beaker tasks failed due to this problem.
Is there any estimate when this bug will be fixed for fedora 22?
(In reply to Jan Hutař from comment #0) > https://beaker.engineering.redhat.com/jobs/964523 This job is suffering the same issue as described in [1], namely your recipe starts with RHEL7.0 and then upgrades to RHEL7.1 selinux policy. Workaround is described in [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1149988#c37 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1149988#c46 I don't know of any reasonable way we can handle that situation (RHEL7.0->RHEL7.1) in the beah package. So the first half of this bug is essentially a dupe of bz1149988 and CANTFIX. (In reply to Pavel Studeník from comment #3) > libsepol.permission_copy_callback: Module beah depends on permission kill in > class service, not satisfied (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! The beah policy failing to load on Fedora 22 is a totally separate issue. I suspect we just need to rebuild beah for F22 instead of reusing the F21 builds.
Just note, that the syntax is: <repo name="beaker-harness" url="http://download.lab.bos.redhat.com/beakerrepos/harness/Fedora22/"/> otherwise beaker complains. Now I can progress little bit further. Thanks for workaround and time estimation and confirmation that something is moving.
This was fixed some time ago (can't find the internal ticket right now). beaker.engineering.redhat.com is now using the correct Fedora 22 harness builds for Fedora 22.