On Jul 19, 2009, at 4:26 AM, Ralf S. Engelschall wrote:
Although we've not changed the underlying DB version in RPM 5, since
recently with 5.1.9 I see at the end of the OpenPKG "bootstrap"
package
upgrade:
| rpmdb: PANIC: fatal region error detected; run recovery
| error: db4 error(-30974) from db->cursor: DB_RUNRECOVERY: Fatal
error, run database recovery
| [...]
| rpmdb: File handles still open at environment close
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/__db.001
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Packages
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Basenames
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Name
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Sha1header
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Triggername
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Group
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Providename
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Requirename
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Dirnames
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Requireversion
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Provideversion
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Installtid
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Sigmd5
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Filedigests
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Packagecolor
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Nvra
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/Filepaths
| rpmdb: Open file handle: /v/gmbh/sw/RPM/DB/BuildEnvironment
| rpmdb: PANIC: fatal region error detected; run recovery
| error: db4 error(-30974) from dbenv->close: DB_RUNRECOVERY: Fatal
error, run database recovery
(aside)
What is in BuildEnvironment?
I need a bit more context for orientation wrto what operation was
performed.
The reason is that because in %pre and %post a few "rpm -q" operations
are performed. Those seem to be still work fine as before, but at the
end of the outer "rpm -U" operation RPM seems to detect the above
problem now. Nothing seems to be actually broken afterwards, but the
above errors make me feel bad and also confuse users.
What is the basis for the "reason"? There are *lots* of possible
causes for DB_RUNRECOVERY ...
Two questions come up for me:
1. Why were no such errors in the past with 5.0.x and <= 5.1.[7-9]
(approximately)?
Dunno. DB_RUNRECOVERY is ultimately a data, not an implementation,
issue.
2. What can we do to workaround this problem? Perhaps run
the "rpm -q" operations in a special RPMDB read-only mode or
something like this? Perhaps --define '__dbi_private yes'?
There's lots of ways to workaround (but not DB_PRIVATE disabling locks).
Are chroot's involved?
What is being queried?
Do you have a definite reproducer or is the problem just occurring
occaisionally randomly?
73 de Jeff
Ralf S. Engelschall
[email protected]
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
