Red Hat Bugzilla – Bug 68486
Anaconda does not correctly calculate the disk space required
Last modified: 2007-04-18 12:44:03 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 Description of problem: When doing an install-everything it said the size of the install was ~3.87 GB. I was installing in a single 4GB partition, and anaconda reported I needed an additional 31 MB in /usr. I could not back track to correct this problem by repartition the disk to accomodate this increased space requirement. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. The process is discribed above. 2. I have seen similar problems doing installes in multiple partitions. 3. This means the problem is reproducible when a partition is too small. Actual Results: The results are described above. Expected Results: Anaconda should correctly calculate and report the required install size at a point where a user could make sure they have sufficient sized partition(s) available. Does an install require addition of a fudge factor to install sizes for processing input RPMs? Additional info: I even tried unmounting the single large partition in vt2, but the partition was busy. Lsof was not a vailable, but I assume it was a CWD for part of anaconda. It wouold be nice if it was possibvle to unmount /tmp/sysimage to allow recovery of this sirt of failing install(or update of a previous install)
In the package selection screen, we're just showing you how much space is required for the packages. This doesn't include overhead for things like cache files created by various package %post scripts, the rpmdb, or the size of the install image needed on the hard drive. But when the rpm space calculation occurs, it takes all of this into account (and also number of inodes)
There appear to be several problems here. One is that the disk space in the early (package selection) part of Anaconda is inaccurate. Another is that the disk space calculation for upgrades is wildly inaccurate since it doesn't appear to take account of the space used by the existing packages. I have tried to upgrade two computers from RH 7.1 to 7.3. BOTH of them have given me endless grief over this. I go through all the usual steps and get to the end and it spends "minutes" copying an install image and then spends more minutes twiddling its thumbs and then it announces "You don't appear to have enough disk space to install the packages you've selected. You need more space on the following filesystems: / 220M". That was the second try. The first time, it demanded more than 350MB more -- so I went back and deleted *more than* 350MB of packages from the list of packages to upgrade. Then went forward with the upgrade. Then I go through ten minutes of foot-twiddling while it does something slow and useless, and now it tells me it wants 220MB. WHY WON'T IT TELL ME WHAT IT REALLY WANTS? WHY DOES IT PUT US THROUGH THIS TORTURE? What puts the icing on the cake is that it turned out in my very first RH7.1 to 7.3 upgrade that when all was said and done, it really didn't need all that disk space. After I went back around several times, deleting packages from the list to update, until it finally ungraciously consented to do the upgrade -- then I upgraded those packages manually which I had had to skip the first time -- it had PLENTY of disk space! There's just some serious bug in how it's calculating all this crap. But every time someone mentions this, you guys close out the bug without ever fixing it. Bug #35798 is another variant of this bug, reported in RH 7.1, and also closed out by incompetent maintainers. If you won't fix this, you should at least make a button for "GO AHEAD ANYWAY" in the "You don't appear to have enough disk space" dialogue -- so that users can get their *$*&#$&# systems upgraded without endlessly reporting the same bug and having you ignore them.
Bug 20554 is another person who ran into this problem -- in RH 7.0.