Hi everybody! Today I was investigating a problem that I have on my home pc since a few months.
The problem is that zypper repeatedly asks me to confirm repository signing keys even if I already told it to trust the key always.
I found a lot of threads with similar problems, which led me investigating zypper, gpg and rpm.At one point, I found out that my rpm db is corrupted, because when I enter ‘rpm -qa gpg-pubkey*’ this is what I get:
Besides the fact that there are a lot of duplicated entries (I don’t know if it’s normal), there is that ugly error that asks for immediate action.
So I took a backup of the rpm db and then issued ‘sudo rpm -vv --rebuilddb’, which gave me this (snipped):
(...)
Header SHA1 digest: OK
D: adding "bison" to Name index.
D: adding 53 entries to Basenames index.
D: adding "Development/Languages/C and C++" to Group index.
D: adding 17 entries to Requirename index.
D: adding 2 entries to Providename index.
D: adding 15 entries to Dirnames index.
D: adding 1 entries to Installtid index.
D: adding 1 entries to Sigmd5 index.
D: adding "71bc5f24969fabf4a56f13f92b3c9f7968f2fe1c" to Sha1header index.
D: adding 1 entries to Recommendname index.
D: read h# 64697
Header SHA1 digest: BAD (Expected bf167126ecaa67d16fee74af17096529278aad8d != cd4a91ad1f0d65d360cce5dacffea553e358b550)
error: cannot add record originally at 64697
D: closed db index /usr/lib/sysimage/rpm/Packages
D: closed db environment /usr/lib/sysimage/rpm
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Packages
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Enhancename
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Supplementname
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Suggestname
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Recommendname
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Transfiletriggername
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Filetriggername
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Sha1header
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Sigmd5
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Installtid
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Dirnames
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Triggername
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Obsoletename
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Conflictname
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Providename
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Requirename
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Group
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Basenames
D: closed db index /usr/lib/sysimage/rpmrebuilddb.21797/Name
D: closed db environment /usr/lib/sysimage/rpmrebuilddb.21797
warning: failed to rebuild database: original database remains in place
So, I don’t know if this is the root cause of my problems with zypper, but it is nevertheless something that has to be dealt with.
Given the fact that rpm itself hasn’t been able to fix the situation, what possibilities do I have to fix the problem?
Thank you for your suggestion. Unfortunately Yast only shows me a handful of keys (6 IIRC, I’m not on the faulty box right now) and it shows no error.
The same happens if I issue this at the cli:
rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SUMMARY}
’
It will show just 5 or 6 keys with no error.
I’m lost
Anybody else has any idea of how to fix this, short of reinstalling?
Sorry but you have the fingerprint that gives you error, identify it between the keys and delete it, close and restart yast, which will ask you to accept the new Repo footprint
You should be able to delete them with something like this:
rpm -e --allmatches gpg-pubkey-df7587c3-576a5c23
But, do you actually have any problem because of the “duplicated” keys?
If not, I see no reason to reinstall either…
And I do have duplicates here on my system as well, although everything works fine AFAICT.
If the rpm database is corrupted, you could try to run “rpm --rebuilddb” to hopefully fix it.
“rpm --reinitdb” will create a new, empty, one that would also “fix” the duplicated keys, but it would also lose track of what packages are installed of course.
PS: In my case the key for KDE:Extra is installed multiple (about 60+) times.
That’s probably related to the bug that caused libzypp to “forget” the repo key (triggered by PackageKit) and asking to accept it again and again. (which happened especially with that particular repo for me)
I just had a look at libzypp’s changelog (on Leap 42.3) and found this that sounds related:
* Tue Jan 16 2018 ma@suse.de
- Fix deleted keys not removed from rpmdb too (bsc#1075449)
- version 16.17.9 (0)
I.e. apparently zypper/libzypp did not remove keys from the rpm database until recently due to a bug.
Well, not exactly.
I am investigating a problem where zypper insists telling me that it received a new repository or package signing key, asking me to validate it each time, even though I have told it to always trust the key a zillion times.
While investigating on this problem, I noticed the error and the duplication. I don’t know if the duplication is malign, it just stroke me as something weird. And since I also have a db corruption problem, I thought the two were related.
Unfortunately, as you can read in my OP, that command failed in fixing my rpm db :(.
Hey, this is exactly what is happening to me!!
But, despite repeated googling I failed to find a related bug!! Do you have the number? Is it fixed now?
The strange thing is that I only have it on one PC, the other one seems immune.
I am still seeing the problem, though. Had it just five minutes ago when I ran ‘zypper dup’… I had to trust (again) the key for 4 repos.
I tried this command with the key identified by the error message (gpg-pubkey-3dbdc284-53674dd4).
I can verify that the key is not present anymore, but I still have the error when I run ‘rpm -qa gpg-pubkey*’.
I’d need to search for the bug report, but that probably wouldn’t help you. It was about PackageKit causing repo keys to get invalidated when it looked for updates (the bug was actually in libzypp), which made it necessary to accept them again and again.
It’s fixed since nearly a year though, and I haven’t had the problem a single time since then. Also, there were a couple of forum threads about it back then, and new ones ceased to appear since then either.
Yeah, I did not see that error message “hidden” in the rest of the output before.
Well, your database is indeed corrupted.
If “rpm --rebuilddb” doesn’t fix it, the only option I see is start fresh with a clean one (rpm --reinitdb) and reinstall all packages I’m afraid.
The rpm database is a standard Berkely DB though, maybe there tools/ways to fix it but I cannot help there.
You won’t see the error fixed yet on your system, Wolfi said he found the issue possibly addressed on 42.3 and you’re on TW.
BTW -
I found it curious that your rpm database is so complex with so many indexes…
I checked on one of my own TW which is nearly a default install and it only has 2 indexes (Packages and Names) and 2 gpg-pubkeys(I haven’t verified, but I’m guessing that means that more than one TW repo may be signed with the same pubkey).
I guess your long list of indexes are due to your many OBS repos which possibly have packages under development with frequent changes…
Actually the issue was in 42.2, it was fixed already when 42.3 was released.
And of course it is fixed on TW too, since about a year as I wrote.
I found it curious that your rpm database is so complex with so many indexes…
I checked on one of my own TW which is nearly a default install and it only has 2 indexes (Packages and Names)
???
From my 42.3 system:
$ ls /var/lib/rpm
alternatives Dirnames Name Providename Sha1header
Basenames Group Obsoletename Pubkeys Sigmd5
Conflictname Installtid Packages Requirename Triggername
And that’s the norm.
Everything except Packages can be recreated automatically (from Packages), and that’s exactly what “rpm --rebuilddb” does.
In the OP’s case, it seems that Packages itself is corrupt though.
and 2 gpg-pubkeys(I haven’t verified, but I’m guessing that means that more than one TW repo may be signed with the same pubkey).
I guess your long list of indexes are due to your many OBS repos which possibly have packages under development with frequent changes…
The number of indexes has nothing to do with the number of repos.
The number of gpg-keys of course does, because usually each repo has its own key.
Hm, I don’t see how this would magically fix a corrupted rpm database though… :\
It would of course help if you encounter some bug that’s already fixed, but the fix is not in the standard repos yet.
That’s not really the case here though AFAICT.
