[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: xorg-x11 update may have broken my system



D. Hugh Redelmeier wrote:

| From: Ralf Corsepius <rc040203 freenet de>

| The %postun scriptlet contained in
| xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1.i386 definitely is broken:
| | # rpm -q xorg-x11-Mesa-libGLU
| xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1
| | | # rpm -q --scripts xorg-x11-Mesa-libGLU
| postinstall program: /sbin/ldconfig
| postuninstall scriptlet (using /sbin/ldconfig):
| | ##### xfs scripts ####################################################
| # Work around a bug in the XFree86-xfs postun script, which results in the
| # special xfs user account being inadvertently removed, causing xfs to run as
| # the root user, and also resulting in xfs not being activated by chkconfig,
| # This trigger executes right after the XFree86-xfs postun script, and ensures
| # that the xfs user exists, and that the xfs initscript is properly chkconfig
| # activated (#118145,118818)
| | => ldconfig tries to execute a shell script fragment.

Yes.

More evidence:

 # rpm -q --scripts xorg-x11-Mesa-libGLU-6.8.2-37.FC4.45
 postinstall scriptlet (using /bin/sh):
 /sbin/ldconfig
 postuninstall scriptlet (using /bin/sh):
 /sbin/ldconfig

 ##### xfs scripts ####################################################
 # Work around a bug in the XFree86-xfs postun script, which results in the
 # special xfs user account being inadvertently removed, causing xfs to run as
 # the root user, and also resulting in xfs not being activated by chkconfig,
 # This trigger executes right after the XFree86-xfs postun script, and ensures
 # that the xfs user exists, and that the xfs initscript is properly chkconfig
 # activated (#118145,118818)

In this (older) RPM, the scriptlet is run using /bin/sh, not /sbin/ldconfig.

Doing an strace on the attempted removal
 # strace -o 0 -f rpm -e --verbose xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1
You can see the exec of /sbin/ldconfig:
 execve("/sbin/ldconfig", ["/sbin/ldconfig", "/var/tmp/rpm-tmp.60280", "1"], [/* 27 vars */]) = 0

The first and second arguments to /sbin/ldconfig make no sense
according the the ldconfig(8) manpage.

BTW, apparently both versions of the RPM can coexist.  The files are
identical, except for one timestamp:
 # rpm --verify xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1
 .......T.   /usr/X11R6/lib/libGLU.so.1.3
 # rpm --verify xorg-x11-Mesa-libGLU-6.8.2-37.FC4.45

It looks to me by your results that the older package is intact and that rpm thinks that the only difference during verification is the particular LibGLU.so.1.3 version. In other words, The new package is not actually present on the system, the older package is installed on the system. Both versions are in the rpm database though. To make upgrading your system easier whenever X is fixed and a new release comes out, removing the db entry for the newer version might be needed.

Interesting information about the script breakage. This is surely a problem.

--
QOTD:
	If it's too loud, you're too old.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]