Bug 63056 - up2date behaves irratically when a very large number of updates are required
up2date behaves irratically when a very large number of updates are required
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2002-04-09 13:59 EDT by Need Real Name
Modified: 2015-01-07 18:55 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-09 14:29:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-04-09 13:59:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)

Description of problem:
I put a new 7.2 installation on my network, configured up2date to use my 
standard configuration (storagedir=/home/share/up2date, keepafterinstall=1, 
everything else default).  [Note: /home/share/up2date is a NFS share used by 
all hosts on the network and contains all rpms previously downloaded by any 
host on my LAN.  I ruled out nfs as the source of the problem by copying the 
directory to the local harddrive]

When running up2date on the new machine, a variety of problems were 
encountered -- segfaults, bogus checksum errors, and other errors which 
appeared in an inconsistant and erratic manner.  The box in question is a K6-
2/500 with 256 MB of RAM and 60GB of disk space (40+20).  The point where the 
most problems were encountered was while the rpm interdependencies were being 
resolved, which might indicate some kind of overflow or resource exhaution in 

My initial thought was that either /var/spool/up2date or /tmp was filling up, 
but the problem persisted even after mounting an empty 10GB partition 
on /var/spool/up2date.  There appeared to be plenty of free space in /tmp as 
well (/tmp has nearly >900M free).

The workaround I came up with was to repeatedly run 'rpm -Uhv' on small sets (< 
6) of packages in /home/share/up2date, then run 'up2date -p' after about 70% of 
the required packages

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

How reproducible:

Steps to Reproduce:
1. Install a virgin RH 7.2 system (I did a fairly extensive installation -- 
with X, KDE, gnome, Apache + several modules, samba, nfs, etc.  The problem 
appears not to be the specific packages involved, but the total size and 
complexity of the update)

2. Run rhn_register
3. nfs mount directory containing previously-downloaded .rpm and .hdr files 
on /home/share/up2date (or copy files into local directory of same name)
3. edit /etc/sysconfig/rhn/up2date; set storagedir=/home/share/up2date and 
4. Run up2date --nox --update


Actual Results:  Varied: segfaults, bogus MD5 checksum errors, bogus bad 
signature notices, even a kernel panic once.  Errors occured at many different 
points in the process, but most often while resolving dependencies

Expected Results:  All updates should be installed without error

Additional info:
Comment 1 Adrian Likins 2002-04-09 14:29:46 EDT
My first impression is that this sounds alot like random memory corruption
cause by hardware failures. 

  The md5sum and gpg checks are fairly cpu and memory intensive, and very 
  fragile in the face of hardware problems.

  It only happens with very large sets of packages, which would tend to
  stress the mem/cpu more. 

  I havent seen any other similar reports, and I havent seen it in internal
  testing (I typically upgrade every package on a box in a go many times 
  a day...)

  segfaults and kernel oopses often occompany hardware issues (cpu overheating
   and faulty memory in particular).

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