Unfortunately an update to the SELinux policy package in Fedora 20 (and therefore Korora 20) caused RPM scriptlets to fail when updating packages.
This bug only affects systems that have SELinux mode set to enforcing (which is the default) and were updated to version 3.12.1-116 of the selinux-policy package. If you have seen the following sort of error when updating packages, then this bug may affect you:
warning: %post(libkcompactdisc-4.12.1-1.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package libkcompactdisc-4.12.1-1.fc20.x86_64
Below are the commands to resolve this issue (which has been fixed in an updated 3.12.1-117 version of selinux-policy).
sudo setenforce 0
sudo yum clean expire-cache
sudo yum update selinux-policy\*
sudo setenforce 1
The first command disables SELinux enforcement for the current session and the subsequent commands expire the yum cache and install the SELinux policy update which fixes this issue. The last command re-enables SELinux enforcement.
If you previously installed any packages which failed with scriptlet errors like above, you can reinstall them using the following command:
sudo yum reinstall
You can find out what packages were installed after the broken update using a command like this:
sudo sed '1,/selinux-policy-3.12.1-116/d' /var/log/yum.log
If you require any assistance please don’t hesitate to ask for help using Engage or jump onto the #korora channel in IRC freenode.net servers.
I have written a new article to follow up my previous (admittedly strongly worded) article on Ubuntu, with the two suggestions posted on my blog recently. I have no delusions that it will make any difference what-so-ever, but hopefully it’ll get people thinking about the issue anyway..
So on another machine (my Dad’s to be exact) after an upgrade to Karmic, both sound and printing were broken.
I fixed the printing issue last night, which was truly strange. The original printer was still there (as I would expect) and could be seen in the GNOME print manager. The problem was that it just wouldn’t print at all. Taking a closer look, for some reason the driver had been reset to “Alps MD-1000” even though it’s a Samsung.
Changing the driver to anything else and saving the changes did not actually change the driver – it went straight back to “Alps MD-1000.” Adding a new printer resulted in the same problem.
The fix was to log into the CUPS server directly (http://localhost:631) and from here I was able to select the right driver – and it stuck. It could now print correctly.
Going back to the GNOME print manager still shows the driver as being the “Alps MD-1000” which is just wrong.
So I’m not sure why GNOME print manager is broken, but if I configure the printer directly with CUPS it works.
This morning I turned on my openSUSE work machine and was greeted (as I often am) with a message to update the system.
Today’s message was special however, and perhaps one for The Daily WTF.
I wonder whether “Do not warn me again” means
Don’t tell me when there’s a non-existent update again
Still, it seemed pretty important so I did it straight away!
It’s good to know that I’m protected from security threats so real, they cannot be named 🙂
P.S. If you’re wondering what awesome icon set I’m using, it’s Oxy-GNOME.