"untrusted keys" and "corrupted"

[buhtz]

X-Post in Arch Forum: LINKS-NOT-ALLOWED https_bbs.archlinux_org/viewtopic.php?pid=2188851

Sorry, for also asking. I can find a lot of messages about this in the internet but none of the solutions (I tried and understood) worked for me. Beside of that I am not a regular Arch user but coming from Debian. I am just an upstream maintainer needing Arch doing tests.

Are run Arch on a VM only every couple of months. So the state of the system is often out of date. The error message I do get is

$ sudo pacman -Sy archlinux-keyring manjaro-keyring && sudo pacman -Su
...
(602/602) checking package integrity               [#################] 100%
error: bash: signature from "Mark Wagie <mark@manjaro.org>" is unknown trust
:: File /var/cache/pacman/pkg/bash-5.2.026-3-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
...
error: xiccd: signature from "Mark Wagie <mark@manjaro.org>" is unknown trust
:: File /var/cache/pacman/pkg/xiccd-0.3.0-2-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

There are several “unknown trust” and “corrupted” messages like this.
Seems to doesn’t matter if I answer Y or n.

I also know this commands, not sure what they are doing but also tried them.

$ sudo pacman-key --refresh-keys
$ sudo rm -R /etc/pacman.d/gnupg
$ sudo pacman-key --init
$ sudo pacman-key --populate archlinux

[Arrababiski]

Here we even have a script to solve those issues:

[HowTo] Work around gpg verification issue on left behind systems

Difficulty: ★☆☆☆☆ This script is the result of people here in the forum having problems with Manjaro installations that haven’t been updated for more than 2 months or booting an old ISO plus installing it which is older than 2 months. I was a bit tired of explaining how to solve that issue and created a script, which does the job. Methods Method 1 - Basic Remove lock files of pamac and pacman Refresh Package Database Populate local keyrings to the GnuPG Database of pacman Refresh GnuPG Data…

[omano]

@buhtz

bbs.archlinux_org/viewtopic.php?pid=2188851

You should not post on Arch forum for issues with Manjaro, you’ll probably receive the adequate response there in a moment

PS: you didn’t even search, I typed manjaro-keyring in the forum search, and found the thread quickly (it is often suggested in most of the threads in results): [HowTo] Work around gpg verification issue on left behind systems (same as above). Same if you search the actual error invalid or corrupted package.

[linux-aarhus]

Another source → Pacman troubleshooting - Manjaro

[buhtz]

I didn’t search for “manjaro-keyring” because I did not realize this is a Manjaro problem. From my non-user-upstream-maintainer-perspective Manjaro is just an Arch easier to install. Anyway…

Even after reading the sources you where so nice to provide I do not understand why the problem occur every time I boot an Arch-based distro.

I try to understand and not only solve. Let me ask the other way around: Why isn’t this treated as a bug when it has such impact on users?

[cfinnberg]

@buhtz

Manjaro is just an Arch easier to install.

How to offend two distro communities with just one phrase (just kidding)

The mantra is: Manjaro is not Arch. Manjaro has its own repositories, and even if most packages come from Arch, there are enough differences that make them two different distros.

That said, to solve the problem now, you can follow the instructions in the link provided by @Arrababiski and download and execute the script.

If you want to avoid these problems in the future, you should update your VM more often. If you really do it every couple of months it shouldn’t be any problems.

[buhtz]

@cfinnberg

If you want to avoid these problems in the future, you should update your VM more often. If you really do it every couple of months it shouldn’t be any problems.

That is a workaround not a solution. I am not an Arch(-based) user. I am an upstream maintainer. I boot that VMs only for diagnosing bugs or doing full tests before a new release.

Again: Why does this problem happens? From my current point of view it looks like a design problem of the whole package infrastructure and management.

On Debian GNU/Linux this does not happen. What is the difference in the concept of these two package systems?

I am asking not to blame Arch & Co but just to learn.

[omano]

@buhtz

Why does this problem happens?

I don’t have the explanation but Rolling Release distributions NEED to be updated regularly, you also need to follow changes to configuration that will/may not be updated automagically, or changes to critical system parts.

For the keys issue, I would guess you missed multiple consecutive updates of these packages and at some point you have no possibility of properly continue the updates of anything normally, as everything regarding that is out of date, and a manual intervention is required to get the normal update process work as intended. Maybe someone who knows will chime in at some point.

@buhtz

On Debian GNU/Linux this does not happen

Yes, this is not the same at all, these are Point Release distribution, and another package manager, everything works completely in other ways. Respective WIKI and manuals will have all the answers regarding how things work here or there.

[Molski]

@omano

I don’t have the explanation but Rolling Release distributions NEED to be updated regularly

I ran Gentoo for over 15 years, another rolling release distro. It was kind of the nature of the beast. It was one a downside to running the latest of everything, and all the cool things Gentoo could do compared to other distros in it’s day. They even have dispatch for config files, instead of pacnew files, and they can even be versioned controlled there.

As technologies arise and grow, big changes happens to rolling release distros. Just to name a couple, Wayland got enabled by default if possible, and now Pipewire instead of Pulseaudio. Things become obsolete, and new things take their place.

Should an update on an instance work after you haven’t touched it for 2 years? That would be great! But if it’s regularly going to be mostly powered off for very long periods, any rolling release distro is probably not the right choice for this circumstance. As omano said, you probably want a distro that is point/fixed release, and has Long Term Support (LTS) on top of that.

I honestly don’t know how far back testing takes place for updates, the longest I’ve gone is 2 weeks.

[omano]

In his case he doesn’t need to run Point Release distro, as he said he uses various systems to do bug testing for a project he maintains. So he needs to use this or this distro in order to bug hunting or do various tests.

Updating the machines every month or so would be the way to go if he wants to use them occasionally for his tests. Or a full new install would be the other way to go. But starting a machine 6 months after last update and expecting everything to work on a full system update without any manual intervention is very optimistic. As you said it is the nature of the beast, it keeps rolling.