Bug 1302558 - groupadd cannot load libselinux.so in %post script
Summary: groupadd cannot load libselinux.so in %post script
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libutempter
Version: 5.11
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-28 07:36 UTC by Miroslav Suchý
Modified: 2016-10-17 11:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-17 11:11:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Miroslav Suchý 2016-01-28 07:36:05 UTC
Description of problem:
When you try install system from scratch you have pretty high chance to hit this error:
  Installing : 2:shadow-utils-4.0.17-23.el5.x86_64                                                                    82/114 
/usr/sbin/groupadd: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
/usr/sbin/groupadd: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
  Installing : libutempter-1.1.4-4.el5.x86_64                                                                         83/114 
warning: group utmp does not exist - using root



Version-Release number of selected component (if applicable):
shadow-utils-4.0.17-23.el5.x86_64
libutempter-1.1.4-4.el5.x86_64

How reproducible:
very often

Steps to Reproduce:
1. Easiest way is to:
   mock -r epel-5-x86_64 --init
   on any system (can be even Fedora)

Actual results:
Notice that libutempter are installed *before* libselinux, therefore libselinux.so is not available during %post script.
Because there is no ordering, yum can sort it any way. And in past yum probably sort it in way that libselinux was installed before libutempter. But something else changes and libselinux is installed after libutempter and from yum POV it is fine, because all requires are satisfied.

This package is in @buildsys group so it need special handling, because you cound not expect base package to be installed when yours is installed.
We are hitting corner case here as you have correctly:
  Requires(pre): shadow-utils
in spec. But this is not enough and you need either add:
  Requires(pre): libselinux
or shadow-utils need to add to spec
  Requires(pre): libselinux
I'm not sure which solution is the best, but one of them needs to be done.



Expected results:
Requires(pre): libselinux

Additional info:

Comment 2 Tomas Mraz 2016-01-28 08:57:12 UTC
Hmm, this seems to me like a bug in rpm.

If something such as shadow-utils has 'Requires: libselinux' - it does not actually have this exact requires but has the autogenerated Requires for the library, but that should be equivalent - then if something else Requires(pre): shadow-utils, it should imply that the Requires: libselinux from above should be evaluated as Requires(pre): libselinux for the install of the package. If shadow util itself does not need the libselinux in pre/post scripts there is no point in having Requires(pre): libselinux directly in shadow-utils.

Comment 3 Miroslav Lichvar 2016-01-28 09:34:20 UTC
It looks like there is a dependency loop and rpm is forced to break it at a random point.

shadow-utils -> coreutils -> util-linux -> libutempter -> shadow-utils

In Fedora the dependency of coreutils on util-linux was removed some time ago. If it was removed in RHEL too, maybe it would fix the problem?

Comment 4 Miroslav Lichvar 2016-01-28 09:39:52 UTC
Also, it's not clear to me what RHEL version this is about. The bug is filed against RHEL7, but package versions indicate RHEL5, where we probably wouldn't be able to make any changes like that.

Comment 5 Miroslav Suchý 2016-01-28 10:10:44 UTC
This is against RHEL5.

Comment 6 Miroslav Lichvar 2016-09-08 07:41:24 UTC
Moving to the rpm component in case there is a possibility for improving the algorithm that breaks the dependency loop. Anyway, I'm not sure if this is a critical bug that would warrant a fix in RHEL5 at this point of its life.

Comment 7 Panu Matilainen 2016-10-17 11:05:01 UTC
In rpm >= 4.8.0 the ordering code was largely rewritten to keep packages with dependency loops close together during installation which helps, but that doesn't mean loops are no longer a problem. And its definitely not backportable to RHEL 5 anyway.

Switching compotent back to libutempter - if you want to fix it then you need to remove the loop, otherwise just close it. It's a bit late for fixes like this in RHEL 5 anyway.

Comment 8 Miroslav Lichvar 2016-10-17 11:11:31 UTC
Thanks, Panu. I'm closing this as it's too late for fixes like that in RHEL5.


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