Bug 88788 - rpm --rebuilddb fails
rpm --rebuilddb fails
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
9
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-14 02:19 EDT by Need Real Name
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-04-14 02:19:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
whenever I run rpm --rebilddb I get this error

error: db4 error(16) from dbenv->remove: Device or resource busy

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

How reproducible:
Always

Steps to Reproduce:
1.in a shell I type rpm --rebuilddb    

Actual Results:  the output before it crashes:

D: adding "Development/Languages" to Group index.
D: adding 13 entries to Requirename index.
D: adding 3 entries to Providename index.
D: adding 3 entries to Dirnames index.
D: adding 13 entries to Requireversion index.
D: adding 3 entries to Provideversion index.
D: adding 1 entries to Installtid index.
D: adding 1 entries to Sigmd5 index.
D: adding "665ca8b6dab16505c57ffe91c661dec74bc7d4f5" to Sha1header index.
D: adding 53 entries to Filemd5s index.
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
error: db4 error(16) from dbenv->remove: Device or resource busy
D: removed  db environment /var/lib/rpm/Packages
D: closed   db index       /var/lib/rpmrebuilddb.4659/Pubkeys
D: closed   db index       /var/lib/rpmrebuilddb.4659/Filemd5s
D: closed   db index       /var/lib/rpmrebuilddb.4659/Sha1header
D: closed   db index       /var/lib/rpmrebuilddb.4659/Sigmd5
D: closed   db index       /var/lib/rpmrebuilddb.4659/Installtid
D: closed   db index       /var/lib/rpmrebuilddb.4659/Provideversion
D: closed   db index       /var/lib/rpmrebuilddb.4659/Requireversion
D: closed   db index       /var/lib/rpmrebuilddb.4659/Dirnames
D: closed   db index       /var/lib/rpmrebuilddb.4659/Triggername
D: closed   db index       /var/lib/rpmrebuilddb.4659/Conflictname
D: closed   db index       /var/lib/rpmrebuilddb.4659/Providename
D: closed   db index       /var/lib/rpmrebuilddb.4659/Requirename
D: closed   db index       /var/lib/rpmrebuilddb.4659/Group
D: closed   db index       /var/lib/rpmrebuilddb.4659/Basenames
D: closed   db index       /var/lib/rpmrebuilddb.4659/Name
D: closed   db index       /var/lib/rpmrebuilddb.4659/Packages
D: closed   db environment /var/lib/rpmrebuilddb.4659/Packages
D: removed  db environment /var/lib/rpmrebuilddb.4659/Packages
D: removing directory /var/lib/rpmrebuilddb.4659
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
[root@Andrew root]# 

Expected Results:  no output

Additional info:

I had installed some alsa rpm's beforehand from freshrpms.net.
Comment 1 Jeff Johnson 2003-04-14 10:41:37 EDT
Yes, an attempt to remove the dbenv while still in
use prints an error message. The message is harmless.
Comment 2 Alex Kanavin 2003-04-14 12:38:50 EDT
It is harmless to the existing database, 
but rpm does not actually create a new rebuilt 
database either and it leaves __db* files in 
/var/lib/rpm. Upgrading to rpm-4.2-1 does not help.
Comment 3 Jeff Johnson 2003-04-14 12:43:06 EDT
Say what? The above -vv snippet shows that the indices were
sucessfully rebuilt, and renamed back into place, in spite
of the error.

Yes __db* files are persistent in rpm-4.1 and later.

Upgrading to rpm-4.2 does not help *what*?
Comment 4 Alex Kanavin 2003-04-14 13:03:44 EDT
Maybe I was confused by the fact that the mtime of the indices
stays exactly the same as before after the rebuild. 
Is that how it should be?
Comment 5 Jeff Johnson 2003-04-14 13:04:51 EDT
Yes. Try looking at the creation time.
Comment 6 Alex Kanavin 2003-04-14 13:21:42 EDT
Creation time? Unix files do not have that, I always thought.

The glibc manual says:
==============
Each file has three time stamps associated with it:  its access time,
its modification time, and its attribute modification time. [...]
When a file is created, all three time
stamps for that file are set to the current time.
==============
So how do the mtimes of the new indices end up being set 
to the mtimes of the old ones I don't understand....
But the inode numbers change, so it must be working indeed.
Comment 7 Jeff Johnson 2003-04-14 14:11:30 EDT
Yup, no create time, I'm corrected.

Yes, I forgot inode, and meant the time that can't
be changed with utime(2) or utimes(2).

But we agree files are changed ;-)

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