xorg-x11 update may have broken my system

Jim Cornette fc-cornette at insight.rr.com
Mon Sep 19 11:10:39 UTC 2005


D. Hugh Redelmeier wrote:

>| From: Ralf Corsepius <rc040203 at 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.




More information about the fedora-list mailing list