Wrong dependence?

Hello,

In an attempt to remove devel packages (installed only for building purposes) I’ve found I can’t remove

lib64gcrypt-devel

$ urpme lib64gcrypt-devel
Removing the following package will break your system:
basesystem-3-0.1-omv2015.0.x86_64
(due to missing kernel)

Why? If it was not installed before why can’t I remove it now?

In fact,

$ rpm -q --what-requires lib64gcrypt-devel
no package requires lib64gcrypt-devel

https://openmandriva.pkgs.org/3.0/openmandriva-main-updates-x86_64/lib64gcrypt-devel-1.7.6-1-omv2015.0.x86_64.rpm.html

maybe your rpmdb is corrupted

Well, I was wrong when I said the package lib64gcrypt-devel was not installed.

I have two openmandriva installations. Both return,

$ rpm -q --what-requires lib64gcrypt-devel
no package requires lib64gcrypt-devel

Please what does this command returns for you? If you get different result, how do I rebuild openmandriva database?

thanks

# db52_recover -h /var/lib/rpm -ev

# rpm -vvv --rebuilddb

Edit: I doubt this will change anything as far as that package. Also I suspect that TPG will get same result from the command used below. Based on my results in a very fresh install from ISO 1298 yesterday. Same as you get:

$ rpm -q --what-requires lib64gcrypt-devel
no package requires lib64gcrypt-devel

2nd Edit: Rebuilding rpm database won’t hurt anything though.

There are some instructions here.

I’m still curious about dependences in openmandriva LX 3. I’ve followed the steps,

$ rm -f /var/lib/rpm/__db*
$ rpm --rebuilddb

and nothing has changed. For instance, I cannot uninstall the package,

lib64png-devel-1.6.31-1-omv2015.0.x86_64

because many other packages would have to be uninstalled as well despite the command

$$ LC_ALL=C rpm -q --what-requires lib64png-devel-1.6.31-1-omv2015.0.x86_64
no package requires lib64png-devel-1.6.31-1-omv2015.0.x86_64.

What seems strange is the fact that rebuilddb never ends.

I was checking for the size of __db files until they did not get bigger anymore. Although all __db files stopped growing, rebuilddb did not end!

rpm --rebuilddb

rpmdb: BDB0113 Thread/process 18236/140514524972864 failed: BDB1507 Thread died in Berkeley DB library
error: db_init:db3.c:1190: dbenv->failchk(-30973): BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
Re-opening dbenv with DB_RECOVER …
BDB2526 Finding last valid log LSN: file: 217 offset 9004886
recovery 33% completeBDB1514 Recovery starting from [217][4630534]
recovery 100% completeBDB1518 Recovery complete at Tue Aug 1 22:21:21 2017
BDB1519 Maximum transaction ID 80012565 recovery checkpoint [217][9005458]
.
recovery succeeded.

Sorry, It was not correct to say that __db* files stopped growing. They are growing but size updates are being done after longer periods …

Still tying,
meanwhile, this are the error messages I’m getting when I try to rebuild database,

rpm --rebuilddb
rpmdb: BDB2055 Lock table is out of available lock entries
error: db3associate:db3.c:1674:
db->associate(12): Cannot allocate memory

I would like to know if something is wrong and what is wrong. Please, if somebody knows let me know…

I still can’t remove package lib64png-devel because 19 packages would have to be removed as well. However,

LC_ALL=C rpm -q --what-requires lib64png-devel-1.6.31-1-omv2015.0.x86_64

no package requires lib64png-devel-1.6.31-1-omv2015.0.x86_64

I tried rebuilding data base after removing all __db* files from /var/lib/rpm and got the errors I’ve reported in the last post. I also tried rebuilding data base after,

db52_recover -h /var/lib/rpm -ev

BDB2526 Finding last valid log LSN: file: 290 offset 1743047
BDB1518 Recovery complete at Wed Aug 2 18:26:26 2017
BDB1519 Maximum transaction ID 0 recovery checkpoint [290][1745403]

and got different __db files. Without db52_recover, I used to have

$ ls -al /var/lib/rpm/__*
-rw-r–r-- 1 root root 4145152 ago 2 08:22 /var/lib/rpm/__db.001
-rw-r–r-- 1 root root 22290432 ago 2 08:22 /var/lib/rpm/__db.002
-rw-r–r-- 1 root root 41951232 ago 2 08:22 /var/lib/rpm/__db.003
-rw-r–r-- 1 root root 41951232 ago 2 08:22 /var/lib/rpm/__db.004
-rw-r–r-- 1 root root 41951232 ago 2 08:22 /var/lib/rpm/__db.005
-rw-r–r-- 1 root root 41951232 ago 2 08:22 /var/lib/rpm/__db.006

And with db52_recover the rebuilding process generated only,

$ ls -al /var/lib/rpm/__*
-rw-r----- 1 root root 2072576 ago 2 18:28 /var/lib/rpm/__db.001
-rw-r----- 1 root root 32768 ago 2 18:28 /var/lib/rpm/__db.002
-rw-r----- 1 root root 270336 ago 2 18:28 /var/lib/rpm/__db.003

Finally, the output the following command has the same error messages as before but ends with exit code 0 (???)

rpm -vvv --rebuilddb

D: pool fd: created size 392 limit -1 flags 0
D: pool ds: created size 232 limit -1 flags 0
D: pool syck: created size 40 limit -1 flags 0
D: pool ht: created size 72 limit -1 flags 0
D: pool mire: created size 136 limit -1 flags 0
D: pool lua: created size 64 limit -1 flags 0
D: pool ts: created size 1200 limit -1 flags 0
D: pool db: created size 328 limit -1 flags 0
D: pool dbi: created size 472 limit -1 flags 0
D: rpmdb: cpus 4 physmem 5915Mb
D: opening db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn
D: opening db index /var/lib/rpm/Packages create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Name create:thread:auto_commit mode=0x2
D: pool h: created size 360 limit -1 flags 0
D: opening db index /var/lib/rpm/Version create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Release create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Arch create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Os create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Basenames create:thread:auto_commit mode=0x2
D: pool bf: created size 56 limit -1 flags 0
D: opening db index /var/lib/rpm/Group create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Providename create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Requirename create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Conflictname create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Obsoletename create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Triggername create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Dirnames create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Installtid create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Sigmd5 create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Sha1header create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Filedigests create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Pubkeys create:thread:auto_commit mode=0x2
D: pool ctx: created size 112 limit -1 flags 0
D: opening db index /var/lib/rpm/Packagecolor create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Nvra create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Sourcepkgid create:thread:auto_commit mode=0x2
D: opening db index /var/lib/rpm/Filepaths create:thread:auto_commit mode=0x2
rpmdb: BDB2055 Lock table is out of available lock entries
error: db3associate:db3.c:1674: db->associate(12): Cannot allocate memory
D: rpmdb: max. primary key 12197
D: opening db index /var/lib/rpm/Seqno create:thread:auto_commit mode=0x2
D: closed db seqno /var/lib/rpm/Seqno
D: closed db index /var/lib/rpm/Seqno
D: closed db index /var/lib/rpm/Filepaths
D: closed db index /var/lib/rpm/Sourcepkgid
D: closed db index /var/lib/rpm/Nvra
D: closed db index /var/lib/rpm/Packagecolor
D: closed db index /var/lib/rpm/Pubkeys
D: closed db index /var/lib/rpm/Filedigests
D: closed db index /var/lib/rpm/Sha1header
D: closed db index /var/lib/rpm/Sigmd5
D: closed db index /var/lib/rpm/Installtid
D: closed db index /var/lib/rpm/Dirnames
D: closed db index /var/lib/rpm/Triggername
D: closed db index /var/lib/rpm/Obsoletename
D: closed db index /var/lib/rpm/Conflictname
D: closed db index /var/lib/rpm/Requirename
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Group
D: closed db index /var/lib/rpm/Basenames
D: closed db index /var/lib/rpm/Os
D: closed db index /var/lib/rpm/Arch
D: closed db index /var/lib/rpm/Release
D: closed db index /var/lib/rpm/Version
D: closed db index /var/lib/rpm/Name
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm/Packages
D: pool tsi: created size 48 limit -1 flags 0
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 ds: reused 78, alloc’d 2, free’d 2 items.
D: pool db: reused 0, alloc’d 1, free’d 1 items.
D: pool dbi: reused 0, alloc’d 24, free’d 24 items.
D: pool h: reused 130021, 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 bf: reused 29339, alloc’d 1, free’d 1 items.
D: pool ht: reused 0, alloc’d 25, free’d 25 items.
D: pool ctx: reused 0, alloc’d 1, free’d 1 items.
D: pool syck: reused 0, alloc’d 1, free’d 1 items.
D: pool fd: reused 48, alloc’d 2, free’d 2 items.
D: exit code: 0

No, nothing is wrong. ‘db52_recover -h /var/lib/rpm -ev’ results are normal. ‘rpm -vvv --rebuilddb’ results are also normal.

If it ain’t broke don’t fix it.

Post Edit: Looks like ben79 made a boo boo. See next post below.

As I understand it rpm will create the _db files as and when it needs them.

I missed this, honestly I don’t know if this is or isn’t a problem but it looks like something wrong. And it looks like my last post above was incorrect. When I run this command I do not get this error.

As I understand it this is good as in 0 problems. Bad would be if there was a number other than 0. Again that’s as I understand it.

What you can do is do an internet search (ie. Google) of the actual error and see what comes up. From what I see it tells us to remove all _db files and ‘rpm -vvv --rebuilddb’.

The -vvv just means verbose X 3 hence you get extra output. Does not change at all what rpm is doing.

Yes, the point is that I’ve already done this with the same output of error messages.

There seems to be a great update. One of my computers already got these updates. This one, with this possible database problem, has not received updating annoucements yet. I’ll wait to see what will happen when this updates are available for this computer.

Thanks a lot.

I cannot install anything. For instance,

urpmi plib-devel

installing plib-devel-1.8.5-7-omv2015.0.x86_64.rpm a partir de /var/cache/urpmi/rpms
Preparing… ###############################################################
1/1: plib-devel ###############################################################
rpmdb: BDB2055 Lock table is out of available lock entries
error: db3associate:db3.c:1674: db->associate(12): Cannot allocate memmory
rpmdb: BDB2055 Lock table is out of available lock entries
error: cannot open Packagecolor(1184) index: Cannot allocate memmory(12)
DB: Berkeley DB 5.2.42: (February 29, 2012)

All sites I’ve seen recomend rebuilding data base after removing __db* files. But I get errors even when rebuilding data base. Still searching. For now I’ve found something different to try:

rpm --verify --all

which, I guess, is supposed to find inconsistencies on the data base (broken rpms(?), …)

Could it be that some temporary file is still there (at /var/lib/rpm) and be the cause for this problem?

I cannot verify it just now but in another computer (RHEL 6.5) there is a .rpm.lock file with size 0.

Thanks

It seems to be the end of this installation. I cannot fix the database with rpm --rebuilddb, I also cannot install anything else like the package lib64db2-devel to have commands like,

db2-load and db2-dump

for checking and correcting the file Packages at /var/lib/rpm

so don’t know what else I could do!

This file does not exist in my /var/log/rpm. So try moving it or renaming it.

Thanks Ben79.

The database was badly altered by my several attempts to fix the problem.

I possbly got into troubles when I CRTL+C when the command “rpm --rebuilddb” because it was taking so long. After that, I was no longer able to correct anything.

I’ve reinstalled the system with OMV LX 3.02 downloaded from sourceforge. Now I’m still installing/configuring everything to let the system as it used to be before the database problem.

Yep, that would do it. That’s a command that must not be interrupted.