Bug 132064 - up2date checks the diskspace only for the binary packages
up2date checks the diskspace only for the binary packages
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Red Hat Satellite QA List
:
Depends On:
Blocks: 191074 191079
  Show dependency treegraph
 
Reported: 2004-09-08 10:30 EDT by Thomas Uebermeier
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:19:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Uebermeier 2004-09-08 10:30:12 EDT
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 10:46:57 EDT
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 12:49:12 EDT
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-10 20:33:09 EDT
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release
Comment 6 Fanny Augustin 2006-04-13 15:37:14 EDT
Moving bugs to the CanFix List
Comment 7 Fanny Augustin 2006-05-08 15:15:53 EDT
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 16:06:08 EDT
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 Product and Program Management 2007-10-19 15:19:04 EDT
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.