Bug 78013

Summary:	up2date crashes system after installing latest php-manual rpm
Product:	[Retired] Red Hat Linux	Reporter:	Thomas Bolioli <terraformer>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED NOTABUG	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.1	CC:	gafton, mihai.ibanescu
Target Milestone:	---
Target Release:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-12-03 21:15:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas Bolioli 2002-11-17 14:51:32 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016

Description of problem:
Twice (I can't try a third time), up2date crashed the system after installing
the latest php-manual rpm. Both times the system remains pingable but none of
the services responded. I was also not able to log in under the console and my
current session was toast. The first time, when I restarted the system, fsck
failed to fix the errors and I had to go into single user mode and tweak fsck
with a few options (don't remember) to get it to repair everything. All of the
files that were fried were all related to php-manual. BTW, it failed about 85%
of the way into the install. The second time I did this it made it 100% of the
way through the package update and then locked me out of the system. When I
restarted fsck was able to pick up the pieces (all php-manual related) without a
single user mode session but when I went to run up2date or rpm it failed (see
below for error). Now the rpm database is corrupt and nothing is able to fix it.
I tried info from http://rpm.redhat.com/hintskinks/repairdb/ and that did not
work. As it was, the verification took days since the Packages file is 15meg. 

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


How reproducible:
Always

Steps to Reproduce:
1.ran up2date on my system with php-manual as one of the to be updated packages
2.
3.
	

Actual Results:  
[root@terra rpm]# up2date --update
rpmdb: page 3156: illegal page type or format
rpmdb: PANIC: Invalid argument
rpmdb: /var/lib/rpm/Packages: pgin failed for page 3156
error: db4 error(-30981) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run
database recovery
error: db4 error(-30981) from dbcursor->c_close: DB_RUNRECOVERY: Fatal error,
run database recovery
error: db4 error(-30981) from db3c_open: DB_RUNRECOVERY: Fatal error, run
database recovery
error: db4 error(-30981) from db->get: DB_RUNRECOVERY: Fatal error, run database
recovery
Traceback (innermost last):
  File "/usr/sbin/up2date", line 781, in ?
    main()
  File "/usr/sbin/up2date", line 569, in main
    pkgNames, fullUpdate, dryRun = dry_run))
  File "/usr/sbin/up2date", line 724, in batchRun
    batch.run()
  File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 57, in run
    self.__findPackagesToUpdate()
  File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 89, in
__findPackagesToUpdate
    plist.run()
  File "/usr/share/rhn/up2date_client/packageList.py", line 76, in run
    installedPackageList = rpmUtils.getInstalledPackageList()
  File "/usr/share/rhn/up2date_client/rpmUtils.py", line 409, in
getInstalledPackageList
    h = db[key]
rpm.error: cannot read rpmdb entry
error: db4 error(-30981) from db->close: DB_RUNRECOVERY: Fatal error, run
database recovery
error: db4 error(-30981) from dbenv->close: DB_RUNRECOVERY: Fatal error, run
database recovery
error: db4 error(-30981) from db_env_create: DB_RUNRECOVERY: Fatal error, run
database recovery
error: db4 error(-30981) from dbenv->remove: DB_RUNRECOVERY: Fatal error, run
database recovery


Expected Results:  a completed update of errata packages

Additional info:

Comment 1 Adrian Likins 2002-12-02 22:37:58 UTC

First thought is this sounds like you have a hard drive that is
dieing. Since php-manual is a pretty big package, it's a good
candidate for tweaking a unstable disk (lots of disk io to
install that package...)

And of course, none of the behaviour mentioned sounds like
something that a simple package install (failed or not) should
cause. 

Also, rpmdb is something else that gets easily freaked out if
there are io errors from the disk. 

It could potentially maybe something deep down in rpm causing
that package installed to die horribly and spew garbage on the
disk (though, as mentioned before, my guess is bad hardware...) so
I'm bouncing this to the rpm component to let the rpm maintatiner
take a look at it to be sure.

Comment 2 Thomas Bolioli 2002-12-03 21:15:51 UTC

OK, over the weekend I discovered there may be a hardware problem so you may be
right. But the rub is I checked the hardrives a month ago when this problem
originally happened and they seemed fine. I will skip the details but I have
upgraded to a whole new machine (over the turkey day weekend) and when I tried
to reinstall over the old machine to use it as a backup it failed when perfoming
the initial partition format. I changed out the drives and cables and it still
failed in the formatting of the partitions. I have no way of knowing but it
appears the HD controller is bad. Despite not knowing for sure, I would say this
should be closed out.