Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 374091 [details] from yumex log Description of problem: Updating to abrt.x86_64 0:1.0.0-1.fc12 with utdates testing and lockdev.x86_64 0:1.0.1-17.fc12 geve error on yumex log Version-Release number of selected component (if applicable): yumex-2.9.4-1.fc12.noarch yum-3.2.25-1.fc12.noarch How reproducible: Steps to Reproduce: 1. update with yumex using updates testing abrt.x86_64 0:1.0.0-1.fc12 lockdev.x86_64 0:1.0.1-17.fc12 ( last ot from updates testing ) 2. 3. Actual results: 00:04:42 : YUM: /var/tmp/rpm-tmp.GHr79l: line 1: /usr/sbin/groupadd: Permission denied 00:04:42 : YUM: Error in PREIN scriptlet in rpm package lockdev-1.0.1-17.fc12.x86_64 more in attachment Expected results: successfull update Additional info: something is missing to boot kernel-2.6.31.6-145.fc12.x86_64
I have now updated with yum kernel-2.6.31.6-145.fc12.x86_64 abrt.x86_64 0:1.0.0-1.fc12 lockdev.x86_64 0:1.0.1-17.fc12 I removed with yum kernel-2.6.31.6-145.fc12.x86_64 and then updated with yum initramfs-2.6.31.6-145.fc12.x86_64.img was about 6 Mb bout not 11729176 b I am not sure why. I might have shutdow during update
this is a scriptlet error in lockdev, it seems. Reassigning there.
Hi. I wasn't able to reproduce the problem with kernel-2.6.31.6-145.fc12.x86_64 nor kernel-2.6.31.5-127.fc12.x86_64
Description of this bug: In lockdev.spec's %pre section group lock is added with groupadd command. Yumex unfortunately denies permission to /usr/sbin/groupadd. 7:58:46 : YUM: /var/tmp/rpm-tmp.Qt8Exz: line 1: /usr/sbin/groupadd: Permission denied I fixed the lockdev.spec's %pre section according to http://fedoraproject.org/wiki/Packaging/UsersAndGroups so now (lockdev-1.0.1-19.fc12) it looks like this: getent group lock >/dev/null || groupadd -g 54 -r -f lock exit 0 so the groupadd command isn't called when lock group already exists (lock:x:54 group is in /etc/group by default so there's no problem even when installing lockdev for the first time with yumex). This fixes this one problem (when upgrading lockdev with yumex), but I think there's still problem with yumex, which denies permission to /usr/sbin/groupadd. As you can see in attached log here https://bugzilla.redhat.com/show_bug.cgi?id=543638#c0 YUM doesn't have problem with /usr/sbin/groupadd in %pre section. I guess all packages which are trying to add a group (/usr/sbin/groupadd) in %pre section are seeing this error when being installed/upgraded with yumex.
My guess is right. I get 10:29:28 : YUM: /var/tmp/rpm-tmp.RNnPrf: line 1: /usr/sbin/groupadd: Permission denied 10:29:28 : YUM: Error in PREIN scriptlet in rpm package abrt-1.0.0-1.fc12.x86_64 10:29:28 : YUM: RPM Scriptlet: error: %pre(abrt-1.0.0-1.fc12.x86_64) scriptlet failed, exit status 126 10:29:28 : YUM: error: install: %pre scriptlet failed (2), skipping abrt-1.0.0-1.fc12 when upgrading (or removing and installing again) abrt package in yumex. abrt.spec's %pre section looks like: %pre /usr/sbin/groupadd -f --system abrt
yumex cannot be the culprit here. It doesn't have any facilities to intercept and deny permission for scriptlets running in an rpm transaction. over to rpm.
Rpm doesn't deny permissions either. This is a SELinux-issue, AFAICT dupe of bug 527528.
[root@dhcp102 rpm]# ls -lZ /usr/bin/yumex -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/yumex ^^^^^ There's the problem, for rpm_execcon() to succeed rpm_exec_t context is needed and "chcon -t rpm_exec_t /usr/bin/yumex" fixes this. *** This bug has been marked as a duplicate of bug 527528 ***