Bug 77469 - Significant Data-loss type issues on RHN updates
Significant Data-loss type issues on RHN updates
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Adrian Likins
Red Hat Satellite QA List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-07 10:54 EST by Need Real Name
Modified: 2007-04-18 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-15 01:09:35 EST
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 Need Real Name 2002-11-07 10:54:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
After initial update through RHN, rpm no longer works properly. It will hang on
most install tries.  If I install RH8:Custom:Everything, and then *NOT* RHN
update, I can function perfectly.  If I install RH8:Custom:Everything and run
RHN update, I can no longer install NVIDIA drivers, apt-get-rpm, synaptic. 
(these are the programs I've tried)

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


How reproducible:
Always

Steps to Reproduce:
1.  Install RH 8.0 Custom:Everything
2.  Run complete RHN update
3.  Install NVIDIA, apt-get-rpm, or synaptic  (all I tested...It has been part
of my standard load for a couple years now)
	

Actual Results:  System will run fine if rpm is not used.  Any attempt to use
rpm from cli :  rpm -Uvh, rpm -ivh, etc.  will result in the session hanging. 
You can CTRL-C out of the hang, but ps ax |grep rpm shows the process still
alive.  You must kill the process at this point.

Expected Results:  Package should've installed or failed via standard rpm behavior

Additional info:

I've tried this as a complete install on a P2-333 box with 256MB Ram and 20GB
disk twice, and on a Cele 550 with 128M RAM.  Reproduces...

I have a P3 650 and a P4 1.2 that I will be researching it on today.

When it hangs significantly, in some cases it causes a complete hang of the
system (no capslock or numlock).  On reboot, after recovering journals and
cleaning up, KDE3 hangs to reboot in the X load screens.At this point, the
system is unusable and requires a reload.
Comment 1 Adrian Likins 2002-11-07 18:13:41 EST
try:

  rm -rf /var/lib/rpm/__*

and trying again. This looks to be a rpm database related
locking bug (the __* files are essentially lock files).
Comment 2 Need Real Name 2002-11-08 00:24:37 EST
Ok...  found and fixed problem.

Note:  If *any* program up2date is going to update is open, or even in memory, 
the rpm database (instead of not applying the update and giving an error as 
should be) will simply corrupt itself.  a quick edit of inittab to runlevel 3, 
reboot, rpm --rebuilddb, and then an up2date on a clean boot fixes the problem.

Thanks for the help.

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