Title:
Repair an RPM database safely
![RPM homepage link]()
Home
Up
| |
Q. I can't upgrade any packages, run up2date or rpm.
What is wrong?
A. The RPM database sometimes gets stuck. One cause of this problem is
when a process working on the RPM database is killed, which leaves lock
files in place, limiting what further processes can do to the database. So,
a word to the wise:
make sure such a process really is stuck before killing it - if a process
is using much CPU time (eg. as reported by top) it is probably still doing
useful work.
A tip o' the hat to: M A Young <m.a.young@xxxxxxxxxxxx> for
this summarization.
This has to be repaired manually for rpm to eliminate waht are
described at 'hangs', and to permit rpm to properly
function.
What the nature of the underlying problem is, and how to fix it,
are detailed below:
First informally: When a process _is_ so killed
[sometimes due to a loss of power crash,
sometimes due to a third party helper application dying without cleaning
up the lock files at exist,
sometimes due to an impatient admin],
it will almost always leave some small
corruption behind in the RPM 'SleepyCat' db based database.
Usually the simple
rm -f /var/lib/rpm/__db*
rpm --rebuilddb
will remove the lockfiles (which start with that distinctive "__"),
and fix the database damage left behind.
But sometimes more substantive database repair is needed, as described below
the section with Jeff Johnson's email later in this discussion.
Think of a two way linked list (we ignore indices to simplify the
presentation) for RPM Package description items thus:
-> -> -> ->
A B C D E
<- <- <- <-
If we have just a couple of broken links, we do not have any 'orphan
chains' and rpm --rebuilddb can repair things:
-> -> ->
A B C D E
<- <- <-
But if substantial persistent corruption occurs, and is not repaired for a
long time, we might get:
-> ->
A B C D E
<- <-
And it becomes unclear where to re-attach A and B, to the other chain.
(Note: This
is an analogy, and does not precisely describe the data structures,
rebuild or dump processes from a formal standpoint.)
What else might cause the problem? Warren Togami has reviewd the
trouble ticket trackers for the Conectiva apt for rpm package, and
others (the Ximian updater, Gerald Teschl's autoupdate), and helped
locate some interaction issues
which are being worked on and discussed on the RH rpm-list.
More formally: see the Bugzilla master ticket on this issue,
73097
Separately, a testing release (issued 7 Oct 2002) for an
updated RPM is available at Jeff Johnson's personal ftp site
ftp://people.redhat.com/jbj/test-4.1/
-- Warning: This is NOT a formal Red Hat QA approved
release.
Date: Thu, 8 Aug 2002 09:10:12 -0400
From: Jeff Johnson <jbj@xxxxxxxxxx>
Subject: Re: rpm database - how to repair it?
On Thu, Aug 08, 2002 at 01:37:52PM +0200, Robert Vojta wrote:
<snip>
> What is the safest way how to repair rpm database
> (if it's corrupted)? I was doing this job a long time
> ago and I forgot the whole process :(
Hmmm, "hangs" in select are usually stale locks. Fix by doing
rm -f /var/lib/rpm/__db*
Otherwise,
All that needs repairing is /var/lib/rpm/Packages, the indices can/will be
rebuilt with rpm --rebuilddb later.
Save a copy just in case:
cd /var/lib
tar czvf /tmp/rpmdb.tar.gz rpm
Verify integrity with
cd /var/lib/rpm
db_verify Packages
If there are any errors, repair by doing
mv Packages Packages-ORIG
db_dump Packages-ORIG | db_load Packages
Read all the headers in Packages by doing
rpm -qa
If you segfault here, make an entry at
http://bugzilla.redhat.com and
I'll tell you what to do.
Rebuild the indices
rpm --rebuilddb
------------------------------------
HTH
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj@xxxxxxxxxx (jbj@xxxxxxx)
Chapel Hill, NC
Later:
On Thu, Aug 08, 2002 at 08:08:13AM -0400, Gene C. wrote:
>
> 2. There are circumstances that screw up the rpm "database" which
> are not recoverable ... you will need to re-install.
No, there aren't any cases the database is not recoverable. There are still
times that a re-install is an easier recovery pathway, however.
Editor's Note added September 18 2002:
In moving to RPM-4.1, the above repair and test process needs an update
of the db3-3.x packages packages from the RPM ftp site, if an error of
the following sort shown in bold
red is encountered:
[root@router root]# rpm -Uvh popt-1.7-1.07.7x.i386.rpm \
rpm-4.1-1.07.7x.i386.rpm rpm-build-4.1-1.07.7x.i386.rpm \
rpm-python-4.1-1.07.7x.i386.rpm
Preparing ... ########################################### [100%]
1:popt ########################################### [ 25%]
2:rpm ########################################### [ 50%]
3:rpm-build ########################################### [ 75%]
4:rpm-python ########################################### [100%]
# > then try the 'test tip' at the RPM website:
# >
# > http://www.rpm.org/hintskinks/repairdb/
# >
[root@router root]# rpm --rebuilddb
[root@router root]# cd /var/lib ; tar czvf /tmp/rpmdb.tar.gz
<snip>
[root@router lib]# cd /var/lib/rpm
[root@router rpm]# db_verify Packages
db_verify: Program version 3.2.9 doesn't match environment version 4.0.14
[root@router rpm]#
These earlier 'transition' packages are available here.
Last updated: Sat, 30 Nov 2002 12:31:59 -0500
|
Back to Top page
Maintained by Owl
River Company -- Comments to:
rpm editor, please.
|
|