Maybe I should add that the issue appeared with a recent Tumbleweed update. I didn’t change any repos previously since months.
I can activate also temporarily only the officially supported software package repositories. But I wonder still why the signature checks fail with a strange message.
I hope that the clarification of this technical annoyance can become more constructive.
Thanks for your additional information.
Any ideas how I can fix it?
I am still looking for a solution.
Which software components can trigger a signature check failure here?
My software update experiences might be similar in this case. How should the involved components become consistent again?
You have been asked to provide output / info, which has been ignored/refused so far. That leaves those trying to help without the info needed to help, which makes any statement a shot in the dark based on nothing but belief. And that is not what we’re here for. My 2 cents.
Would you like to take a response from the user “cfeck” into account then for the desired clarification of a questionable software situation?
Hi
I’ve yet to see the requested information posted… as explained, it’s hard to help diagnose issues;
rpm -qa |grep pubkey
@elfring and cfeck, please provide above info…
How much can the following data help?
elfring@Sonne:~> rpm -qa|grep pubkey|sort
gpg-pubkey-05905ea8-58932fa5
gpg-pubkey-0d210a40-581257c6
gpg-pubkey-0f2672c8-5924b423
gpg-pubkey-17280ddf-5a631c69
gpg-pubkey-1abd1afb-54176598
gpg-pubkey-233ab63d-5899991c
gpg-pubkey-307e3d54-4be01a65
gpg-pubkey-324e6311-578e3afa
gpg-pubkey-32567f38-5492e4d7
gpg-pubkey-367fe7fc-588f5460
gpg-pubkey-3dbdc284-53674dd4
gpg-pubkey-3f882d82-587394ea
gpg-pubkey-498d5a23-593bd7b8
gpg-pubkey-5abb3cd0-4c61961d
gpg-pubkey-5fd803b8-57fe8cd6
gpg-pubkey-629ff0c2-578df563
gpg-pubkey-6ba6c051-58fe032a
gpg-pubkey-6f88bb2f-4fe5b9a8
gpg-pubkey-72db573c-4da468cb
gpg-pubkey-766da614-58aee216
gpg-pubkey-98c4529d-578c9204
gpg-pubkey-c0951497-53515432
gpg-pubkey-c2c0e8d4-5931bd76
gpg-pubkey-c66b6eae-4491871e
gpg-pubkey-c862b42c-57a2e70b
gpg-pubkey-c8da93d2-5a099d2c
gpg-pubkey-d15ee595-582c900c
gpg-pubkey-eafffe6c-54201922
gpg-pubkey-fd09be7d-57b8e25f
Do you find the error message “… is signed with an unknown key ‘’.” also strange?
Hi
So, seems like you have a lot of keys and some may be duplicate and out of date, easiest way is to fire up YaST -> Software repositories and bottom right hand side, select the gpg keys button, clean out the cruft (old, not used, out of date) and see how that goes.
29 keys were integrated as usual for a while.
…, clean out the cruft (old, not used, out of date) and see how that goes.
Why should such a change help finally?
Have you got any more insights to offer for the error message “… is signed with an unknown key ‘’.”?
I guess that a bit more information should usually be displayed in this case between the apostrophes. :\ Are you concerned that the data processing resulted in an empty string there?
Hi
I think it’s an old/expired key, or are all the ones listed current? I have the following;
rpm -qa|grep pubkey|sort
gpg-pubkey-307e3d54-5aaa90a5 - SUSE package key
gpg-pubkey-39db7c82-5847eb1f - SUSE package key
gpg-pubkey-3dbdc284-53674dd4 - openSUSE Project key
I only have oss, oss-update repos and a local repo.
If you use some verbosity to zypper ref it will show the keys being used;
zypper -v ref -f
Do I need to reinstall any keys so that I see also a description for them there?
If you use some verbosity to zypper ref it will show the keys being used;
zypper -v ref -f
The corresponding file retrieval is still working also on my system while all signature checks fail somehow.
Hi
So the rpm output does not match the list you see in YaST?
If you delete via YaST and the repository is enabled, it will ask to accept the key again on a zypper ref…
Thank you. I deleted all expired keys via YaST, and now it works. Those keys were from repositories I no longer use, worth a bug report?
I do not interpret my software situation in this direction.
Did you add any descriptions to your listing of installation keys manually?
If you delete via YaST and the repository is enabled, it will ask to accept the key again on a zypper ref…
The signature checks continue to fail here.
Hi
So according to your information from the rpm output you have twenty (29) repositories enabled in Tumbleweed?
Maybe try rebuilding the rpm database and see if that helps to clean up any keys;
rpmdb --rebuilddb
Yes I added the key descriptions to my rpm query output to clarify what those ones were for you.
Again, in YaST select each key and look at the expiry date, if any are out of date delete them.
Possibly, lets see how user elfring goes…
So how many repositories did you have inactive? Did you set any repository priorities, or used the default of 99?
No.
But it can be that there is information for a similar number of installation sources still managed here.
Yes I added the key descriptions to my rpm query output to clarify what those ones were for you.
Thanks for this information. - This detail can cause confusion when it did really not belong to the original command display.
Again, in YaST select each key and look at the expiry date, if any are out of date delete them.
I would find it very strange if the signature checking software would get confused by expired keys when the required ones can always be loaded on demand.
Most (temporarily) from my software selection.
Did you set any repository priorities, or used the default of 99?
Both. - The system configuration evolved as usual through the years.
Hi
So are you using mirrorbrain (download.opensuse.org) or a specific mirror on some of those repositories, if using a mirror it maybe out of date.
Yes, until the signature checks failed somehow.
How much will this influence the desired clarification of the software situation?