Red Hat Bugzilla – Bug 119122
glibc rpm upgrade fails badly
Last modified: 2007-11-30 17:10:38 EST
Description of problem:
This is a longish story, and I'm not sure where I should report this
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
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),
kept on going these fubared installs for about 100 rpm's before it
zsh: bus error yum --exclude=xorg\* --exclude=anaconda
I found out that /lib/ld-linux.so.2, /lib/ld-2.2.3.so and
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
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
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)
the rpm problem still happens (it fails to replace file with links
Created attachment 98843 [details]
Log of the yum upgrade
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.
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.
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.