During update of my system using pacman -Syu I get the following errors:
error: intel-gmmlib: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/intel-gmmlib-22.9.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: intel-graphics-compiler: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/intel-graphics-compiler-1:2.27.10-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: intel-compute-runtime: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/intel-compute-runtime-26.01.36711.4-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.
I tried quite a few things, but unfortunately nothing solved the issue. Here is a list of things I tried in no particular order:
I’m curious because in my not-yet-downgraded keyring (20260206-1), dbermond is listed as [ full ], while the other recently problematic keys (anatolik, morganamilo, shibumi) all show [marginal].
In this case, I think order matters. I would recommend
sudo pacman -S highway libjxl libvpl vmaf
resolving dependencies...
looking for conflicting packages...
Packages (5) gperftools-2.17.2-1 highway-1.3.0-1 libjxl-0.11.1-5 libvpl-2.16.0-1 vmaf-3.0.0-1
Total Installed Size: 28.97 MiB
:: Proceed with installation? [Y/n] y
(5/5) checking keys in keyring [############################################################################################] 100%
(5/5) checking package integrity [############################################################################################] 100%
error: highway: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/highway-1.3.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: libjxl: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/libjxl-0.11.1-5-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: libvpl: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/libvpl-2.16.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: vmaf: signature from "Daniel Bermond <dbermond@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/vmaf-3.0.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.
pacman-key -l dbermond@archlinux.or
gpg: Note: trustdb not writable
pub rsa2048 2016-06-27 [SC]
3FFA6AB7B69AAE6CCA263DDE019A7474297D8577
uid [ unknown] Daniel Bermond <danielbermond@gmail.com>
uid [ unknown] Daniel Bermond <dbermond@archlinux.org>
sub rsa2048 2016-06-27 [E]
pub ed25519 2021-10-30 [SC] [expires: 2026-10-29]
80247D99EABD3A4D1E3A1836E85B8683EB48BC95
uid [marginal] Daniel Bermond <dbermond@archlinux.org>
sub cv25519 2021-10-30 [E] [expires: 2026-10-29]
Trying to force remove those and their dep’s actually bricked my system.. This IMPOV show’s a bit the type of things users are going through when the pacman subsystem goes downhill.
I’m mostly replying, as I want to know more. The above got marked as the solution.
Isn’t this actually just a hack? (With a chance of backfiring if you don’t --delete it next update. As maintainers always change.)
And isn’t there an additional security risk, for a chunk of the actual official repository? And you hope you’re okay until `archlinux-keyriung’ gets a higher version?
And you still have that local exception lingering, if you didn’t delete that key.
(These are all questions which were just my assumptions.)
Aren’t all the steps around this one, the correct way?
It probably did not work because of some undeleted cache.
This is indeed a workaround.
Bermond has 3 keys. So far the packages were only signed with one of them. In the old version of keyring this one was trusted, the other 2 not. In the February version of the keyring it was the other way around which broke the older packages.
Now for me, there are still questions open, and the most important is how will his packages be signed from now on? Was it an oversight or an intentional change. If it was intentional we will end in the same situation next month.
In any case, even if it happens once more the other way around in February, until March everything has to be synced. But for February release just adding locally all the 3 keys might be the workaround.
I guess we will see if anyone will get problems on next stable update and who - those who reverted or those who added one more key (they should actually be safe).
For now just note both solutions - revering the whole keyring and locally adding a key.
