Can't update packages - what causes keyring corruption?

Hi :slight_smile:

A lot of people are having issues with the keychain. What causes this?
Is it file system corruption? Mis-use of pacman? A bad ordering of packages when upgrading?

One more concrete theory I have is that maybe if the internet connection is cut after downloading the packages, the install-scripts of the various *-keyring packages won’t be able to install the keys. And it appears they won’t try again when re-installing.

I’m asking about the “why” in being unable to verify package signatures and keyring failures.

I think, pacman-init should be recommended instead of running the individual commands surrounding pacman-key manually - mainly because that avoids the pitfall of not selecting the all the relevant keyrings.

To anyone trying to fix their system, give pacman-init a try (systemctl start pacman-init; depends on haveged for some reason).
If you prefer doing things manually, remember to include all keyrings for manjaro arm (pacman-key --populate archlinux archlinuxarm manjaro manjaro-arm) and try a different keyserver if gpg can’t find a specific key (gpg --keyserver keyserver.ubuntu.com ...).

The rest of this post is just what happened to me lately in the hope that the search will lead some people here and that maybe what worked for me works for them as well.


About a week ago, I was unable to run yay -Syu because of missing keys and unverifyable signatues and such.

I followed the instructions taken from here and here (populating with archlinux archlinuxarm manjaro manjaro-arm).

After that, one update worked. It needed several attempts, though.

A few days later, another update failed to verify the signature of libqofono-qt5 claiming it had been signed with a key of fkardame (I didn’t know he was signing packages for manjaro?).
Oh… and… pacman kept asking me to import the key of Philip Müller (interestingly, asking for a different key ID than the one stated in the other forum post, one started with 1B and one with 1D). It never installed anything regardless of whether I said yes or not.

When I retried the pacman keyring initialisation, it kept failing with a variety of funky errors.
Among those where gpg not reading from stdin, gpg failing to find a specific key, and lots of stuff like this:

gpg: key 786C63F330D7CB92: no user ID for key signature packet of class 10
...
gpg: keyserver receive failed: No name
...
gpg: trustdb: read failed (n=16): No such file or directory
...
==> ERROR: E4CDFE50A2DA85D58C8A8C70CAA6A59611C7F07E could not be locally signed.
gpg: error reading key: No public key

This is the last lines of output from pacman-key --populate:

  -> Disabled 45 keys.                                                             
==> Updating trust database...                                                                                                                                         
gpg: public key of ultimately trusted key 9824550F782D9DBB not found                                                                                                   
gpg: marginals needed: 3  completes needed: 1  trust model: pgp                                                                                                        
gpg: depth: 0  valid:   2  signed:  32  trust: 0-, 0q, 0n, 0m, 0f, 2u                                                                                                  
gpg: depth: 1  valid:  32  signed:  83  trust: 0-, 0q, 0n, 28m, 0f, 0u             
gpg: depth: 2  valid:  77  signed:  25  trust: 77-, 0q, 0n, 0m, 0f, 0u                                                                                                 
gpg: next trustdb check due at 2021-08-02                                          
==> ERROR: Trust database could not be updated.

At this point, I’m confused and paranoia starts setting in. Why were 45 keys disabled after a fresh initialisation? Why is the key ID different from the one in the forum?
I haven’t been able to cross-check philm’s key yet because i can’t find a page like the one from arch linux. I can only assume no one has taken over the mirrors and given me false pgp keys (which is ).

I was able to solve my problem by downloading the haveged dependency (pacman -S haveged) for pacman-init choosing not to delete the file because of a broken signature, extracting the files from the package manually (sudo tar -C / -xvf /var/cache/pacman/pkg/haveged.. /usr) and running systemctl start haveged and systemctl start pacman-init.
I had to start pacman-init a few times before it succeeded.
After that, I installed haveged properly to not have stray files in my system.

That’s quite an adventure. :wink:

As to why it happened, I’m not sure. Recently the archlinux-keyring and manjaro-keyring packages was updated. But so far only in Unstable branch.

The tip about pacman-init.service is a good one. It was used by manjaro-system package to regenerate the keys on a previous update. But I fear that the standard keyserver used in gnupg is having issues these days, which results in lots of errors when populating keys.

Forgot to mention: My phone is on stable.
It didn’t occur to me to look at whether there was a keyring change.
Maybe it could have been the scheduled local refresh? I don’t think I’ll be able to find out after clearing the pacman keyring multiple times.
I’ll be more catious next time!

Interesting!
PGP infrastructure…

I’ll test with and without that other keyserver in /etc/pacman.d/gnupg/gpg.conf when it happens again:

keyserver hkps://keyserver.ubuntu.com

Indeed.

This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected.

Update 2021-06-21 : Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.

https://sks-keyservers.net/

That’s a good alternative for now.