Claude Jones wrote:
I use smart, and have had no problems for months, but this evening I got the
following error messages -
Output from libwmf-0.2.8.4-5.2@i386:
error: %post(libwmf-0.2.8.4-5.2.i386) scriptlet failed, exit status 255
Output from selinux-policy-2.3.2-1.fc5@noarch:
error: %post(selinux-policy-2.3.2-1.fc5.noarch) scriptlet failed, exit status
255
Output from libsane-hpaio-1.6.6a-1.1@i386:
error: %post(libsane-hpaio-1.6.6a-1.1.i386) scriptlet failed, exit status 255
Output from sendmail-8.13.7-2.fc5.1@i386:
error: %pre(sendmail-8.13.7-2.fc5.1.i386) scriptlet failed, exit status 255
error: install: %pre scriptlet failed (2), skipping sendmail-8.13.7-2.fc5.1
Output from system-config-kickstart-2.6.6-5@noarch:
error: %post(system-config-kickstart-2.6.6-5.noarch) scriptlet failed, exit
status 255
Output from coreutils-5.97-1.1@i386:
error: %pre(coreutils-5.97-1.1.i386) scriptlet failed, exit status 255
error: install: %pre scriptlet failed (2), skipping coreutils-5.97-1.1
Output from hplip-1.6.6a-1.1@i386:
error: %post(hplip-1.6.6a-1.1.i386) scriptlet failed, exit status 255
I've never seen these "scriptlet failed" errors - anyone else getting these,
or know what they're about?
This error sounds like a problem with SELinux or a problem with the
labeling of your filesystem because of SELinux not having the proper
security rights to install itself.
Try running setenforce 0 in a root terminal before attempting to upgrade
your system.
For the %pre scriptlet errors, I do not think that there will be too
much of a problem since the installation of the new rpm never took
place. You should still have the older version on your system.
When you have a %post scritlet error, you will have the latest rpm
installed and a database entry for the previous version.
In the past, I erased the database entry for the previous version and
took it that the rpm was installed with all needed elements. I thought
of another option that would probably work out better to ensure program
integrity. The thought is to remove the latest version database entry
and leave in the actually replaced version in the rpm database. Then
performing an update should complete all of the intended functions for
the %pre and %post scriptlets which would ensure users were added if
needed and file permissions were properly set. THe only thing that I am
unsure of is if rpm would bomb out because it was looking for files with
specific information such as library files with specific filenames which
changed. Just a thought!
The safest way to ensure the rpms are installed properly in my view is
to download the versions with the %pre and %post problems, turn off
selinux enforcing as mentioned earlier, then run rpm with the
--replacefiles --replacepkgs flags. I have run this option from the rpms
yum downloaded to the cache and changed to that particular derectoy and
ran rpm as described above. The results were that the multiple versions
in the rpm database were cleared and the programs seem to function
correctly now.
Jim
--
Some people live life in the fast lane. You're in oncoming traffic.
