On Feb 14, 2011, at 6:30 PM, Silvan Calarco wrote: > On Tuesday 15 February 2011 00:24:37 Silvan Calarco wrote: >> On Monday 14 February 2011 20:02:04 Jeff Johnson wrote: >>> No worries, I *am* an expert at using Berkeley DB, all of them, every >>> which way ;-) >> >> Good, that's reassuring to hear :) >> >>> The DB_SECONDARY_BAD means that the primary (i.e. Packages) and secondary >>> (all the rest of the indexes) are out of sync. This is fixed by >>> >>> rpm --rebuilddb -vv >>> >>> which will regenerate all the indexes. >> >> Rebuild doesn't fix the problem. So far I'm reiterating the following >> commands to be sure that I'm testing the whole upgrade procedure from >> initial 5.2.1 db: >> >> mv /var/lib/rpm /tmp >> cp -a /var/lib/rpm.5.2 /var/lib/rpm >> rm -f /var/lib/rpm/DB_CONFIG >> db_dump-47 /var/lib/rpm/Packages | sed -e 's/^type=hash$$/type=btree/' \ >> -e '/^h_nelem=/d' -e 's/^ \(..\)\(..\)\(..\)\(..\)$$/ \4\3\2\1/' | \ >> db_load-47 /var/lib/rpm/Packages.new >> mv -f /var/lib/rpm/Packages.new /var/lib/rpm/Packages >> rpm --rebuilddb -vv >> >> But I still get: >> >> # rpm -i /tmp/python-rpm-5.3.8-2mamba.arm.rpm >> rpmdb: /var/lib/rpm/Packages: DB_SECONDARY_BAD: Secondary index >> inconsistent with primary >> error: db3cget:db3.c:1314: dbcursor->get(-30973): DB_SECONDARY_BAD: >> Secondary index inconsistent with primary >> rpm: rpmdb.c:2186: rpmmiNext: Assertion `0' failed. >> Aborted > > This is the output of rpm --rebuilddb -vv: > > D: pool fd: created size 208 limit -1 flags 0 > D: pool iob: created size 20 limit -1 flags 0 > D: pool mire: created size 84 limit -1 flags 0 > D: pool lua: created size 32 limit -1 flags 0 > D: pool ts: created size 888 limit -1 flags 0 > D: pool db: created size 208 limit -1 flags 0 > D: pool dbi: created size 288 limit -1 flags 0 > D: rpmdb: cpus 1 physmem 208Mb > D: opening db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn > Freeing read locks for locker 0x10: 1068/0 > Freeing read locks for locker 0x12: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0 > Freeing mutex for process: 1068/0
This is cleaning up "stale locks" from process 1068 abnormally exiting. > D: opening db index /var/lib/rpm/Packages create:thread:auto_commit > mode=0x2 > D: pool tsi: created size 24 limit -1 flags 0 > D: closed db index /var/lib/rpm/Packages > D: closed db environment /var/lib/rpm/Packages And this looks like an empty Packages file (it won't be 0 length, but it will be small, like < 10Kb). Is that the case? > D: pool tsi: reused 1, alloc'd 1, free'd 1 items. > D: pool ts: reused 0, alloc'd 1, free'd 1 items. > D: pool db: reused 0, alloc'd 1, free'd 1 items. > D: pool dbi: reused 0, alloc'd 1, free'd 1 items. > D: pool lua: reused 0, alloc'd 1, free'd 1 items. > D: pool mire: reused 0, alloc'd 1, free'd 1 items. > D: pool iob: reused 0, alloc'd 1, free'd 1 items. > D: pool fd: reused 15, alloc'd 2, free'd 2 items. > BTW, these are statistics for memory pool object reuse. RPM has 30-40 objects these days. 73 de Jeff > Silvan > > -- > mambaSoft di Calarco Silvan > Web: http://www.mambasoft.it > > mambaSoft Store @ http://www.mambastore.it > openmamba GNU/Linux development @ http://www.openmamba.org > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
