Red Hat Bugzilla – Bug 160585
Upgrade from FC3 leaves old version of glibc
Last modified: 2014-03-25 20:52:20 EDT
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.
This has nothing to do with glibc itself. It might be the package management.
Reassigned to rpm.
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.
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.
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,
Created attachment 116277 [details]
Created attachment 116278 [details]
Created attachment 116279 [details]
Created attachment 116280 [details]
Created attachment 116281 [details]
Created attachment 116282 [details]
Created attachment 116283 [details]
Created attachment 116284 [details]
Thanks - this indicates the reason why the old glibc was not removed (failing
trigger), changing component to anaconda and will try reproduce.
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 || :
/sbin/sln ld-linux.so.2 /lib/ld-lsb.so || :
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.
(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?
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.
*** Bug 161993 has been marked as a duplicate of this bug. ***
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.
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:22.214.171.124.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
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
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:126.96.36.199.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
[root@dhcp-87 yum.repos.d]# rpm -qa | grep redhat-lsb
[root@dhcp-87 yum.repos.d]# rpm -qa | grep glibc
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 ?
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 ?
Thank you for the bug report. Closing bug as per comment #25.