Bug 181726 - Upgrade from RHEL3-U6 -> RHEL4-U3 leaves old version of glibc
Upgrade from RHEL3-U6 -> RHEL4-U3 leaves old version of glibc
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-lsb (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Lawrence Lim
:
Depends On: 160585
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-15 19:37 EST by Ben Levenson
Modified: 2014-03-25 20:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 14:47:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Levenson 2006-02-15 19:37:01 EST
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@redhat.com 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@mac.com 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@rogers.com 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@redhat.com 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@rogers.com on 2005-07-02 07:37 EST --
Created an attachment (id=116277)
/root/upgrade.log


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


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


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


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


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


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


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


-- Additional comment from pnasrat@redhat.com 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@mac.com 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@users.sourceforge.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@rogers.com 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@redhat.com on 2005-07-14 21:23 EST --
*** Bug 161993 has been marked as a duplicate of this bug. ***

-- Additional comment from llch@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2005-11-28 14:45 EST --
rawhide redhat-lsb spec still contains trigger.  Reassign to redhat-lsb.

-- Additional comment from llch@redhat.com on 2006-01-08 22:15 EST --
Thanks Paul, will merge the changes in RHEL updates to rawhide.
Comment 2 RHEL Product and Program Management 2007-10-19 14:47:21 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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