Reinstalled a fresh copy of Fedora 20 yesterday, and went through the update process before I installed KDE 4.12 from the kde-unstable repo. During that install, I saw a lot of scriplet failures, exit status 127 scrolling across the screen. I was in run level 3 at that point, so had no real way of grabbing that output. A mail surfaced on the Fedora-test mailing list ( https://lists.fedoraproject.org/pipermail/test/2014-January/120090.html ) that eventually led to the same problems I was having, and in discussions on IRC it is becoming a widespread problem. Some troubleshooting from Rex Dieter revealed that the packages can be installed manually without any errors, but when installed via rpm the error code is being produced. To my untrained eye, it appears that the rpm scriplet is launching a process and waiting for the pid to be returned, and either the process isn't being started or the pid isn't being passed back to the scriptlet, producing the exit status 127. An example, obtained with rpm -Uvvh kde-connect.rpm: D: %post(kde-connect-0.4.2-1.fc20.x86_64): scriptlet start D: %post(kde-connect-0.4.2-1.fc20.x86_64): execv(/sbin/ldconfig) pid 4414 D: %post(kde-connect-0.4.2-1.fc20.x86_64): waitpid(4414) rc 4414 status 7f00 warning: %post(kde-connect-0.4.2-1.fc20.x86_64) scriptlet failed, exit status 127 This is the output of my yum update this morning: http://paste.fedoraproject.org/68957/89881516/ Some updates installed fine, most produced the same error. I am still trying to track down a common thread between all of them besides the execv/waitpid process - but it is definitely in the rpm process, not yum or dnf as originally suspected.
On my systems this turned out to be a SELinux problem; `setenforce 0` will temporarily suppress the problems. It might be fixed by updating to selinux-policy-{targeted-}3.12.1-117 (from updates-testing). Note the changelog: * Wed Jan 15 2014 Miroslav Grepl <mgrepl> 3.12.1-117 - Add back rpm_run for unconfined_t Does the problem go away if you install that package?
Can't install the package. yum output: [root@localhost Downloads]# yum install ./selinux-policy-3.12.1-117.fc20.noarch.rpm Loaded plugins: langpacks, refresh-packagekit Examining ./selinux-policy-3.12.1-117.fc20.noarch.rpm: selinux-policy-3.12.1-117.fc20.noarch Marking ./selinux-policy-3.12.1-117.fc20.noarch.rpm as an update to selinux-policy-3.12.1-116.fc20.noarch Resolving Dependencies --> Running transaction check ---> Package selinux-policy.noarch 0:3.12.1-116.fc20 will be updated --> Processing Dependency: selinux-policy = 3.12.1-116.fc20 for package: selinux-policy-targeted-3.12.1-116.fc20.noarch --> Processing Dependency: selinux-policy = 3.12.1-116.fc20 for package: selinux-policy-targeted-3.12.1-116.fc20.noarch ---> Package selinux-policy.noarch 0:3.12.1-117.fc20 will be an update --> Finished Dependency Resolution Error: Package: selinux-policy-targeted-3.12.1-116.fc20.noarch (@updates-testing) Requires: selinux-policy = 3.12.1-116.fc20 Removing: selinux-policy-3.12.1-116.fc20.noarch (@updates-testing) selinux-policy = 3.12.1-116.fc20 Updated By: selinux-policy-3.12.1-117.fc20.noarch (/selinux-policy-3.12.1-117.fc20.noarch) selinux-policy = 3.12.1-117.fc20 Available: selinux-policy-3.12.1-106.fc20.noarch (fedora) selinux-policy = 3.12.1-106.fc20 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@localhost Downloads]# rpm output (snipped for brevity): file /usr/lib/rpm/macros.d/macros.selinux-policy from install of selinux-policy-3.12.1-117.fc20.noarch conflicts with file from package selinux-policy-3.12.1-116.fc20.noarch
Yeah, you need to install both packages. Hence "selinux-policy-{targeted-}3.12.1-117". Try `yum --enablerepo=updates-testing update selinux-policy*`.
Targeted policy won't install. Yum output: http://paste.fedoraproject.org/69028/93243138/ rpm -Uvvh output: http://paste.fedoraproject.org/69030/98934541/
Scratch comment 4 - I forgot to set selinux to permissive mode. Once permissive mode was enabled, I was able to install selinux-policy-targeted-3.12.1-117. I then set selinux back to enforcing, and tried my test rpm again, and it proceeded with no errors. On another note, yum doesn't see the selinux-policy*3.12.1-117 yet - I had to manually download them from the updates repo and install from local rpms.
Reassigning, rumors are confirmed, this should help: https://admin.fedoraproject.org/updates/FEDORA-2014-0870/selinux-policy-3.12.1-117.fc20 Though, getting this installed on boxes suffering from this may be tricky, may require something like: setenforce 0 yum --enablerepo=updates-testing update selinux-policy setenforce 1
*** Bug 1053985 has been marked as a duplicate of this bug. ***
*** Bug 1053529 has been marked as a duplicate of this bug. ***
*** Bug 1054355 has been marked as a duplicate of this bug. ***
*** Bug 1054430 has been marked as a duplicate of this bug. ***
*** Bug 1054531 has been marked as a duplicate of this bug. ***
*** Bug 1054402 has been marked as a duplicate of this bug. ***
Yes, unfortunately setenforce 0 yum --enablerepo=updates-testing update selinux-policy-targeted setenforce 1 is needed to make an update working again. I apologize.
*** Bug 1054729 has been marked as a duplicate of this bug. ***
(re comment #11 and comment #13) That, or just disabling SELinux permanently, as every Fedora user should do anyway. This bug just shows yet again that SELinux enforcing is a horrible default for Fedora.
(I mean: re comment #6 and comment #13)
*** Bug 1054851 has been marked as a duplicate of this bug. ***
*** Bug 1054932 has been marked as a duplicate of this bug. ***
*** Bug 1054698 has been marked as a duplicate of this bug. ***
*** Bug 1054454 has been marked as a duplicate of this bug. ***
*** Bug 1054551 has been marked as a duplicate of this bug. ***
*** Bug 1054966 has been marked as a duplicate of this bug. ***
*** Bug 1054996 has been marked as a duplicate of this bug. ***
*** Bug 1054306 has been marked as a duplicate of this bug. ***
*** Bug 1054877 has been marked as a duplicate of this bug. ***
*** Bug 1054864 has been marked as a duplicate of this bug. ***
*** Bug 1055006 has been marked as a duplicate of this bug. ***
*** Bug 1055017 has been marked as a duplicate of this bug. ***
*** Bug 1054495 has been marked as a duplicate of this bug. ***
(In reply to Miroslav Grepl from comment #13) > Yes, unfortunately > > setenforce 0 > yum --enablerepo=updates-testing update selinux-policy-targeted > setenforce 1 > > is needed to make an update working again. > > I apologize. As updates wont work again without manual intervention shouldn't an announcement be posted to the main web page to inform the users!
*** Bug 1054508 has been marked as a duplicate of this bug. ***
*** Bug 1055055 has been marked as a duplicate of this bug. ***
*** Bug 1055075 has been marked as a duplicate of this bug. ***
Quote As updates wont work again without manual intervention shouldn't an announcement be posted to the main web page to inform the users! Unquote Yes, and what is this "main web page"? If I had not filed a bug report I would not have learned of this work-around.
*** Bug 1055043 has been marked as a duplicate of this bug. ***
This issue and resolution is documented now at https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriptlets_fail_during_updates I have also sent out an announcement to the Fedora announce list but it appears struck in the moderation queue for now. Hope that helps
*** Bug 1055136 has been marked as a duplicate of this bug. ***
*** Bug 1055130 has been marked as a duplicate of this bug. ***
*** Bug 1055096 has been marked as a duplicate of this bug. ***
*** Bug 1055035 has been marked as a duplicate of this bug. ***
(In reply to Rahul Sundaram from comment #36) > This issue and resolution is documented now at > > https://fedoraproject.org/wiki/ > Common_F20_bugs#RPM_scriptlets_fail_during_updates > > I have also sent out an announcement to the Fedora announce list but it > appears struck in the moderation queue for now. Hope that helps Thank you.
You are welcome. I have also filed a ticket with FESCo with a proposal to avoid similar issues in the future. If you or anyone else affected including QA folks wants to chime in with your own thoughts, feel free to do so https://fedorahosted.org/fesco/ticket/1223
*** Bug 1055358 has been marked as a duplicate of this bug. ***
*** Bug 1055133 has been marked as a duplicate of this bug. ***
*** Bug 1055445 has been marked as a duplicate of this bug. ***
Got this this morning, even though I had already installed selinux-policy-3.12.1-117.fc20.noarch. I got around the bug by updating packages a few at a time. "(Positioned myself on my local directory conaining rpm's) 503 yum --security check-update (Then did yum --assumeno update, and edited the output to create command 509) 507 yum list kernel 508 yum remove kernel (to avoid possible running out of space on /boot) 509 yum install kernel-3.12.8-300.fc20.x86_64.rpm kernel-devel-3.12.8-300.fc20.x86_64.rpm NetworkManager-0.9.9.0-25.git20131003.fc20.x86_64.rpm NetworkManager-glib-0.9.9.0-25.git20131003.fc20.x86_64.rpm audit-2.3.3-1.fc20.x86_64.rpm audit-libs-2.3.3-1.fc20.x86_64.rpm audit-libs-python-2.3.3-1.fc20.x86_64.rpm initscripts-9.51-1.fc20.x86_64.rpm java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.rpm java-1.7.0-openjdk-headless-1.7.0.60-2.4.4.1.fc20.x86_64.rpm kernel-headers-3.12.8-300.fc20.x86_64.rpm nfs-utils-1.2.9-2.1.fc20.x86_64.rpm selinux-policy-targeted-3.12.1-117.fc20.noarch.rpm tcpdump-4.5.1-1.fc20.x86_64.rpm 510 setenforce 0 # Per bug 1054350 511 yum clean expire-cache # Per bug 1054350 512 yum update selinux-policy # Per bug 1054350, did not update 513 yum list selinux-policy (Found I already had 117) 517 yum reinstall selinux-policy-3.12.1-117.fc20.noarch.rpm (failed, I think) 519 yum install kernel-3.12.8-300.fc20.x86_64.rpm kernel-devel-3.12.8-300.fc20.x86_64.rpm NetworkManager-0.9.9.0-25.git20131003.fc20.x86_64.rpm NetworkManager-glib-0.9.9.0-25.git20131003.fc20.x86_64.rpm audit-2.3.3-1.fc20.x86_64.rpm audit-libs-2.3.3-1.fc20.x86_64.rpm audit-libs-python-2.3.3-1.fc20.x86_64.rpm initscripts-9.51-1.fc20.x86_64.rpm java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.rpm java-1.7.0-openjdk-headless-1.7.0.60-2.4.4.1.fc20.x86_64.rpm kernel-headers-3.12.8-300.fc20.x86_64.rpm nfs-utils-1.2.9-2.1.fc20.x86_64.rpm selinux-policy-targeted-3.12.1-117.fc20.noarch.rpm tcpdump-4.5.1-1.fc20.x86_64.rpm (failed) 520 yum install kernel-3.12.8-300.fc20.x86_64.rpm kernel-devel-3.12.8-300.fc20.x86_64.rpm kernel-headers-3.12.8-300.fc20.x86_64.rpm (Succeeded) 522 yum install NetworkManager-0.9.9.0-25.git20131003.fc20.x86_64.rpm NetworkManager-glib-0.9.9.0-25.git20131003.fc20.x86_64.rpm audit-2.3.3-1.fc20.x86_64.rpm audit-libs-2.3.3-1.fc20.x86_64.rpm audit-libs-python-2.3.3-1.fc20.x86_64.rpm initscripts-9.51-1.fc20.x86_64.rpm java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.rpm java-1.7.0-openjdk-headless-1.7.0.60-2.4.4.1.fc20.x86_64.rpm nfs-utils-1.2.9-2.1.fc20.x86_64.rpm selinux-policy-targeted-3.12.1-117.fc20.noarch.rpm tcpdump-4.5.1-1.fc20.x86_64.rpm (Failed) 523 yum install initscripts-9.51-1.fc20.x86_64.rpm java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.rpm java-1.7.0-openjdk-headless-1.7.0.60-2.4.4.1.fc20.x86_64.rpm nfs-utils-1.2.9-2.1.fc20.x86_64.rpm selinux-policy-targeted-3.12.1-117.fc20.noarch.rpm tcpdump-4.5.1-1.fc20.x86_64.rpm (Succeeded) 525 yum check-update (Nothing more to update. Bug ocurrence is resolved.) "
*** Bug 1054999 has been marked as a duplicate of this bug. ***
*** Bug 1055701 has been marked as a duplicate of this bug. ***
Peter H. Jones, the better fix in your case would have been to run "yum update selinux-policy\*" (or "yum update selinux-policy-targeted") in permissive mode. The instructions in the Wiki have been updated already to cover such a failure scenario. # setenforce 0 # yum clean expire-cache # yum update selinux-policy\* # setenforce 1 [What you've encountered is that due to SELinux enforcing mode your normal updates have only managed to update to selinux-policy-3.12.1-117.fc20 but not selinux-policy-targeted-3.12.1-117.fc20 (the important one!), because that one had failed to update. Therefore a "yum update selinux-policy" could not fix it, since package selinux-policy was up-to-date but selinux-policy-targeted wasn't.]
*** Bug 1055873 has been marked as a duplicate of this bug. ***
By temporarily disabling targeted mode and updating to selinux-policy-targeted-3.12.1-117.fc20 the issue is now fixed, however the kernel update done just before that is not available -- initramfs file specific to the new version is missing in /boot and therefore GRUB can't list it.
Thanks for comment 49. I now have: "# yum list selinux-\* Loaded plugins: langpacks, refresh-packagekit Installed Packages selinux-policy.noarch 3.12.1-117.fc20 @/selinux-policy-3.12.1-117.fc20.noarch selinux-policy-targeted.noarch 3.12.1-117.fc20 @/selinux-policy-targeted-3.12.1-117.fc20.noarch Available Packages selinux-policy-devel.noarch 3.12.1-117.fc20 updates selinux-policy-doc.noarch 3.12.1-117.fc20 updates selinux-policy-minimum.noarch 3.12.1-117.fc20 updates selinux-policy-mls.noarch 3.12.1-117.fc20 updates selinux-policy-sandbox.noarch 3.12.1-117.fc20 updates" After reading comment 51, when I updated this morning, I also found I was still running kernel-3.12.7-300.fc20.x86_64, and not kernel-3.12.8-300.fc20.x86_64, which was shown as installed, but was not visible in grub. I removed and reinstalled the latter, and it is now working.
(In reply to Peter H. Jones from comment #52) > After reading comment 51, when I updated this morning, I also found I was > still running kernel-3.12.7-300.fc20.x86_64, and not > kernel-3.12.8-300.fc20.x86_64, which was shown as installed, but was not > visible in grub. I removed and reinstalled the latter, and it is now working. I had four packages plus the the kernel in a halfway-update: selinux-policy-targeted-3.12.1-117.fc20.noarch initscripts-9.51-1.fc20.x86_64 nfs-utils-1.2.9-2.1.fc20.x86_64 tcpdump-4.5.1-1.fc20.x86_64 kernel-3.12.8-300.fc20.x86_64 My commands from history: 1009 setenforce 0 1010 yum clean expire-cache 1011 yum update selinux-policy\* 1012 setenforce 1 1013 yum update initscripts 1014 yum update nfs-utils # Installation of remaining updates (tcpdump and new) 1015 yum update # Didn't update or reinstall the kernel 1017 yum reinstall kernel # Didn't update or reinstall the kernel 1018 yum remove kernel-3.12.8-300.fc20.x86_64 1019 yum update # Kernel updated # New kernel in use after reboot
*** Bug 1055065 has been marked as a duplicate of this bug. ***
*** Bug 1056519 has been marked as a duplicate of this bug. ***
*** Bug 1055078 has been marked as a duplicate of this bug. ***
*** Bug 1057228 has been marked as a duplicate of this bug. ***
Another reference point: https://bugzilla.redhat.com/show_bug.cgi?id=1056187
I had no problem on my laptop, but on desktop yes. Both updated from F19 via fedup originally. Several packages were failing the same way. setenforce 0 fixed the issue with all packages. Nothing else was needed. I wonder why desktop suffered while laptop did not? Interesting.
*** Bug 1064507 has been marked as a duplicate of this bug. ***
Closing, as the update is in stable.