Bug 132064 - up2date checks the diskspace only for the binary packages
Summary: up2date checks the diskspace only for the binary packages
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bret McMillan
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: 191074 191079
TreeView+ depends on / blocked
 
Reported: 2004-09-08 14:30 UTC by Thomas Uebermeier
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 19:19:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Thomas Uebermeier 2004-09-08 14:30:12 UTC
From Bugzilla Helper: 
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux 
2.6.6-1.435.2.3smp) (KHTML, like Gecko) 
 
Description of problem: 
When up2date performs an update (or any other installation action) it 
checks the diskspace, but does this only for the binary packages. 
(actually only for packages that are going to be installed). 
 
When retrieveSource=1 the source packages are being retrieved as 
well, but as the calculation of the diskspace is being done before 
downloading and there is no further check afterwards (or while 
installing) disk space might get low and the database (?) might get 
inconsistent. 
 
Version-Release number of selected component (if applicable): 
 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
1. set retrieveSource=1 in /etc/sysconfig/rhn/up2date 
2. have little disk space left or fill the disk after up2date did the 
diskspace 
3. start up2date -u 
 
Actual Results:  inconsistent RPM DB

Comment 1 Paul Nasrat 2004-09-08 14:46:57 UTC
To clarify a little on inspection of the box in question various
packages were removed from rpmdb but were not updated/removed from
filesystem.

I generated a manifest based on /var/log/up2date array and matching
against n-v-r key in db.  If not installed (and not kernel*) I
outputed to missing-packages

[root@dhcp-136 tmp]# wc -l missing-packages
     77 missing-packages

Attempting install from manifest:

rpm -Uv --test --percent missing-packages
...
        installing package openoffice.org-i18n-1.1.0-16.13.EL needs
51MB on the / filesystem
        installing package openldap-clients-2.0.27-17 needs 51MB on
the / filesystem
        installing package ntsysv-1.3.11-0.3 needs 51MB on the /
filesystem
        installing package nss_ldap-207-11 needs 54MB on the / filesystem
        installing package nfs-utils-1.0.6-31EL needs 54MB on the /
filesystem

Included in there were things like XFree86. up2date looks like it's
disabling disk space checking rpm.RPMPROB_FILTER_DISKSPACE

Suggestions - don't ignore diskspare errors, add src.rpm calculation
to totalSize in BatchRun


Comment 2 Adrian Likins 2004-09-09 16:49:12 UTC
There are two components to the space calculation. The
first one is at the up2date app level and is an attempt
to see if there is enought diskspace in /var/spool/up2date 
to download all the needed packages. 

Currently that only calculates space needed for binary
packages. At the moment, the client/server protocol
doesnt have any mechnanism for determining the size of
the src rpms before downloading them, so that would have
to change to do this correctly.

The other size calculation is done by rpm, and thats the
calculation to see if there is enough space to actually
_install_ the packages. 

Comment 5 Fanny Augustin 2006-04-11 00:33:09 UTC
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release

Comment 6 Fanny Augustin 2006-04-13 19:37:14 UTC
Moving bugs to the CanFix List

Comment 7 Fanny Augustin 2006-05-08 19:15:53 UTC
This bug did not make the code freeze and it will not be fiixed during this
release cycle.  Re-aligning bug to the next release

Comment 8 Fanny Augustin 2006-05-08 20:06:08 UTC
This bug did not make the code freeze.  It will not be fixed in this releasee 
Reea ligning to the next one.

Comment 9 RHEL Program Management 2007-10-19 19:19:04 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.


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