Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160585 - Upgrade from FC3 leaves old version of glibc
Summary: Upgrade from FC3 leaves old version of glibc
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-lsb
Version: 4
Hardware: i686
OS: Linux
medium
low
Target Milestone: ---
Assignee: Lawrence Lim
QA Contact:
URL:
Whiteboard:
: 161993 (view as bug list)
Depends On:
Blocks: 164768 181726
TreeView+ depends on / blocked
 
Reported: 2005-06-15 22:18 UTC by ChenLi Tien
Modified: 2014-03-26 00:52 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-04 20:14:41 UTC


Attachments (Terms of Use)
/root/upgrade.log (deleted)
2005-07-02 11:37 UTC, ChenLi Tien
no flags Details
/root/upgrade.log.syslog (deleted)
2005-07-02 11:38 UTC, ChenLi Tien
no flags Details
/var/log/rpmpkgs (deleted)
2005-07-02 11:39 UTC, ChenLi Tien
no flags Details
/var/log/rpmpkgs.1 (deleted)
2005-07-02 11:40 UTC, ChenLi Tien
no flags Details
/var/log/up2date.2 (deleted)
2005-07-02 11:41 UTC, ChenLi Tien
no flags Details
/var/log/rpmpkgs.3 (deleted)
2005-07-02 11:41 UTC, ChenLi Tien
no flags Details
/var/log/rpmpkgs.4 (deleted)
2005-07-02 11:42 UTC, ChenLi Tien
no flags Details
/var/log/rpmpkgs.2 (deleted)
2005-07-02 11:43 UTC, ChenLi Tien
no flags Details

Description ChenLi Tien 2005-06-15 22:18:52 UTC
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

Comment 1 Ulrich Drepper 2005-06-30 20:18:20 UTC
This has nothing to do with glibc itself.  It might be the package management. 
Reassigned to rpm.

Comment 2 Jeff Johnson 2005-07-01 09:58:10 UTC
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.

Comment 3 ChenLi Tien 2005-07-01 14:50:00 UTC
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.

Comment 4 Paul Nasrat 2005-07-01 16:47:53 UTC
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.

Comment 5 ChenLi Tien 2005-07-02 11:37:13 UTC
Created attachment 116277 [details]
/root/upgrade.log

Comment 6 ChenLi Tien 2005-07-02 11:38:28 UTC
Created attachment 116278 [details]
/root/upgrade.log.syslog

Comment 7 ChenLi Tien 2005-07-02 11:39:35 UTC
Created attachment 116279 [details]
/var/log/rpmpkgs

Comment 8 ChenLi Tien 2005-07-02 11:40:22 UTC
Created attachment 116280 [details]
/var/log/rpmpkgs.1

Comment 9 ChenLi Tien 2005-07-02 11:41:13 UTC
Created attachment 116281 [details]
/var/log/up2date.2

Comment 10 ChenLi Tien 2005-07-02 11:41:42 UTC
Created attachment 116282 [details]
/var/log/rpmpkgs.3

Comment 11 ChenLi Tien 2005-07-02 11:42:31 UTC
Created attachment 116283 [details]
/var/log/rpmpkgs.4

Comment 12 ChenLi Tien 2005-07-02 11:43:17 UTC
Created attachment 116284 [details]
/var/log/rpmpkgs.2

Comment 13 Paul Nasrat 2005-07-02 12:25:52 UTC
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


Comment 14 Jeff Johnson 2005-07-02 15:49:20 UTC
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.

Comment 15 Hubert Verstraete 2005-07-05 16:44:05 UTC
(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?

Comment 16 ChenLi Tien 2005-07-11 15:15:11 UTC
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

Comment 17 Leon Ho 2005-07-15 01:23:39 UTC
*** Bug 161993 has been marked as a duplicate of this bug. ***

Comment 19 Jakub Jelinek 2005-07-15 07:12:56 UTC
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.

Comment 20 Leon Ho 2005-07-20 04:08:43 UTC
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]#


Comment 24 Christian Iseli 2007-01-22 11:16:58 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 25 ChenLi Tien 2007-01-22 13:02:18 UTC
Update FC4 to FC6 days ago. There was nothing wrong this time. Thanks for your work.
I (In reply to comment #24)
> This report targets the FC3 or FC4 products, which have now been EOL'd.
> 
> Could you please check that it still applies to a current Fedora release, and
> either update the target product or close it ?
> 
> Thanks.

Comment 26 Peter van Egdom 2007-07-04 20:14:41 UTC
Thank you for the bug report. Closing bug as per comment #25.


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