Bug 1054350 (scriptlet) - rpm scriptlets are exiting with status 127
Summary: rpm scriptlets are exiting with status 127
Keywords:
Status: CLOSED ERRATA
Alias: scriptlet
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 20
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1053529 1053985 1054306 1054355 1054402 1054430 1054454 1054495 1054508 1054531 1054551 1054698 1054729 1054851 1054864 1054877 1054932 1054966 1054996 1054999 1055006 1055017 1055035 1055043 1055055 1055065 1055075 1055078 1055096 1055130 1055133 1055136 1055358 1055445 1055701 1055873 1056519 1057228 1064507 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-16 16:49 UTC by Dan Mossor [danofsatx]
Modified: 2014-05-28 14:48 UTC (History)
66 users (show)

Fixed In Version: selinux-policy-3.12.1-117.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-28 14:48:43 UTC


Attachments (Terms of Use)

Description Dan Mossor [danofsatx] 2014-01-16 16:49:17 UTC
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.

Comment 1 Will Woods 2014-01-16 16:57:57 UTC
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@redhat.com> 3.12.1-117
  - Add back rpm_run for unconfined_t

Does the problem go away if you install that package?

Comment 2 Dan Mossor [danofsatx] 2014-01-16 17:23:20 UTC
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

Comment 3 Will Woods 2014-01-16 17:24:57 UTC
Yeah, you need to install both packages. Hence "selinux-policy-{targeted-}3.12.1-117".

Try `yum --enablerepo=updates-testing update selinux-policy*`.

Comment 4 Dan Mossor [danofsatx] 2014-01-16 17:31:13 UTC
Targeted policy won't install. Yum output:

http://paste.fedoraproject.org/69028/93243138/


rpm -Uvvh output:

http://paste.fedoraproject.org/69030/98934541/

Comment 5 Dan Mossor [danofsatx] 2014-01-16 17:42:34 UTC
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.

Comment 6 Rex Dieter 2014-01-16 17:49:03 UTC
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

Comment 7 Josh Boyer 2014-01-16 19:44:18 UTC
*** Bug 1053985 has been marked as a duplicate of this bug. ***

Comment 8 Daniel Walsh 2014-01-16 21:50:13 UTC
*** Bug 1053529 has been marked as a duplicate of this bug. ***

Comment 9 Siddhesh Poyarekar 2014-01-17 04:01:14 UTC
*** Bug 1054355 has been marked as a duplicate of this bug. ***

Comment 10 Panu Matilainen 2014-01-17 05:49:29 UTC
*** Bug 1054430 has been marked as a duplicate of this bug. ***

Comment 11 Panu Matilainen 2014-01-17 05:52:54 UTC
*** Bug 1054531 has been marked as a duplicate of this bug. ***

Comment 12 Panu Matilainen 2014-01-17 05:55:19 UTC
*** Bug 1054402 has been marked as a duplicate of this bug. ***

Comment 13 Miroslav Grepl 2014-01-17 08:30:47 UTC
Yes, unfortunately

setenforce 0
yum --enablerepo=updates-testing update selinux-policy-targeted
setenforce 1

is needed to make an update working again. 

I apologize.

Comment 14 Panu Matilainen 2014-01-17 11:05:05 UTC
*** Bug 1054729 has been marked as a duplicate of this bug. ***

Comment 15 Kevin Kofler 2014-01-17 15:10:21 UTC
(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.

Comment 16 Kevin Kofler 2014-01-17 15:10:58 UTC
(I mean: re comment #6 and comment #13)

Comment 17 Miroslav Grepl 2014-01-17 15:29:57 UTC
*** Bug 1054851 has been marked as a duplicate of this bug. ***

Comment 18 Michael Schwendt 2014-01-17 19:25:08 UTC
*** Bug 1054932 has been marked as a duplicate of this bug. ***

Comment 19 Michael Schwendt 2014-01-17 22:23:48 UTC
*** Bug 1054698 has been marked as a duplicate of this bug. ***

Comment 20 Michael Schwendt 2014-01-17 22:24:24 UTC
*** Bug 1054454 has been marked as a duplicate of this bug. ***

Comment 21 Michael Schwendt 2014-01-17 22:24:38 UTC
*** Bug 1054551 has been marked as a duplicate of this bug. ***

Comment 22 Michael Schwendt 2014-01-17 22:28:33 UTC
*** Bug 1054966 has been marked as a duplicate of this bug. ***

Comment 23 Michael Schwendt 2014-01-17 22:28:35 UTC
*** Bug 1054996 has been marked as a duplicate of this bug. ***

Comment 24 Michael Schwendt 2014-01-17 22:29:32 UTC
*** Bug 1054306 has been marked as a duplicate of this bug. ***

Comment 25 John Ellson 2014-01-17 22:46:54 UTC
*** Bug 1054877 has been marked as a duplicate of this bug. ***

Comment 26 Cristian Ciupitu 2014-01-17 22:58:15 UTC
*** Bug 1054864 has been marked as a duplicate of this bug. ***

Comment 27 Michael Schwendt 2014-01-17 23:07:00 UTC
*** Bug 1055006 has been marked as a duplicate of this bug. ***

Comment 28 Panu Matilainen 2014-01-18 07:39:28 UTC
*** Bug 1055017 has been marked as a duplicate of this bug. ***

Comment 29 leigh scott 2014-01-18 08:34:03 UTC
*** Bug 1054495 has been marked as a duplicate of this bug. ***

Comment 30 leigh scott 2014-01-18 09:24:59 UTC
(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!

Comment 31 leigh scott 2014-01-18 10:22:41 UTC
*** Bug 1054508 has been marked as a duplicate of this bug. ***

Comment 32 leigh scott 2014-01-18 12:09:07 UTC
*** Bug 1055055 has been marked as a duplicate of this bug. ***

Comment 33 Davide Repetto 2014-01-18 18:44:34 UTC
*** Bug 1055075 has been marked as a duplicate of this bug. ***

Comment 34 Jim Haynes 2014-01-18 20:02:25 UTC
 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.

Comment 35 Michael Schwendt 2014-01-18 20:12:55 UTC
*** Bug 1055043 has been marked as a duplicate of this bug. ***

Comment 36 Rahul Sundaram 2014-01-19 06:11:23 UTC
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

Comment 37 Michael Schwendt 2014-01-19 08:31:36 UTC
*** Bug 1055136 has been marked as a duplicate of this bug. ***

Comment 38 Michael Schwendt 2014-01-19 08:31:37 UTC
*** Bug 1055130 has been marked as a duplicate of this bug. ***

Comment 39 Michael Schwendt 2014-01-19 08:31:39 UTC
*** Bug 1055096 has been marked as a duplicate of this bug. ***

Comment 40 Michael Schwendt 2014-01-19 08:31:41 UTC
*** Bug 1055035 has been marked as a duplicate of this bug. ***

Comment 41 Miroslav Grepl 2014-01-19 20:47:45 UTC
(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.

Comment 42 Rahul Sundaram 2014-01-19 21:25:39 UTC
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

Comment 43 Panu Matilainen 2014-01-20 06:53:33 UTC
*** Bug 1055358 has been marked as a duplicate of this bug. ***

Comment 44 Jan Zeleny 2014-01-20 09:16:50 UTC
*** Bug 1055133 has been marked as a duplicate of this bug. ***

Comment 45 Panu Matilainen 2014-01-20 09:56:26 UTC
*** Bug 1055445 has been marked as a duplicate of this bug. ***

Comment 46 Peter H. Jones 2014-01-20 16:26:16 UTC
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.)
"

Comment 47 Rahul Sundaram 2014-01-20 18:52:19 UTC
*** Bug 1054999 has been marked as a duplicate of this bug. ***

Comment 48 Michael Schwendt 2014-01-20 23:01:11 UTC
*** Bug 1055701 has been marked as a duplicate of this bug. ***

Comment 49 Michael Schwendt 2014-01-20 23:17:12 UTC
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.]

Comment 50 Panu Matilainen 2014-01-21 07:06:29 UTC
*** Bug 1055873 has been marked as a duplicate of this bug. ***

Comment 51 Mircea Sava 2014-01-21 07:22:53 UTC
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.

Comment 52 Peter H. Jones 2014-01-21 13:24:40 UTC
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.

Comment 53 Henrik Johansson 2014-01-21 19:28:54 UTC
(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

Comment 54 fujiwara 2014-01-22 02:39:14 UTC
*** Bug 1055065 has been marked as a duplicate of this bug. ***

Comment 55 Kevin Kofler 2014-01-22 11:33:25 UTC
*** Bug 1056519 has been marked as a duplicate of this bug. ***

Comment 56 Jan Zeleny 2014-01-23 07:50:03 UTC
*** Bug 1055078 has been marked as a duplicate of this bug. ***

Comment 57 Michael Schwendt 2014-01-23 20:16:44 UTC
*** Bug 1057228 has been marked as a duplicate of this bug. ***

Comment 58 Timothy St. Clair 2014-01-27 14:52:43 UTC
Another reference point: https://bugzilla.redhat.com/show_bug.cgi?id=1056187

Comment 59 Grzegorz Witkowski 2014-01-29 23:30:05 UTC
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.

Comment 60 Jan Zeleny 2014-02-13 08:37:43 UTC
*** Bug 1064507 has been marked as a duplicate of this bug. ***

Comment 61 Zbigniew Jędrzejewski-Szmek 2014-05-28 14:48:43 UTC
Closing, as the update is in stable.


Note You need to log in before you can comment on or make changes to this bug.