Red Hat Bugzilla – Bug 33649
Wolverine upgrade from 7.0 filled up /var and gave up without cleaning up
Last modified: 2007-04-18 12:32:25 EDT
I had problems upgrading from RH 7.0 to the beta Wolverine version. The
first time, after I selected packages to upgrade, it said that it needed a
few hundred K more space in /, and let me go back and de-select some
packages. This was a bit uncool, in that the package selection pages give
no hint whatsoever of how much space they need in / (vs /usr, etc). It
also gave no way of dropping into a shell to manually clean up any unneeded
files, other than rebooting. I wanted to keep all the selections I had
made, so I kept going.
This time it said it needed 15 Megs in /. At this point I removed the CD
and rebooted the system. What I found in /var/lib/rpm was two temporary
copies of the Packages database, at about 13-14 Megs apiece, both created
during the upgrade attempt.
The upgrade process should either remove the working copy of the database
before returning to the selection process, or reuse the same file the next
time it checks for dependencies and disk space.
It should also provide usable information to help choose packages to leave
out of the upgrade. Even more valuable would be some way to delete
existing packages, in addition to the choice between upgrading or not.
These temporary files are removed if you exit the installer cleanly. Since you
rebooted there was no opportunity to clean them up.
Matt could we be better about looking in /var/lib/rpm and removing left over
temp files to free space?
Excuse me? Where does the installer give any option to exit cleanly when there
is not enough space to do the upgrade?
Before I rebooted, I went back and deselected some packages. Then when I
clicked NEXT> to attempt the upgrade again, it created the second 14-meg copy
of the database. THIS is where it should have cleaned up the temp space.
For that matter, it should blow away any temp files it finds there before it
begins the upgrade -- If I had booted the install CD again, I'll bet the garbage
would have still been there.
I checked in a patch to remove anaconda-rebuilddbXXXXXXXXX when a rebuild fails
or when an upgrade package search fails.