From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322 Description of problem: Note: I'm running on x86_64 (2 x dual core Opterons) When trying to install postgresql-server and freeradius, I get the following: # yum -y install freeradius postgresql-server Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package postgresql-server.x86_64 0:8.0.4-2.FC4.1 set to be updated ---> Package freeradius.x86_64 0:1.0.4-1.FC4.1 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: freeradius x86_64 1.0.4-1.FC4.1 updates-released 1.2 M postgresql-server x86_64 8.0.4-2.FC4.1 updates-released 3.8 M Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 5.0 M Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction error: %pre(freeradius-1.0.4-1.FC4.1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping freeradius-1.0.4-1.FC4.1 error: %pre(postgresql-server-8.0.4-2.FC4.1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping postgresql-server-8.0.4-2.FC4.1 Earlier, when I were installing thse packages together with accompanying ones (postgresql-libs, etc) there were script errors for those packages, too, but they've installed anyhow, since those scriptlets were post-install, not pre-install: Transaction Summary ============================================================================= Install 12 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 25 M Downloading Packages: (1/9): freeradius-1.0.4-1 100% |=========================| 1.2 MB 00:00 (2/9): net-snmp-utils-5.2 100% |=========================| 172 kB 00:00 (3/9): postgresql-debugin 100% |=========================| 10 MB 00:01 (4/9): freeradius-debugin 100% |=========================| 1.0 MB 00:00 (5/9): postgresql-pl-8.0. 100% |=========================| 65 kB 00:00 (6/9): postgresql-docs-8. 100% |=========================| 4.6 MB 00:00 (7/9): net-snmp-5.2.1.2-f 100% |=========================| 604 kB 00:00 (8/9): lm_sensors-2.9.1-3 100% |=========================| 477 kB 00:00 (9/9): dmidecode-2.6-1.14 100% |=========================| 28 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: postgresql-libs ####################### [ 1/12] error: %post(postgresql-libs-8.0.4-2.FC4.1.x86_64) scriptlet failed, exit status 255 Installing: postgresql ####################### [ 2/12] error: %pre(postgresql-server-8.0.4-2.FC4.1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping postgresql-server-8.0.4-2.FC4.1 Installing: dmidecode ####################### [ 4/12] Installing: lm_sensors ####################### [ 5/12] error: %post(lm_sensors-2.9.1-3.FC4.2.x86_64) scriptlet failed, exit status 255 Installing: net-snmp ####################### [ 6/12] error: %post(net-snmp-5.2.1.2-fc4.1.x86_64) scriptlet failed, exit status 255 Installing: net-snmp-utils ####################### [ 7/12] error: %pre(freeradius-1.0.4-1.FC4.1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping freeradius-1.0.4-1.FC4.1 Installing: postgresql-debuginfo ####################### [ 9/12] Installing: freeradius-debuginfo ####################### [10/12] Installing: postgresql-pl ####################### [11/12] error: %post(postgresql-pl-8.0.4-2.FC4.1.x86_64) scriptlet failed, exit status 255 Installing: postgresql-docs ####################### [12/12] Version-Release number of selected component (if applicable): 8.0.4-2.FC4.1 How reproducible: Always Steps to Reproduce: 1. Try to install postgresql-server or freeradius with yum. Additional info:
I don't think this is a postgres issue. The %post failures are happening for several packages. In particular, the only %post action that postgresql-libs has at all is /sbin/ldconfig. I'll bet that all the packages that are showing problems are trying to run ldconfig, and that's what's failing. What do you see if you try to run ldconfig manually?
It runs successfully: # ldconfig && echo OK || echo BAD OK But you're right, there seems to be a general problem with rpm, seemingly all scripts fail, not only those involving ldconfig: # rpm -ihv postgresql-server-8.0.4-2.FC4.1.x86_64.rpm Preparing... ########################################### [100%] error: %pre(postgresql-server-8.0.4-2.FC4.1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping postgresql-server-8.0.4-2.FC4.1 # rpm -qp --scripts postgresql-server-8.0.4-2.FC4.1.x86_64.rpm preinstall scriptlet (using /bin/sh): groupadd -g 26 -o -r postgres >/dev/null 2>&1 || : useradd -M -n -g postgres -o -r -d /var/lib/pgsql -s /bin/bash \ -c "PostgreSQL Server" -u 26 postgres >/dev/null 2>&1 || : # If we're upgrading from rh-postgresql, we have to repeat the above actions # after rh-postgresql-server is uninstalled, because its postun script runs # after our pre script ... postinstall scriptlet (using /bin/sh): chkconfig --add postgresql /sbin/ldconfig preuninstall scriptlet (using /bin/sh): if [ $1 = 0 ] ; then /sbin/service postgresql condstop >/dev/null 2>&1 chkconfig --del postgresql fi postuninstall scriptlet (using /bin/sh): /sbin/ldconfig if [ $1 -ge 1 ] ; then /sbin/service postgresql condrestart >/dev/null 2>&1 || : fi if [ $1 = 0 ] ; then userdel postgres >/dev/null 2>&1 || : groupdel postgres >/dev/null 2>&1 || : fi Maybe this could be related: I've added the "tsflags=repackage" option to yum.conf to get the RPM rollback functionality. So during all upgrades and erases, RPM has been repackaging the installed packages. But the scripts currently fail regardless of repackage being used or not. Doing "rpm --rebuilddb" doesn't help, either. Should I change the component from postgresql to rpm?
Created attachment 122557 [details] bzipped output from "strace -f rpm -iv postgresql-server-8.0.4-2.FC4.1.x86_64.rpm" This is output from running "strace -f rpm -iv postgresql-server-8.0.4-2.FC4.1.x86_64.rpm". It's over 600 kb, so it's compressed with bzip2. Use bzcat to view it. It may contain hints as to why the scriptlets fail.
Especially the following looks suspicious: [pid 8668] open("/proc/self/attr/exec", O_RDWR) = 9 [pid 8668] write(9, "root:staff_r:rpm_script_t\0", 26) = -1 EINVAL (Invalid argument) [pid 8668] close(9) = 0 [pid 8668] exit_group(-1) = ? Seems that forked rpm instance does some SELinux related stuff before exec-ing the shell that would execute the scriptlet which lies in /var/tmp/rpm-tmp.79370 Writing to /proc/self/attr/exec fails... What's the semantics of such operation? Switching SELinux contexts? Anyway, this is apparently rpm problem, so I'm changing the component.
Hard to tell if this is RPM or SELinux messing up. Do you have SELinux in enforcing mode, and if so does turning it off make a difference? Also, at this point it'd behoove you to mention the rpm and selinux-policy package versions.
No, SELinux has been in permissive mode since the system installation. Also, selinux doesn't log any errors to kernel log when I try to install postgresql.
rpm code does not open /proc/self/attr/exec, libselinux code does. Changing component.
What version of policy do you have installed? Also what does id -Z show? You are trying to install with the staff_r role for some reason which should not happen in targetd policy.
strict, running in permissive mode. SELinux packages have the following versions: libselinux-1.23.10-2 libselinux-1.23.10-2 libselinux-devel-1.23.10-2 selinux-policy-strict-1.27.1-2.16 selinux-policy-strict-sources-1.27.1-2.16 selinux-policy-targeted-1.27.1-2.16
I do all work through SSH, but I'm put in the staff_r role when opening SSH session: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:staff_r:staff_t That's strange, since /etc/selinux/strict/users/system.users has the root user defined as: user root roles { sysadm_r staff_r secadm_r system_r };
grep for sshd in /etc/selinux/strict/contexts/default_context. This is how the program decides what is the default contexts to run a login session as. The program should not be failing in permissive mode. I will check the libselinux version to make sure it allows continues even on failure. But in strict policy you should newrole -r sysadm_r before running rpm. If you were running in enforcing mode rpm should fail to install.
Fixed in libselinux-1.23.11-1.1
Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists in a current Fedora release (such as Fedora Core 5 or later), please reopen and set the version appropriately.