Bug 1302558

Summary:	groupadd cannot load libselinux.so in %post script
Product:	Red Hat Enterprise Linux 5	Reporter:	Miroslav Suchý <msuchy>
Component:	libutempter	Assignee:	Miroslav Lichvar <mlichvar>
Status:	CLOSED WONTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	5.11	CC:	davejohansen, ovasik, packaging-team-maint, peter, pmatilai, tmraz
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-17 11:11:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.