From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Description of problem:
In order to upgrade glibc (security problem upgrading standard RH8.0 to
glibc-2.3.2-4.80) I had to clear 177Mbytes of space on the root fs. During the
installation the free space was never less than about 150Mbytes. This seems
I was upgrading glibc, glibc-devel and glibc-common.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Root fs with 150Mbyte free
2. Try to upgrade above 3 packets with command:
3. rpm -U glibc glibc-2.3.2-4.80.i686.rpm glibc-devel-2.3.2-4.80.i386.rpm
Actual Results: rpm claimed there was not enough space on root fs
Expected Results: Should have installed
Similar behavior on one of my systems. The glibc/glibc-common/glibc-devel
2.3.2-4.80 i686 RPM installation worked on two systems, but failed on the
system with 155 MB free disk space. The error said that the installation
failed because it required 34 MB of free disk space on /.
I have the same bug on RedHat 9 system though I should say that it is not limited only to
glibc rpm package. Seems that new rpm has BIG problems calculating correct disk space
needed for install.
Here is an example:
[root@miami root]# LANG=C apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded
arts arts-devel glibc glibc-common glibc-devel kdebase kdelibs kdelibs-devel kdemultimedia
libogg nscd quanta
redhat-artwork samba samba-client samba-common xvidcore
The following packages have been kept back
apt mplayer qt qt-designer qt-devel
17 packages upgraded, 0 newly installed, 0 removed and 5 not upgraded.
Need to get 0B/92.0MB of archives.
After unpacking 812kB disk space will be freed.
Do you want to continue? [Y/n] y
Executing RPM (-Uvh)...
warning: /var/cache/apt/archives/glibc-common_2.3.2-27.9_i386.rpm: V3 DSA signature:
NOKEY, key ID db42a60e
warning: /var/cache/apt/archives/arts-devel_8%3a1.1.1-0.3.8.0_i386.rpm: V3 DSA
signature: NOKEY, key ID ff6382fa
warning: /var/cache/apt/archives/xvidcore_0.9.1-fr2_i386.rpm: V3 DSA signature: NOKEY,
key ID e42d547b
installing package glibc-common-2.3.2-27.9 needs 18MB on the /usr filesystem
installing package glibc-2.3.2-27.9 needs 18MB on the /usr filesystem
installing package arts-devel-1.1.1-0.3.8.0 needs 18MB on the /usr filesystem
installing package libogg-1.0-22.214.171.124 needs 18MB on the /usr filesystem
installing package arts-1.1.1-0.3.8.0 needs 18MB on the /usr filesystem
installing package glibc-devel-2.3.2-27.9 needs 18MB on the /usr filesystem
installing package kdelibs-devel-3.1.1-0.5.8.0 needs 106MB on the /usr filesystem
installing package kdelibs-3.1.1-0.5.8.0 needs 107MB on the /usr filesystem
installing package kdebase-3.1.1-0.8.8.0 needs 113MB on the /usr filesystem
installing package kdemultimedia-3.1.1-0.3.8.0 needs 114MB on the /usr filesystem
installing package nscd-2.3.2-27.9 needs 114MB on the /usr filesystem
installing package quanta-3.1.1-0.0.8.0 needs 116MB on the /usr filesystem
installing package redhat-artwork-0.73-126.96.36.199 needs 116MB on the /usr filesystem
installing package samba-common-2.2.7a-8.9.0 needs 115MB on the /usr filesystem
installing package samba-2.2.7a-8.9.0 needs 118MB on the /usr filesystem
installing package xvidcore-0.9.1-fr2 needs 118MB on the /usr filesystem
installing package samba-client-2.2.7a-8.9.0 needs 118MB on the /usr filesystem
E: Sub-process /bin/rpm returned an error code (34)
[root@miami root]# LANG=C df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda7 2450928 2305076 120952 96% /
/dev/hda1 7746 6204 1542 81% /boot
/dev/hda2 1534152 1445044 89108 95% /home
/dev/hda6 1999964 1822860 177104 92% /usr
none 126996 0 126996 0% /dev/shm
It is funny to see that arts or libogg can't install on the disk that has more than 170Mb free!
For me problem usually appears if I try to upgrade a set of rpm packages at once, specifing all
of them in the command line - with one package error is less probable.
Red Hat Linux 8 is a no longer supported project. If this bug is still valid
against latest RPM in Fedora Core 4 or rawhide please reopen adding necessary