Red Hat Bugzilla – Bug 173094
Random rpm script failures (exit status 255)
Last modified: 2007-11-30 17:11:17 EST
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.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install various rpms that use scripts
2. Scripts fail with status 255
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,
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.
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
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.
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
Created attachment 121046 [details]
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
I ran yum from a virtual terminal (initial login as root) when I encountered the
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