Bug 518720 - Yum does not check /var/cache/yum size
Summary: Yum does not check /var/cache/yum size
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 11
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
: 513361 (view as bug list)
Depends On:
Blocks: FedoraOnXO
TreeView+ depends on / blocked
Reported: 2009-08-21 20:12 UTC by Mikus Grinbergs
Modified: 2014-01-21 23:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-27 20:49:47 UTC
Type: ---

Attachments (Terms of Use)

Description Mikus Grinbergs 2009-08-21 20:12:30 UTC
Description of problem:
A requested yum operation can suddenly run out of room in /var/cache/yum, causing yum to terminate abnormally.

Version-Release number of selected component (if applicable):

How reproducible:
Always, if /var/cache/yum too small.

Steps to Reproduce:
1.Allocate say 100 MB to /var/cache/yum.
2.Request a yum operation that would require the downloading of more than 70 MB of packages.

[Note:  I had once before run into this problem when yum decided to install in my /var/cache/yum the "...-filelist.sqlite" data for the (F11) Fedora repository (almost 70 MB in size when unpacked).  But now the problem came up with an ordinary 'yum upgrade', without even involving "...-filelist.sqlite".]
Actual results:
After downloading for quite a while, yum terminated with "out of space" messages.

Expected results:
Yum would have warned before starting the downloads that it did not have enough room in /var/cache/yum.

Better yet, yum would have performed a "stepwise" download in case of "not enough room for all", fetching only a single package at a time (plus its dependencies) and procesing that by itself, instead of beginning by downloading *every* package identified by the requested yum operation.  [What I had issued was 'yum upgrade', which found enough updateable packages to need more than 70 MB of downloads.]

Additional info:
This occurred on an F11 image running on an OLPC-XO1 machine (which has a very limited amount of real storage).  Yet that image had mounted /var/cache/yum as a separate 'tmpfs' filesystem, with a total allocation of 110 MB (which turned out to be not enough space to complete my 'yum upgrade').  [Note that some space in /var/yum/cache is *already* being taken up by local copies of repository indexes ("...-primary.sqlite").]

Comment 1 Mikus Grinbergs 2009-08-26 00:03:46 UTC
A good way to max out the "overhead" storage requirement of yum is to enter 'yum makecache'.  I just did that on a Aug 2008 SoaS F11-on-XO1 build, and the resulting output from 'du /var/cache/yum' showed 184 MB was needed.

Comment 2 seth vidal 2009-08-26 16:11:36 UTC
can you include the error message you actually received here?

Comment 3 Mikus Grinbergs 2009-08-26 21:38:43 UTC
(In reply to comment #2)
> can you include the error message you actually received here?  

No error message.  [Truly - none whatsoever.]


Did testing with virgin (just-installed) F11-on-XO1 build
http://dev.laptop.org/~smparrish/xo-1/builds/os6.img .  [As part of booting to
the command line (in Sugar's 'Terminal' Activity), at home I always enter '
export http_proxy="" ' and now also ' export https_proxy="" '.]  When I installed it, this build had yum 3.2.23-3.fc1 ;  before running the build, I added python-urlgrabber 3.9.0-8.fc12 .

For the test, I deliberately mounted /var/cache/yum as a 'tmpfs'.  On the XO-1, that created a virtual partition of 110 MB.  I then entered 'yum makecache'.  The command ran for a while, then simply ended (without any error mesage).  The way I could determine that something was wrong was to enter 'df'.  That showed that there was no space left in /var/yum cache .

Here is a copy of the __only__ output the console ever showed:
> 0 [olpc]# yum makecache
> fedora/metalink              |  15 kB     00:00     
> fedora                                                             | 3.8 kB     00:00     
> fedora/group_gz              | 370 kB     00:00     
> fedora/filelists_db          |  13 MB     00:26     
> fedora/prestodelta           |  410 B     00:00     
> fedora/primary_db            | 8.4 MB     00:19     
> 0 [olpc]# df
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/mtdblock0         1048576    532096    516480  51% /
> tmpfs                   110140         0    110140   0% /dev/shm
> /tmp                    110140        24    110116   1% /tmp
> vartmp                  110140         8    110132   1% /var/tmp
> /dev/mmcblk0p1         7095808   4135648   2599712  62% /media/164f704b-a781-4795-9e2e-0fd812c5f9f5
> /dev/sda5              7874528   4035128   3439384  54% /media/43e6b669-c30b-40d0-8f5c-5901f5f9914a
> tmpfs                   110140    110140         0 100% /var/cache/yum
> 0 [olpc]#

You will notice that 'yum' terminates with return code 0.  From previous experience, I expect it blew while trying to unpack the filelist.sqlite data for the fedora repo.  [There are numerous other repositories listed in /etc/yum.repos.d/ -- what I think happened was that this instance of the yum command never got as far as trying to fetch from those.]

Comment 4 seth vidal 2009-08-27 17:15:09 UTC
wow,confirmed. That's very very special.

looking for what the heck swallows the error.

Comment 5 seth vidal 2009-08-27 20:49:47 UTC
okay. Found it - I love obscure bugs - but I'm sure this has hit a number of people and silently failing is such fun.

Fix will be upstream shortly and in before F12-final.


Comment 6 seth vidal 2009-09-03 16:00:23 UTC
*** Bug 513361 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Update System 2009-09-30 01:38:03 UTC
yum-3.2.24-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2009-10-19 16:44:58 UTC
yum-3.2.24-2.fc10 has been submitted as an update for Fedora 10.

Comment 9 Fedora Update System 2009-11-04 12:05:14 UTC
yum-3.2.24-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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