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
5

Hey so it sort of worked. This is OP but I had to make another account for reasons I will describe here. So the upgrade seemed to work, it imported the old qubes and I ran the little command to update them. I then removed the duplicate qubes and kept the ones that I wanted. However, dom0 was the only qube that didn’t seem to be imported from the backup. I know it’s bad practice, but I stored the credentials to archuser1234 in a textfile in dom0 because I intended for it to only be a temporary account. But other than my old dom0, the whole upgrade process seemed to work fine.
Okay, so the arch errors. Upgrading unfortunately didn’t fix the arch errors. At this point I think I’ll just download the new template, install the same things, and then switch the appqubes to use the new template instead. I will post again to confirm that that works.
But if anyone has any idea how to get the old dom0 back PLEASE reply. Thanks.
(apologies for the delay, I had other things which prevented me from posting at that time)

6

see the home-restore-<date> directory in your current dom0 home directory, it’s the restore place for the restored dom0 home (/home/user/home-restore-<date>/dom0-user/user/).
Source : Search home-restore in this forum, and read the below reference documentation (the restore Note: section):

It was my initial advice. And don’t forget to switch the new template to the current-testing repository:

[root@archlinux-43 ~]# ls -al /etc/pacman.d/85-qubes-current-testing.conf
lrwxrwxrwx 1 root root 38 Oct  1 21:52 /etc/pacman.d/85-qubes-current-testing.conf -> 85-qubes-current-testing.conf.disabled

The good practice is to use the vault qube.