New openssl package downlaod is corrupt?

ZetaRevan · 2022-12-20 23:31:19

Hi guys,
I'm running a fresh install using the latest iso from Dec on a spare laptop and am running into an issue with the latest openssl 3.0.7 package giving me a message that the.zst package is invalid or corrupted. So I tried changing my mirrorlist to the US mirrorlist using reflector, but I'm still getting the same issue with just that one package when running pacstrap. I tried clearing everything cached in /mnt & running pacstrap again with the new mirrorlist & still no go. I tried clearning it again, running `pacman-key --init`, then tried to install again, and still the same message on the openssl package. I'm not new to installing arch, but this is the first time I've run into this on a brand new install.

error: openssl signature from "Pierre Schmitz <pierre@archlinux.org>" is marginal trust
:: File /mnt/var/cache/pacman/pkg/openssl-3.0.7-4-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).

Last edited by ZetaRevan (2022-12-20 23:34:51)

Trilby · 2022-12-20 23:38:02

Have you tried updating the keyring first.

2ManyDogs · 2022-12-20 23:44:26

Not an installation issue; moving to Newbie Corner.

chfourie · 2022-12-21 04:55:54

The above also applies to a fresh install. I get it when running "pacstrap /mnt base linux linux-firmware" on a new system using a script I have used many times before. (NTP service active, date/time correct on system)

A bug has been opened and subsequently closed on this (76855). The original bug was created by somebody using a docker image. As a result it was closed. I logged a request to have the task re-opened as it is not just happening in docker but also on brand new installs, but I was told to use support channels (IRC, forums, etc) and the request was rejected. 5 more people have voted the issue up after I logged the request to have it re-opened. If you do a google search, the first mention of this is found on 17 December 2022, and then 7 other people (including your self) seemed to have experienced the same issue.

I suspect there is something broken but at this point in time the powers that be still assume it's finger trouble on the part of the user.

Last edited by chfourie (2022-12-21 05:00:44)

HCF · 2022-12-21 06:09:20

As per the wiki, 'sudo pacman -Sy archlinux-keyring' should fix this issue.

ZetaRevan · 2022-12-21 06:12:15

Trilby wrote:

Have you tried updating the keyring first.

I did not, which is why I posted the question in here, and it did work after doing that.

HCF wrote:

As per the wiki, 'sudo pacman -Sy archlinux-keyring' should fix this issue.

That did actually fix it. Thank you.

Last edited by ZetaRevan (2022-12-21 06:13:52)

chfourie · 2022-12-21 07:22:53

Thank you very much @HCF

Running 'sudo pacman -Sy archlinux-keyring' before pacstrap on a new installation solved the issue for me.

Last edited by chfourie (2022-12-21 10:49:05)

MarkZackie · 2022-12-21 10:44:39

HCF wrote:

As per the wiki, 'sudo pacman -Sy archlinux-keyring' should fix this issue.

Many thanks, this solve my issue too (installing from a bootstrap image).

The wiki fails to mention that this command is necessary just before the package list refreshing:
https://wiki.archlinux.org/title/Instal … asic_tools

Trilby · 2022-12-21 17:26:49

It's only necessary under certain conditions. If those conditions will happen sporadically on otherwise "normal" installs, then there'd be a very good case to include a note of this in the installation guide. However, the installation guide has been updated to include the -K flag for pacstrap: was that flag used when these errors were returned? I've not used pacstrap since that flag was added, and I don't really understand it's function, but it does change how the target system's keyring is initialized (initially "empty" but I assume this would mean it was otherwise initialized [e.g., by installing the keyring first] in order to install packages or pactrap -K would fail every time on all packages).

Last edited by Trilby (2022-12-21 17:27:23)

lhaer · 2022-12-21 17:39:37

Quite honestly I don't think the user should be expected to know that they have do this during a brand new installation, and if they are, that should be in the Arch Wiki as Trilby pointed out. So I'd say it is an installation problem, yes. I wouldn't expect to download an Arch Linux ISO and then during the initial steps of the installation receive a package corrupted error right away after correctly following the steps in the Installation Guide from the Wiki

Last edited by lhaer (2022-12-21 17:40:05)

amrtykl · 2022-12-21 17:53:30

Manually updating the keyring does the trick.

Per Wiki, It is recommended to avoid the "-Sy" flag when upgrading packages, so is okay to proceed with?

----
EDIT: Any place to make suggestions about live environment behavior/ISO?

I would suggest that the ISO always update the keyring when connecting to the internet, just like it does with NTP. It would avoid problems like this in the future.

Last edited by amrtykl (2022-12-21 17:57:14)

Scimmia · 2022-12-21 17:58:18

amrtykl wrote:

Manually updating the keyring does the trick.
Per Wiki, It is recommended to avoid the "-Sy" flag when upgrading packages, so is okay to proceed with?

-Sy is unsafe because anything else you try to install will now potentially be newer than the rest of the system. Since you're still on the ISO, you're not generally going to be installing anything there, and even if you did, nothing is persistent, so a reboot fixes it. This is one of the few times you can use -Sy without following it with -Su or -Syu.

Lone_Wolf · 2022-12-21 18:04:51

man pacstrap(8) wrote:

-K
Initialize an empty pacman keyring in the target (implies -G).
-G
Avoid copying the host’s pacman keyring to the target.

That suggests pacstrap -K uses the freshly downloaded archlinux-keyring package to avoid these errors .

cfr · 2022-12-21 18:14:14

HCF wrote:

As per the wiki, 'sudo pacman -Sy archlinux-keyring' should fix this issue.

You should not need sudo during the installation of the system. You're already root and I don't think any normal user account even exists.

This is an installation issue even though people sometimes encounter the same issue with pacman as people are reporting with pacstrap. Just as getting the network working is an installation issue when booting the live distro to install, even though people obviously encounter the same network problems in installed systems.

Fwiw, I suggested the move of this thread might have been mistaken, but I don't know if they would move it back unless the OP requested it. Or maybe the mods think it isn't an installation issue for some reason. I have a pretty simplistic notion of what counts as an installation issue, so that might be the problem.

rufus_lenhador · 2022-12-22 02:27:29

Lone_Wolf wrote:

man pacstrap(8) wrote:
-K
Initialize an empty pacman keyring in the target (implies -G).
-G
Avoid copying the host’s pacman keyring to the target.
That suggests pacstrap -K uses the freshly downloaded archlinux-keyring package to avoid these errors .

Fresh install here, -K option used and had the same error.

'# pacman -Sy archlinux-keyring' fixed it. IMHO it does make sense to have that info in the install wiki instead of having to search on google like I did to find this post.

Edit: not fresh install; this happened while in the live environment.

Last edited by rufus_lenhador (2022-12-22 03:37:16)

cfr · 2022-12-22 02:55:47

rufus_lenhador wrote:

Lone_Wolf wrote:
man pacstrap(8) wrote:
-K
Initialize an empty pacman keyring in the target (implies -G).
-G
Avoid copying the host’s pacman keyring to the target.
That suggests pacstrap -K uses the freshly downloaded archlinux-keyring package to avoid these errors .
Fresh install here, -K option used and had the same error.

Did you get the error on your freshly installed system? Or did you get the error while in the live environment installing the system? If the first, the error is irrelevant to the issue pacstrap -K is intended to address. If the second, that looks like a bug which should be reported.

rufus_lenhador · 2022-12-22 03:02:45

cfr wrote:

rufus_lenhador wrote:
Lone_Wolf wrote:
That suggests pacstrap -K uses the freshly downloaded archlinux-keyring package to avoid these errors .
Fresh install here, -K option used and had the same error.
Did you get the error on your freshly installed system? Or did you get the error while in the live environment installing the system? If the first, the error is irrelevant to the issue pacstrap -K is intended to address. If the second, that looks like a bug which should be reported.

Second option:

error while in the live environment installing the system

Edit: should I be the person reporting it?
Edit 2: no idea if this is relevant, but just remembered the first message I got after booting archiso was something about a X.509 certificate being invalid. This laptop came with Windows installed and I see in 'dmesg' messages about Microsoft X.509 certificates being loaded.

Last edited by rufus_lenhador (2022-12-22 03:14:47)

cfr · 2022-12-22 04:08:34

rufus_lenhador wrote:

Second option:
error while in the live environment installing the system

Do you know if you used any other options? I'm just looking at the manual page and I suspect you could cancel out the -K, so that would be something to check before reporting.

As to whether you should be the one to report it, why not? Just check to see there's not already a bug report. But be sure first it really is behaving other than as the docs say.

Edit: Is -K -G the correct approach? How does initialising an empty keyring help at all? Compare e.g. https://bugs.archlinux.org/task/71983?s … &closedto= and https://bugs.archlinux.org/task/75860?p … &sort=desc.

If you just initialise a keyring, how is it supposed to get populated exactly?

Last edited by cfr (2022-12-22 04:19:33)

withgoody7 · 2022-12-22 04:37:54

Hello.... I encountered same issue this morning while I was installing fresh install

pacstrap /mnt .........

I don't know how to run pacman command this stage

I found the easiest way.... to do..

#archinstall

then automatically archlinux-keyring upgraded

then... abort

# prompt appeared and continue to manual install as we do fresh-install every time.

Hope each time we can do avoid the pgp keyring error each time.

Last edited by withgoody7 (2022-12-22 04:39:11)

Trilby · 2022-12-22 04:43:41

withgoody7 wrote:

pacstrap /mnt .........

So you didn't use the -K flag which is advised in the installation guide.

rufus_lenhador · 2022-12-22 16:37:42

cfr wrote:

rufus_lenhador wrote:
Second option:
error while in the live environment installing the system
Do you know if you used any other options? I'm just looking at the manual page and I suspect you could cancel out the -K, so that would be something to check before reporting.

No, I followed exactly as stated there.

imk82 · 2022-12-22 21:20:43

Hi all,

I faced the exact same problem while installing Arch on two completely blank systems following exactly the install instructions of the wiki page. When exectuing "pacstrap -K /mnt PACKAGELIST" (including base,linux and linux-firmware) the following error occurred:

error: openssl signature from "Pierre Schmitz <pierre@archlinux.org>" is marginal trust
:: File /mnt/var/cache/pacman/pkg/openssl-3.0.7-4-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).

So I think this clearly a kind of bug or documentation problem. I could solve it by updating the keyring package as well ("pacman -Sy archlinux-keyring").

Best regards
Robert

amrtykl · 2022-12-23 01:28:15

I've been looking deeper to understand and I believe it goes like this:

-> pacstrap -K /mnt [PKG] - initiates a recent keyring, getting the package from upstream. This keyring is valid and used only by pacman of the installed system.

-> The problem with the openssl package is caused by an invalid key.

-> pacstrap never updates the live environment keyring, as its function is just to install packages where we specify.
• pacman -Sy archlinux-keyring updates the keyring of the live environment, thus updating the information about the keys. (This fixes the problem with the package and its invalid signature)

I believe there is not a bug (in pacstrap or on ISO) as everything works as expected. I think just changing the behavior of the ISO to always download the latest keyring (like we use the reflector to get the latest mirrorlist) fixes this permanently.
The keyring must be something of a critical level because it contains important information for the correct operation of the live environment - keeping it always updated (ISO live environment), is something important and should be considered.

imk82 · 2022-12-23 22:01:46

amrtykl wrote:

I've been looking deeper to understand and I believe it goes like this:
-> pacstrap -K /mnt [PKG] - initiates a recent keyring, getting the package from upstream. This keyring is valid and used only by pacman of the installed system.
-> The problem with the openssl package is caused by an invalid key.
-> pacstrap never updates the live environment keyring, as its function is just to install packages where we specify.
• pacman -Sy archlinux-keyring updates the keyring of the live environment, thus updating the information about the keys. (This fixes the problem with the package and its invalid signature)
I believe there is not a bug (in pacstrap or on ISO) as everything works as expected. I think just changing the behavior of the ISO to always download the latest keyring (like we use the reflector to get the latest mirrorlist) fixes this permanently.
The keyring must be something of a critical level because it contains important information for the correct operation of the live environment - keeping it always updated (ISO live environment), is something important and should be considered.

Hi amrtykl,

I fully agree with you.

What is the process to change this in pacstrap?

Best regards
Robert

cfr · 2022-12-24 00:45:03

imk82 wrote:

What is the process to change this in pacstrap?

File a bug against arch-install-scripts which includes pacstrap. Feature requests are technically treated as a kind of bug. (I mention this because it might not be obvious - it certainly wasn't obvious to me for a while.)

Arch Linux

#1 2022-12-20 23:31:19

New openssl package downlaod is corrupt?

#2 2022-12-20 23:38:02

Re: New openssl package downlaod is corrupt?

#3 2022-12-20 23:44:26

Re: New openssl package downlaod is corrupt?

#4 2022-12-21 04:55:54

Re: New openssl package downlaod is corrupt?

#5 2022-12-21 06:09:20

Re: New openssl package downlaod is corrupt?

#6 2022-12-21 06:12:15

Re: New openssl package downlaod is corrupt?

#7 2022-12-21 07:22:53

Re: New openssl package downlaod is corrupt?

#8 2022-12-21 10:44:39

Re: New openssl package downlaod is corrupt?

#9 2022-12-21 17:26:49

Re: New openssl package downlaod is corrupt?

#10 2022-12-21 17:39:37

Re: New openssl package downlaod is corrupt?

#11 2022-12-21 17:53:30

Re: New openssl package downlaod is corrupt?

#12 2022-12-21 17:58:18

Re: New openssl package downlaod is corrupt?

#13 2022-12-21 18:04:51

Re: New openssl package downlaod is corrupt?

#14 2022-12-21 18:14:14

Re: New openssl package downlaod is corrupt?

#15 2022-12-22 02:27:29

Re: New openssl package downlaod is corrupt?

#16 2022-12-22 02:55:47

Re: New openssl package downlaod is corrupt?

#17 2022-12-22 03:02:45

Re: New openssl package downlaod is corrupt?

#18 2022-12-22 04:08:34

Re: New openssl package downlaod is corrupt?

#19 2022-12-22 04:37:54

Re: New openssl package downlaod is corrupt?

#20 2022-12-22 04:43:41

Re: New openssl package downlaod is corrupt?

#21 2022-12-22 16:37:42

Re: New openssl package downlaod is corrupt?

#22 2022-12-22 21:20:43

Re: New openssl package downlaod is corrupt?

#23 2022-12-23 01:28:15

Re: New openssl package downlaod is corrupt?

#24 2022-12-23 22:01:46

Re: New openssl package downlaod is corrupt?

#25 2022-12-24 00:45:03

Re: New openssl package downlaod is corrupt?

Board footer