Hide Forgot
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.
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.
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.
# restorecon -v /etc/group should fix. There is no transition if you run groupadd by hand.