From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051103 Fedora/1.5-0.5.0.rc1 Firefox/1.5 Description of problem: I am seeing random rpm script failures with exit status 255. The scripts vary from /sbin/ldconfig to complex scripts. 80% of all rpms being installed fail in one way or another - I see %post, %pre, %trigger, %postun, %preun scripts failing. This is starting to drive me crazy, because things like the fontconfig %post script not executing cause every login/graphical program linked to the fonts library to crash. There's very severe consequences to installing packages when the scripts aren't working. For example, the rpm %pre script fails, the openssl update proceeds... end result: rpm can no longer link to libssl.so.5, and my rpm command does not work. I've been seeing this bug for at least 1.5-2 weeks - haven't reported it yet, since I've been busy, and it might be specific to my machine.. but if it isn't, then it should block FC5. ================================================ Any ideas? Version-Release number of selected component (if applicable): rpm-4.4.2-7 How reproducible: Always Steps to Reproduce: 1. Install various rpms that use scripts 2. Scripts fail with status 255 Additional info:
Well, the code in rpm-4.4.2-7 has not changed a whit in the last 1.5 to 2 weeks, that's a Great Big Hint that this is a problem with your machine, or other software, not rpm.
A "problem with my machine" is usually a software bug that nobody has ran into yet, but I have. I find it strange that the exit code of all these scripts is 255 - why? I have a ton of rpms installed (all of core, all of extras, all of livna, and more on top of that). Is that relevant? I run SELinux in permissive mode...
Strange. I saw a lot of the 255 error codes recently, just as you describe, but I was sure that it was only on machines that were in enforcing mode. Whay I did was to set them to permissive. Reboot, clean up the rpms, run "fixfiles relabel", set back to enforcing, reboot. I haven't seen any more of the "255" messages in the last three days of updates.
I relabeled my system and was still having trouble with the scriplets problem. There was a large list of rpms that would download via rpm and fail because of a scriplet problem. Since other packages were pulled in and yum expected the deps to be met, some packages were successfully upgraded while rpm (or yum) exited the script. This left older versions of rpm, xorg-x11-xfs and an assortment of other programs behind. Rpm would not function since it was actually never updated when openssl was updated. rpm wanted so.5 version liblraries and openssl provided so.6 versions. Of course rpm complained about the shared library not being available. I'll add the listing of rpms that downloaded and never installed later when I'm at the computer that the scriplets failed on.
The ones that don't install are the ones that fail the %pre script. If the %post fails, or the %postun of the old package, then rpm proceeds to install the package. If the %postun fails, you get two packages in the database for the same thing (I use rpm --e --justdb to fix). I actually used rpm to upgrade things, but if you used yum, then this shows a flaw in the transaction system - I would think a failed install of any rpm should abort the whole transaction. To recover your system link .so.6 as .so.5 and lie to rpm.
No thats not how it works. RPM by default uses a best effort strategy for running transactions (provided all pre transaction checks pass, such as dep resolution, disk space utilization, etc.). In the case of an installer like anaconda, and in many environments (though not in mine) this is the sanest policy, because you will likely still end up with a runable system though one package fails to install (or a few, and it depends on which one). There is work to provide for automatic rollbacks of failed transactions, but this is experimental code at the moment. Obviously another possible policy is to be able to have the transaction just halt, but no code as yet has been put in to allow for this experimental or otherwise. Write an RFE if you would like to see said functionality. Cheers...james
I'm not sure whether it makes sense to use "best effort" and "transaction" in the same sentence. Isn't the point of a transaction to ensure atomic commit (to whatever degree is possible), and to prevent the disaster that is happening here. The system would be in good state either by not upgrading anything, or by upgrading everything. Doing a partial upgrade just leaves it in corrupted state. Whether it's "runnable" or not after that is uncertain. I guess I would like to see this functionality, but that's not what this bug is about.
Comment #4 seems to indicate an SELinux problem (libselinux, not rpm, does scriptlet execs). Reassigning ...
Hm... I agree that this is the likely cause - I do not see rpm_execcon doing a mode check. The function can cause a failure even in permissive mode, which is a bug. I am also wondering why this function exists in a shared library in the first place... My selinux setup is in complete chaos, since I work on libsemanage/libsepol, so I'm sure something probably fails... have found lots of bugs that way :)
I have failures from both multiple entries for old and new packages. The problem with rpms downloading but not installing via yum was similar to failures encountered when rpm was used to try to install packages in the yum cache that did not show as being installed. The packages which never installed were below. I'll attach the avc errors from messages and messages.1 since SELinux libraries seem to be the culpret. anaconda.i386 10.89.12-1 anaconda-runtime.i386 10.89.12-1 bind.i386 24:9.3.1-21 binutils.i386 2.16.91.0.3-1 classpathx-mail.noarch 1.0-4jpp_3fc classpathx-mail-javadoc.noarch 1.0-4jpp_3fc cpp.i386 4.0.2-6 ddd.i386 3.3.11-4 dovecot.i386 0.99.14-10.fc5 dvgrab.i386 2.0-1 fedora-logos.noarch 1.1.34-1 freeradius.i386 1.0.4-5 freeradius-mysql.i386 1.0.4-5 freeradius-postgresql.i386 1.0.4-5 freeradius-unixODBC.i386 1.0.4-5 gcc.i386 4.0.2-6 gcc-c++.i386 4.0.2-6 gcc-gfortran.i386 4.0.2-6 gcc-gnat.i386 4.0.2-6 gcc-java.i386 4.0.2-6 gcc-objc.i386 4.0.2-6 gkrellm-daemon.i386 2.2.7-4 gnome-panel.i386 2.12.1-5 gphoto2.i386 2.1.6-6 gphoto2-devel.i386 2.1.6-6 gtkhtml3.i386 3.8.1-2 hal.i386 0.5.4.cvs20051111-1 hal-devel.i386 0.5.4.cvs20051111-1 hal-gnome.i386 0.5.4.cvs20051111-1 httpd.i386 2.0.54-16 iproute.i386 2.6.14-9 jwhois.i386 3.2.3-3 kbd.i386 1.12-11 kernel.i686 2.6.14-1.1663_FC5 kernel-devel.i686 2.6.14-1.1663_FC5 kernel-doc.noarch 2.6.14-1.1663_FC5 lftp.i386 3.3.3-1 libavc1394.i386 0.5.1-1 libavc1394-devel.i386 0.5.1-1 libdbi.i386 0.8.1-1 libdbi-dbd-mysql.i386 0.8.1a-1 libdbi-dbd-pgsql.i386 0.8.1a-1 libdbi-devel.i386 0.8.1-1 libdbi-drivers.i386 0.8.1a-1 libgcc.i386 4.0.2-6 libgcj.i386 4.0.2-6 libgcj-devel.i386 4.0.2-6 libgcj-src.i386 4.0.2-6 libgfortran.i386 4.0.2-6 libgnat.i386 4.0.2-6 libmudflap.i386 4.0.2-6 libmudflap-devel.i386 4.0.2-6 libobjc.i386 4.0.2-6 libraw1394.i386 1.2.0-2.fc5 libraw1394-devel.i386 1.2.0-2.fc5 libsemanage.i386 1.3.53-2 libstdc++.i386 4.0.2-6 libstdc++-devel.i386 4.0.2-6 libuser.i386 0.54.2-1 libuser-devel.i386 0.54.2-1 logrotate.i386 3.7.3-1 mailman.i386 3:2.1.6-2 mod_auth_mysql.i386 1:2.9.0-2 mysql-server.i386 5.0.15-2 ntp.i386 4.2.0.a.20050816-10 nut-cgi.i386 2.0.2-4 nut-client.i386 2.0.2-4 openhpi.i386 2.2.1-1 openhpi-devel.i386 2.2.1-1 openldap-servers.i386 2.3.11-2 openssh-server.i386 4.2p1-6 oprofile.i386 0.9.1-3 oprofile-devel.i386 0.9.1-3 pam_krb5.i386 2.2.0-2 perl.i386 3:5.8.7-0.7.fc5 perl-suidperl.i386 3:5.8.7-0.7.fc5 policycoreutils.i386 1.27.27-3 postfix.i386 2:2.2.5-2.1 postfix-pflogsumm.i386 2:2.2.5-2.1 postgresql.i386 8.1.0-4 postgresql-contrib.i386 8.1.0-4 postgresql-devel.i386 8.1.0-4 postgresql-docs.i386 8.1.0-4 postgresql-jdbc.i386 8.1.0-4 postgresql-libs.i386 8.1.0-4 postgresql-pl.i386 8.1.0-4 postgresql-python.i386 8.1.0-4 postgresql-server.i386 8.1.0-4 postgresql-tcl.i386 8.1.0-4 postgresql-test.i386 8.1.0-4 pyparted.i386 1.6.10-1 rpm.i386 4.4.2-7 sendmail.i386 8.13.5-2 squid.i386 7:2.5.STABLE12-1 tmpwatch.i386 2.9.5-1 udev.i386 075-1 xorg-x11-xfs.i386 6.8.2-62 yum.noarch 2.4.0-13
Created attachment 121042 [details] avc errors before logs rotated Only a few entries here.
Created attachment 121043 [details] avc errors in rotated log. I have no audit.log on my system. These entries are from cat /var/log/messages.1 |grep avc
On my system, the root cause of the failure is setexeccon. It fails on "root:staff_r:rpm_script_t," most likely because the role is wrong. For some reason logging in as root does not set the role as sysadm_r like it should - needs further investigation. Otherwise... patch attached, and sent to nsa-list to make this work in permissive mode.
Created attachment 121046 [details] libselinux.rpm_respect_mode.diff Patch to make rpm_execcon respect the enforcing mode. In permissive mode, all selinux-related failures should be non-fatal, and we should attempt execve anyway.
The failure to begin with is caused by invalid context for my user, which cascades and causes a ton of problems - if the current context is wrong, the one after su is not valid either. I think I need to reboot, and it will probably get fixed (hopefully).
I ran yum from a virtual terminal (initial login as root) when I encountered the error before. After running yum this morning, updates installed without scripting errors. The problem trying to install the kernel is no longer happening and the latest kernel installed without issues on this round. I am using permissive mode, so this error should not have happened. Your patch or a like one that prevents errors in permissive mode should be added to the policy regardless.