Bug 181726

RHEL3-U6 -> RHEL4-U3 upgrades fail in the same way.
RHEL3-U6: redhat-lsb-1.3-3.1.EL3
triggerpostun scriptlet (using /bin/sh) -- glibc
  if [ -f /emul/ia32-linux/lib/ld-linux.so.2 ]; then
    /sbin/sln /emul/ia32-linux/lib/ld-linux.so.2 /lib/ld-lsb.so.1 || :
  else
    /sbin/sln ld-linux.so.2 /lib/ld-lsb.so.1 || :
  fi
---------------------
RHEL4-U6: redhat-lsb-3.0-8.EL 
triggerpostun scriptlet (using /bin/sh) -- glibc
if [ -x /usr/sbin/redhat_lsb_trigger.i386 ]; then
  /usr/sbin/redhat_lsb_trigger.i386
fi

I guess there is nothing we can do about this since the bug is in the *old*
package, but it is probably a good idea to have this issue recorded in Bugzilla
under the RHEL product family.

+++ This bug was initially created as a clone of Bug #160585 +++

Description of problem, bug, incorrect information, or enhancement request:


Version of release notes this bug refers to:

Fedora Core 4 final release

I updated FC4 from FC3, it works fine.
Later I download kernel-xenU-2.6.11-1.1369_FC4.i686.rpm and wanted to install,
it replied that my glibc < 2.3.5-1. I then checked my glibc version by "rpm -qa
| grep glic" and found I had 2 copies of it - one is the old glibc-2.3.5-0.fc3.1
and the other one is glibc-2.3.5-10. I removed the old glibc manually and now I
can install xen0. I think the installation program should remove it.

Sincerely,
ChenLi Tien

-- Additional comment from drepper on 2005-06-30 16:18 EST --
This has nothing to do with glibc itself.  It might be the package management. 
Reassigned to rpm.

-- Additional comment from n3npq on 2005-07-01 05:58 EST --
rpm (and tools that use rpmlib) does remove older versions if invoked with -U.

You have not described what "installation tool" was used, nor have you identified
how it was invoked.

My guess is that rpm -i was used to install glibc-2.3.5-10 rather than rpm -U.

-- Additional comment from cltien on 2005-07-01 10:50 EST --
The glibc is installed by FC4 DVD over FC3 system. This should be RPM's problem
-- it doesn't remove the old glibc package.

I think this won't happen on freshly installation.

-- Additional comment from pnasrat on 2005-07-01 12:47 EST --
Was this an upgrade using anaconda? If so please attach /root/upgrade.log
/var/log/anaconda.log /var/log/anaconda.syslog as seperate uncompressed
attachments.  Please also include the /var/log/rpmpkgs.? containing a reference
to the original glibc following upgrade.

If not please detail in full the steps you took to perform the upgrade - eg yum,
rpm, etc.

-- Additional comment from cltien on 2005-07-02 07:37 EST --
Created an attachment (id=116277)
/root/upgrade.log


-- Additional comment from cltien on 2005-07-02 07:38 EST --
Created an attachment (id=116278)
/root/upgrade.log.syslog


-- Additional comment from cltien on 2005-07-02 07:39 EST --
Created an attachment (id=116279)
/var/log/rpmpkgs


-- Additional comment from cltien on 2005-07-02 07:40 EST --
Created an attachment (id=116280)
/var/log/rpmpkgs.1


-- Additional comment from cltien on 2005-07-02 07:41 EST --
Created an attachment (id=116281)
/var/log/up2date.2


-- Additional comment from cltien on 2005-07-02 07:41 EST --
Created an attachment (id=116282)
/var/log/rpmpkgs.3


-- Additional comment from cltien on 2005-07-02 07:42 EST --
Created an attachment (id=116283)
/var/log/rpmpkgs.4


-- Additional comment from cltien on 2005-07-02 07:43 EST --
Created an attachment (id=116284)
/var/log/rpmpkgs.2


-- Additional comment from pnasrat on 2005-07-02 08:25 EST --
Thanks - this indicates the reason why the old glibc was not removed (failing
trigger), changing component to anaconda and will try reproduce.

Upgrading glibc-2.3.5-10.i686.
error: %trigger(redhat-lsb-1.3-4.i386) scriptlet failed, exit status 255

triggerpostun scriptlet (using /bin/sh) -- glibc
  if [ -f /emul/ia32-linux/lib/ld-linux.so.2 ]; then
    /sbin/sln /emul/ia32-linux/lib/ld-linux.so.2 /lib/ld-lsb.so || :
  else
    /sbin/sln ld-linux.so.2 /lib/ld-lsb.so || :
  fi


-- Additional comment from n3npq on 2005-07-02 11:49 EST --
This is a packaging problem.

One cannot expect a script that has a /bin/sh elf interpreter to function in a
%triggerpostun context
that is recreating a ld-linux.so.2 symliknk.

Bzzzt! Does not compute. Period.

-- Additional comment from hubs.net on 2005-07-05 12:44 EST --
(In reply to comment #0)
> I removed the old glibc manually

Did you run the command "rpm -e glibc-2.3.5-0.fc3.1" and it did not remove the
files associated with it?

-- Additional comment from cltien on 2005-07-11 11:15 EST --
Yes, the rpm -e command is what I did after I understood the old glibc not
removed by anaconda, this command did successfully so I didn't have problem
installing the kernel-xenU-2.6.11-1.1369_FC4.i686.rpm later.

Thaks for your effort and hope you got enough information now.

Sincerely,
ChenLi Tien

-- Additional comment from llch on 2005-07-14 21:23 EST --
*** Bug 161993 has been marked as a duplicate of this bug. ***

-- Additional comment from llch on 2005-07-14 21:27 EST --
Paul, is it a package itself fault or other issue related? 

Jakub, I see there are glibc upgrades for RHEL as well - will this bug affects RHEL?


-- Additional comment from jakub on 2005-07-15 03:12 EST --
If redhat-lsb has the same bug as in FC, then maybe yes.
For these kind of things glibc and libgcc are using tiny statically linked
binaries.  libgcc_post_upgrade.c in gcc*.src.rpm is probably better example,
both used to be massaged so that they aren't 500k+ statically linked binaries,
but that is now with the departure of linuxthreads temporarily disabled
for glibc_post_upgrade.c (just needs more work).  libgcc_post_upgrade.c is
simple enough that it doesn't need it.

-- Additional comment from llch on 2005-07-20 00:08 EST --
I had setup a FC3 environment and did a glibc update with yum. I couldn't see
any problem on that route.

Paul, what do you think on this situation?

--
Performing the following to resolve dependencies:
  Update: binutils.i386 0:2.15.94.0.2.2-2
  Update: cpp.i386 0:4.0.0-8
  Update: gcc.i386 0:4.0.0-8
  Update: gcc-c++.i386 0:4.0.0-8
  Update: gcc-java.i386 0:4.0.0-8
  Update: glibc-common.i386 0:2.3.5-10
  Update: glibc-devel.i386 0:2.3.5-10
  Update: glibc-headers.i386 0:2.3.5-10
  Update: libgcc.i386 0:4.0.0-8
  Update: libgcj.i386 0:4.0.0-8
  Update: libgcj-devel.i386 0:4.0.0-8
  Update: libstdc++.i386 0:4.0.0-8
  Update: libstdc++-devel.i386 0:4.0.0-8
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Updating: libgcc 100 % done 1/28
Updating: glibc-common 100 % done 2/28
Updating: glibc 100 % done 3/28
Stopping sshd:[  OK  ]
Starting sshd:[  OK  ]
Updating: libgcj 100 % done 4/28
Updating: libgcj-devel 100 % done 5/28
Updating: glibc-headers 100 % done 6/28
Updating: glibc-devel 100 % done 7/28
Updating: binutils 100 % done 8/28
Updating: libstdc++ 100 % done 9/28
Updating: libstdc++-devel 100 % done 10/28
Updating: cpp 100 % done 11/28
Updating: gcc 100 % done 12/28
Updating: gcc-c++ 100 % done 13/28
Updating: gcc-java 100 % done 14/28
Completing update for glibc  - 15/28
Completing update for glibc-devel  - 16/28
Completing update for glibc-common  - 17/28
Completing update for glibc-headers  - 18/28
Completing update for binutils  - 19/28
Completing update for gcc-c++  - 20/28
Completing update for gcc  - 21/28
Completing update for libstdc++-devel  - 22/28
Completing update for libstdc++  - 23/28
Completing update for libgcc  - 24/28
Completing update for gcc-java  - 25/28
Completing update for cpp  - 26/28
Completing update for libgcj  - 27/28
Completing update for libgcj-devel  - 28/28

Updated: glibc.i686 0:2.3.5-10
Dependency Updated: binutils.i386 0:2.15.94.0.2.2-2 cpp.i386 0:4.0.0-8 gcc.i386
0:4.0.0-8 gcc-c++.i386 0:4.0.0-8 gcc-java.i386 0:4.0.0-8 glibc-common.i386
0:2.3.5-10 glibc-devel.i386 0:2.3.5-10 glibc-headers.i386 0:2.3.5-10 libgcc.i386
0:4.0.0-8 libgcj.i386 0:4.0.0-8 libgcj-devel.i386 0:4.0.0-8 libstdc++.i386
0:4.0.0-8 libstdc++-devel.i386 0:4.0.0-8
Complete!
[root@dhcp-87 yum.repos.d]# rpm -qa | grep redhat-lsb
redhat-lsb-1.3-4
[root@dhcp-87 yum.repos.d]# rpm -qa | grep glibc
glibc-devel-2.3.5-10
glibc-kernheaders-2.4-9.1.87
glibc-common-2.3.5-10
glibc-headers-2.3.5-10
glibc-2.3.5-10
[root@dhcp-87 yum.repos.d]#


-- Additional comment from pnasrat on 2005-07-20 07:59 EST --
yum does different ordering to an anaconda update.  Please attempt to reproduce
using a FC4 DVD to upgrade.  Please start with the same package set as indicated
in the log files.

Triggerpostun should come last in scriptlet execution order so should be safe -
however as jbj said you are depending on the system being in a state to be able
to run a shell at this point, if you can get it to a reproducible state I'll be
able to assist in seeing what is occuring.

Jakub's suggestion of using a statically linked binary as the interpreter to
perform the change would ensure that hitting a window when we can't run /bin/sh
would be hit.



-- Additional comment from pnasrat on 2005-11-28 14:45 EST --
rawhide redhat-lsb spec still contains trigger.  Reassign to redhat-lsb.

-- Additional comment from llch on 2006-01-08 22:15 EST --
Thanks Paul, will merge the changes in RHEL updates to rawhide.