Bug 753915

Summary: systemtap PREIN failure
Product: [Fedora] Fedora Reporter: Eric Blake <eblake>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dominick.grift, dsmith, dwalsh, fche, ffesti, james.antill, jistone, maxamillion, mgrepl, mjw, pmatilai, pmuller, scox, tla, wcohen, zpavlas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 753849 Environment:
Last Closed: 2011-11-15 10:47:40 UTC Type: ---
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: 753849    
Bug Blocks:    

Description Eric Blake 2011-11-14 20:50:10 UTC
Cloning to systemtap, per the original comment 4.

+++ This bug was initially created as a clone of Bug #753849 +++

Description of problem:
I tried 'yum update libvirt', but yum failed and told me to report this bug.

Version-Release number of selected component (if applicable):
libvirt-0.9.7-1.fc17.i686
yum-3.4.3-11.fc17.noarch

How reproducible:
100%

Steps to Reproduce:
1. 'yum update libvirt'
2.
3.
  
Actual results:
...
Running Transaction Check
ERROR with transaction check vs depsolve:
/usr/bin/stap is needed by libvirt-devel-0.9.7-2.fc17.i686
Please report this error in https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=yum


Expected results:
upgrade should just work

Additional info:

--- Additional comment from eblake on 2011-11-14 10:04:53 MST ---

'yum install systemtap' resolved the problem, but that makes it seem like updating libvirt when libvirt-devel is installed should have automatically pulled in systemtap since it provides /usr/bin/stap.

--- Additional comment from eblake on 2011-11-14 10:13:12 MST ---

Actually, 'yum install systemtap' is failing:

Error in PREIN scriptlet in rpm package systemtap-1.6-1.fc16.i686
error: %pre(systemtap-1.6-1.fc16.i686) scriptlet failed, exit status 10

So maybe the problem here is that because systemtap isn't getting properly installed, then libvirt-devel doesn't work.

--- Additional comment from james.antill on 2011-11-14 13:39:22 MST ---

 If you can still reproduced the first problem ... we need more of the text, to try and see what is going wrong.

--- Additional comment from james.antill on 2011-11-14 13:40:02 MST ---

 Note that the problem in comment #2 is a bug in the systemtap packaging, that shouldn't happen, and should be reported there.

Comment 1 Frank Ch. Eigler 2011-11-14 21:34:34 UTC
Thanks for the problem report.
I have trouble seeing what the .spec file problem might be;
there is only this in the %pre:

%pre
getent group stap-server >/dev/null || groupadd -g 155 -r stap-server || groupadd -r stap-server

I see groupadd can fail with an rc=10 for "can't update group file", but that
doesn't seem like a bug in systemtap packaging as far as I can see.

Comment 2 Eric Blake 2011-11-14 22:02:39 UTC
Interesting - when I ran 'groupadd -g 155 -r stap-server' by hand, things worked, but when it got run during yum upgrade, it fails with a SELinux violation:

[  343.509144] type=1400 audit(1321307909.590:7): avc:  denied  { write } for  pid=1244 comm="groupadd" name="group" dev=dm-1 ino=11373 scontext=unconfigured_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file
[  343.521056] type=1400 audit(1321307909.601:8): avc:  denied  { write } for  pid=1245 comm="groupadd" name="group" dev=dm-1 ino=11373 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file

I'll reassign this to selinux for help.  Probably something in policy needs to be relaxed to allow rpm installation to create groups when run under context created by yum.

Comment 3 Miroslav Grepl 2011-11-15 10:47:40 UTC
# restorecon -v /etc/group

should fix.

There is no transition if you run groupadd by hand.