Qubes 4.2 archlinux can't update. pulseaudio, python, gpg errors

User Support
1

I’m a little at my wit’s end about this. But to summarize, I have 3 different problems when trying to update. Two are regarding mismatching dependencies, pulseaudio and python, the latter of which was fixed in 4.3 in github Qubes issue 10564 (noted in the forum post). However, it was not fixed in 4.2 and it will not be backported. I can’t seem to update to 4.3 because the qubes-dist-upgrade tool crashes at step 1 because arch doesn’t update due to errors. I can’t update arch without updating qubes first, and i can’t update qubes without updating arch first. A real catch 22.
Anyways, I initially received the pulseaudio error in December 2025, and was able to bypass it by adding --ignore pulseaudio,libpulse to the pacman command, generally hoping for the issue to resolve itself in the future. When I started receiving the python error last week, I planned to do the same and ignore it, but I started getting the third error, now regarding PGP keys.

error: qubes-r4.2-current-testing: key "E5001C1D49BE9129DEEC06284C6270146C463D90" is unknown
:: Import PGP key E5001C1D49BE9129DEEC06284C6270146C463D90? [Y/n] 
error: key "E5001C1D49BE9129DEEC06284C6270146C463D90" could not be looked up remotely
error: qubes-r4.2-current: key "E5001C1D49BE9129DEEC06284C6270146C463D90" is unknown
:: Import PGP key E5001C1D49BE9129DEEC06284C6270146C463D90? [Y/n] 
error: key "E5001C1D49BE9129DEEC06284C6270146C463D90" could not be looked up remotely
error: failed to synchronize all databases (unexpected error)

So I assumed this to be an issue with an outdated keyring, so I ran the following.

pacman -Sy archlinux-keyring 
pacman-key --init 
pacman-key --populate archlinux 
pacman-key --refresh-keys

The last command, --refresh-keys, spat out hundreds of lines of error messages about failed keyserver refresh. Here is a snippet

==> ERROR: Could not update key: 19802F8B0D70FC30
gpg: error retrieving 'thomas@bchlr.de' via WKD: Server indicated a failure
gpg: error reading key: Server indicated a failure
gpg: error retrieving 'thomas.baechler@gmx.de' via WKD: Server indicated a failure
gpg: error reading key: Server indicated a failure
gpg: error retrieving 'thomas@archlinux.org' via WKD: Server indicated a failure
gpg: error reading key: Server indicated a failure
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: keyserver refresh failed: Server indicated a failure
==> ERROR: Could not update key: 284FC34C8E4B1A25
gpg: error retrieving 'rgacogne@archlinux.org' via WKD: Server indicated a failure
gpg: error reading key: Server indicated a failure

Then I realized that I also probably had to update the qubes-vm-keyring, upon which I got the same error from earlier about the one PGP key not being able to be looked up remotely.

error: qubes-r4.2-current: key "E5001C1D49BE9129DEEC06284C6270146C463D90" is unknown
:: Import PGP key E5001C1D49BE9129DEEC06284C6270146C463D90? [Y/n] 
error: key "E5001C1D49BE9129DEEC06284C6270146C463D90" could not be looked up remotely
error: database 'qubes-r4.2-current' is not valid (invalid or corrupted database (PGP signature))

This E5001C1D49BE9129DEEC06284C6270146C463D90 is the same key from earlier and seems to be problematic. However, upon looking it up manually, I couldn’t actually find it in any keyservers.
So that’s where I’m at and I’m not sure what exactly the root cause of the PGP problems is here or how to resolve it.

2

Hello @archuser1234 ,
I’m also using ArchLinux but presently with QubesOS 4.3.

Why not upgrading to 4.3 with a new install (clean installation in the Qubes-OS documentation), then restore your backups. I did all my upgrades with this procedure since Qubes-OS 4.0. But first you should verify and trust your backups!

Then later install the ArchLinux 4.3 reference template.

The keyring problem is a common issue with ArchLinux with low frequency updates, see the ArchLinux wiki and forums. With a daily update, I see this problem each 2-3 months :frowning: but I always resolved it.

I update my ArchLinux templates each days. I secure this with a weekly hot backup (qvm-clone <myTemplate> <myBackupTemplate>) and a weekly cold backup (with qubes-backup).

3

See also the 9th comment from :

4

Hello,
Thank you for your reply. I have the resources to back up my installation and do a clean install. I think there’s still a small chance that sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade won’t fix all of the repo errors, but I will try it and will post an update if anything goes wrong.

1 Like