Opened 5 years ago

Last modified 3 months ago

#117 new defect

Rpmdb checksum is invalid: dCDPT(pkg checksums)

Reported by: guzzi Owned by:
Priority: minor Milestone:
Component: rpm Version:
Severity: low Keywords:
Cc:

Description

After installing clamav I got error

Warning: RPMDB altered outside of yum.
Rpmdb checksum is invalid: dCDPT(pkg checksums)

Yum still functions and I can install other packages, but the error now comes back with every install. rpm --rebuilddb does not fix it.

Change History (21)

comment:1 Changed 5 years ago by guzzi

  • Priority changed from major to minor

comment:2 Changed 5 years ago by David McKenna

'yum clean rpmdb' got rid of this error for me.

comment:3 Changed 5 years ago by guzzi

It didn't for me.

comment:4 Changed 5 years ago by ydario

It seems related to some kind of rpm database corruption or duplicate entries. Try

rpm -qa "*clam*"

and see if you have duplicate entries.
Maybe also 'rpm --rebuilddb' could help.

comment:5 Changed 5 years ago by guzzi

No duplicates. rpm --rebuilddb doesn'fix it.

comment:6 Changed 5 years ago by Lewisr

I am seeing this as well, in two different VMs, since upgrading rpm to 4.8.1-22. 4.8.1-20 does not seem to exhibit this behavior (unzipping 4.8.1-20 over an installed 4.8.1-22 results in clean installs without the error). Unfortunately, I can't find a good way of rolling back via yum from 4.8.1-22, as yum downgrade fails with a number of dependencies (including gcc-4.9.2.1-3).

comment:7 Changed 4 years ago by lewisr

  • Severity set to low

This has bubbled up to the surface for me again, as we're readying YUMIE for release.

Interestingly, from @unixroot/var/lib/rpm, I ran:

ren Packages Packages.bak
db_dump Packages.bak | db_load Packages
rpm --rebuilddb

The resulting rebuilt Packages db is considerably slimmer than the previous one:

11-19-15  18:40       3,162,112    124  Packages
 9-26-15   8:55       3,440,640    124  Packages.bak

I'm still seeing the error message during an update operation, but not during install or remove (multiple packages, via yum).

comment:8 Changed 3 years ago by diver

  • Summary changed from installing clamav gives Rpmdb checksum is invalid: dCDPT(pkg checksums) to Rpmdb checksum is invalid: dCDPT(pkg checksums)

I changed the Summary, as this is a general issue and has nothing to do with clamav. Clamav just triggered it for the reporter the first time.

comment:9 Changed 3 years ago by diver

http://trac.netlabs.org/rpm/browser/yum/trunk/yum/rpmsack.py line 706 rises this error. Do we have some debug flags activated?

comment:10 Changed 3 years ago by diver

in https://github.com/rpm-software-management/yum/commit/bf106ce30a198f32f43d14041d808b60f9e6719e#diff-54c87c0b8b359850b7c3cfec40445626 the fix is present. I added it locally and see no more issues. Dmik also has my rpmsack.py and does some additional testings

comment:11 Changed 3 years ago by ydario

yum: fix (from upstream) epoch handling in package match. Fixes ticket#117.
Committed revision r1018.

comment:12 Changed 3 years ago by dmik

Note that I still get this:

Rpmdb checksum is invalid: dCDPT(pkg checksums): coreutils-common.i686 0:8.26-2 - u

sometimes. So this fix doesn't actually remove this message it makes it more verbose. Perhaps it's also related to the fact that the Rpmdb was touched outside yum (i.e. by rpm directly). The question is how to get rid of such messages. Sometimes yum clean all helps but not always it seems.

comment:13 Changed 3 years ago by diver

this is all a yum issue. and yum got several hundreds fixes, but no new release. when time permits, we might update to latest yum git head.

comment:14 Changed 3 months ago by diver

this can be worked around by setting the debuglevel to 0 in /etc/yum/yum.conf

comment:15 Changed 3 months ago by lewisr

Set debuglevel to 0 in /etc/yum/yum.conf.

[n:\] yum update os2-rpm

worked as expected (after confirming update, returned to prompt with no further output). Then:

[n:\] yum update sed

produced:

Rpmdb checksum is invalid: dCDPT(pkg checksums): sed.i686 0:4.7-1.oc00 - u

so it looks like debuglevel=0 is not a comprehensive workaround.

Last edited 3 months ago by lewisr (previous) (diff)

comment:16 Changed 3 months ago by diver

I hate it when documentation is wrong. as this message is only spit when debug value is set. So it must be set anyway somehow. So we have to live with it further. As I have no time to debug when this value is set and why.

comment:17 Changed 3 months ago by diver

I added some debug locally, but until now i'm not able to trigger it.

comment:18 Changed 3 months ago by diver

ok I found something eventually. please test it

in /usr/lib/python2.7/site-packages/yum/rpmsack.py search for

#YD already root based
self._cachedir = cachedir + "/installed/"

and change that to

#YD already root based
#self._cachedir = cachedir + "/installed/"
self._cachedir = cachedir

This installed part is not used since yum 3.4.1 when I read the code right. And I could downgrade and update several packages in a row w/o issues. Before this did not work.

comment:19 Changed 3 months ago by lewisr

Sorry, not working here.

I made the change as described, and then attempted to update whois from the root directory. The error message presented itself.

Same error when downgrading.

Also, the installed directory is indeed used. It is emptied at the conclusion of a transaction, but with DELDIR enabled, it is possible to list the files which were removed from the installed directory (%UNIXROOT%\var\lib\yum\rpmdb-indexes\installed).

Perhaps looking down closer to line 688 (def _deal_with_bad_rpmdbcache) might produce some clues as to what is triggering this (or line 369).

I haven't spent enough time with the script to fully understand all that is happening in it, but maybe you'll catch something.

Last edited 3 months ago by lewisr (previous) (diff)

comment:20 Changed 3 months ago by diver

The installed dir is not used at all if you changed all right. And i cant trigger it anymore with the changes.

comment:21 Changed 3 months ago by diver

ok today I got it as well again. I give up on this for now, as I have really no time. I might look at it again but for sure not before the end of August.

Note: See TracTickets for help on using tickets.