Bug 119122 - glibc rpm upgrade fails badly
glibc rpm upgrade fails badly
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2004-03-25 03:09 EST by Ville Herva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-27 18:17:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Log of the yum upgrade (22.41 KB, text/plain)
2004-03-25 03:10 EST, Ville Herva
no flags Details

  None (edit)
Description Ville Herva 2004-03-25 03:09:00 EST
Description of problem:

This is a longish story, and I'm not sure where I should report this 
bug... Anyway, 
I was upgrading my Fedora Core Development installation with yum 

  yum --exclude=xorg\* --exclude=anaconda --exclude=gdm 
--exclude=kdebase --exclude=kde\* --exclude=chkfontpath 
--exclude=XFree86\* --exclude=epiphany --exclude=gkrellm 
--exclude=rpmdb-fedora update

in preparation to move from XFree86 to x-org. At the time, I only had 
Fedora Devel base path in my yum.conf. yum downloaded the rpms 
slowly, but hell broke loose when rpm begun installing the first 
packages. Basically, glibc-common and 
glibc didn't install properly:

  glibc-common 100 % done 4/208 
  error: unpacking of archive failed on file 
/usr/lib/locale/zh_CN/LC_PAPER: cpio link exists
  warning: /etc/ld.so.conf created as /etc/ld.so.conf.rpmnew

  glibc 100 % done 5/208 
  error: unpacking of archive failed on file /lib/ld-2.3.3.so: cpio: 

and after that, most of the rpm installs were fubar, because rpm 
could not execute 
anything due to missing ls-linux.so.2:

  pango 100 % done 7/208 
  error: %post(pango-1.4.0-1) scriptlet failed, exit status 255

I had left yum running by itself (as the upgrade took about 5 hours), 
so it
kept on going these fubared installs for about 100 rpm's before it 
mis-upgraded python
and sigbus'ed:

  zsh: bus error  yum --exclude=xorg\* --exclude=anaconda 
--exclude=gdm --excl

I found out that /lib/ld-linux.so.2, /lib/ld-2.2.3.so and 
/lib/tls/libc.so.6 were
missing. Through various LD_LIBRARY_PATH, LD_PRELOAD, 
"/backup/lib/ld-linux.so.2 /bin/cp ..." and ash.static hacks I was 
able to restore so much glibc libraries that I could try 
to reinstall the rpm's.

I verified the glibc rpm signatures, and md5 sums were ok. Installing 
glibc-utils-2.3.3-18, glibc-headers-2.3.3-18, glibc-2.3.3-18, 
glibc-devel-2.3.3-18, glibc-common-2.3.3-18 didn't prove easy, 
though. I got the same errors and lost the libraries again. The same 
story when trying to the previous glibc-2.3.3-16. 

This is using rpm-4.3-0.22 and rpm-4.3-0.20 (it was upgraded in the 
process.) I reinstalled 
rpm-4.3-0.22 with rpm -Uvh --force before retrying.) The original 
glibc problem happaned with rpm-4.3-0.20 (glibc was upgraded before 

Basically it, appeared that rpm had become completely unable to 
handle cases where it should replace a file with a link, replace a 
running binary/library, or anything non-trivial. After I did rm -rf 
/usr/lib/locale and some other offending files, I was able to install 
glibc*. However, the same problems continued when I reinstalled the 
misinstalled rpm's:

 python 100 % done 18/208 
 error: unpacking of archive failed on file /usr/bin/python: cpio: 
 gcc-c++ 100 % done 82/208
 error: unpacking of archive failed on file /usr/bin/c++: cpio: link
 e2fsprogs-devel 100 % done 69/208
 error: unpacking of archive failed on file 
 emacs 100 % done 96/208 
 error: unpacking of archive failed on file /usr/bin/emacs: cpio: 

and reinstalling SysVinit complained that /sbin/init textfile was 
busy. Well, duh!

(Sorry for the possibly inexact error messages, the rxvt where I 
cut'n'pasted these from 
was a bit garbled.)

So, all in all, I'm not sure if this is a bug in the rpm packages, 
rpm itself, yum, or perhaps in cpio. I would suspect rpm. But is 
quite serious.

Version-Release number of selected component (if applicable):
rpm-python-4.3-0.22 / 4.3-0.20
rpm-build-4.3-0.22 / 4.3-0.20
rpm-4.3-0.22 / 4.3-0.20
glibc-utils-2.3.3-18 (2.3.3-16 before upgrade)
glibc-2.3.3-18 (2.3.3-16 before upgrade)
glibc-devel-2.3.3-18 (2.3.3-16 before upgrade)
glibc-common-2.3.3-18 (2.3.3-16 before upgrade)

How reproducible:
the rpm problem still happens (it fails to replace file with links 
Comment 1 Ville Herva 2004-03-25 03:10:34 EST
Created attachment 98843 [details]
Log of the yum upgrade
Comment 2 Ville Herva 2004-03-25 03:51:24 EST
About reproducibility: I tried to recreate a link 
(/usr/share/man/man3/uuid_generate.3.gz) that rpm previosuly failed 
to cleanly replace when installing e2fsprogs-devel, and reinstall 
e2fsprogs-devel to get a strace. This time rpm -Uvh did not fail.
So it is not easily reproducible now, although it happened with about 
10 rpm's when I reinstalled the mis-installed rpms.

I'll try harder tonight. 
Comment 3 Ville Herva 2004-03-25 16:56:02 EST
Seems I cannot trigger it anymore (perhaps it is rpm-4.3-0.22 / 4.
3-0.20 difference), but the problem happened with quite many 
packages. And to me it was a serious issue. 

I just can't think of what could have caused it.
Comment 4 Ville Herva 2004-03-28 02:46:44 EST
Could you please outline why this is NOTABUG?

While I cannot trigger it anymore, it did happen more than once and rpm badly failing 
glibc upgrade is something that IMVHO is severe enough even if it happens once.

There WAS something *severely* wrong about how rpm tried to replace symlinks and 
files binaries that were in use. I have tried to think of what the could have caused this 
behaviour, but I cannot think of anything. 

I was hoping you had some idea. 

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