Arch Linux upgrade problems

Rosika · February 9, 2024, 1:51pm

Hi all,

I wonder if anybody can help me solving an upgrade problem I encountered with Arch Linux.

I´m running Arch Linux as a virtual machine in gnome-boxes. This is the image I´m using: “Arch-Linux-x86_64-basic-20220127.45754.qcow2”.

I used to run it with virt-manager but at present I´m running it with gnome-boxes. No issues there. The problems started when I tried to upgrade Arch.

I did it this way: pacman -Syu.
This should update the package repositories and then perform the upgrade, as Arch is a rolling release model.
Currently it´s an older version: archlinux 5.16.3.

I´ll have to dig my memory as I didn´t take notes at the time. I´ll do my best to be as accurate as possible. Well, I got something like this in the terminal:

core is up to date
extra is up to date
community is up to date

Then I proceeded: Starting full system upgrade.
After that: resolving dependencies... looking for conflicting packages... .

So far so good. Then:
Proceed with installation? [Y/n] I accepted, of course. After that several “corrupted” errors occurred.
Here is just one example:

File /var/cache/pacman/pkg/confuse-2.8-2-x86_64.pkg.tar.xz 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.

I always let the packages be deleted but in the end I got “errors occurred, no packages were upgraded”. I wasted about 600 MB of download and the system wasn´t upgraded after all.

I also refreshed the package mirrors: sudo pacman -Syy
and cleared the pacman cache: sudo pacman -Scc.
Nothing helped so far.

Then I thought: Perhaps it’s possible that my pacman keyring is outdated or corrupted. So I did the following:

sudo pacman-key --init
sudo pacman-key --populate archlinux

It worked well but the upgrade still failed with the same errors.

Then I updated my mirrorlist using reflector:
sudo reflector --country Germany --latest 10 --sort rate --save /etc/pacman.d/mirrorlist .

cat /etc/pacman.d/mirrorlist showed me that I was successful in doing that. But the upgrade still failed with the same error messages.

Now I´m running out of ideas. Does anyone know what can be done about it

Thanks a lot in advance and many greetings from Rosika.

ihasama · February 9, 2024, 2:25pm

I’m not sure if this helps. I’ve noticed that sometimes you just need to wait for a while if an update doesn’t work. It’s Arch and not so stable IMO… have you checked arch’s webpage? There might be news if it’s common problem.

abhishek · February 9, 2024, 2:27pm

This is what i see on Arch wiki:

“Failed to commit transaction (invalid or corrupted package)” error

Look for .part files (partially downloaded packages) in /var/cache/pacman/pkg/ and remove them (often caused by usage of a custom XferCommand in pacman.conf).

find /var/cache/pacman/pkg/ -iname "*.part" -delete

Did you to try that?

Rosika · February 9, 2024, 2:29pm

Hi @ihasama,

thanks for your reply.

I see. Well, it´s been a few days now and nothing has changed so far.

But I´ll take a look at Arch´s webpage. Thanks for the suggestion.

Cheers from Rosika

Rosika · February 9, 2024, 2:36pm

Hi Abhishek,

thanks for your suggestion.

I just looked at it:

find /var/cache/pacman/pkg/ -iname "*.part"

didn´t return anything. There seem to be no partially downloaded packages. All of them seem to be quite complete.
So the problem has to be elsewhere.

Thanks a lot.

Cheers from Rosika

Rosika · February 9, 2024, 3:48pm

Update:

I seem to have succeeded at last:

Here I found that the problem I encountered had been discussed already.
One member suggested:

pacman -S archlinux-keyring

and then

pacman -Syu

This did the trick.

These are the messages I got from the fist command:

sudo pacman -S archlinux-keyring
resolving dependencies...
looking for conflicting packages...

Packages (1) archlinux-keyring-20231222-1

Total Installed Size:  1.65 MiB
Net Upgrade Size:      0.22 MiB

:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring                          [##############################] 100%
(1/1) checking package integrity                        [##############################] 100%
(1/1) loading package files                             [##############################] 100%
(1/1) checking for file conflicts                       [##############################] 100%
(1/1) checking available disk space                     [##############################] 100%
:: Processing package changes...
(1/1) upgrading archlinux-keyring                       [##############################] 100%
==> Appending keys from archlinux.gpg...
==> Locally signing trusted keys in keyring...
  -> Locally signed 2 keys.
==> Importing owner trust values...
gpg: inserting ownertrust of 4
gpg: setting ownertrust to 4
==> Disabling revoked keys in keyring...
  -> Disabled 19 keys.
==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   5  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   5  signed:  98  trust: 0-, 0q, 0n, 5m, 0f, 0u
gpg: depth: 2  valid:  74  signed:  29  trust: 74-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2024-04-10
:: Running post-transaction hooks...
(1/2) Reloading system manager configuration...
(2/2) Arming ConditionNeedsUpdate...

After that the upgrade went through with an exit code of zero.

I still get:

arch@archlinux ~> uname -a
Linux archlinux 5.16.3-arch1-1 #1 SMP PREEMPT Thu, 27 Jan 2022 14:18:25 +0000 x86_64 GNU/Linux

arch@archlinux ~> lsb_release -a
LSB Version:	n/a
Distributor ID:	Arch
Description:	Arch Linux
Release:	rolling
Codename:	n/a

So the version number “Linux archlinux 5.16.3-arch1” hasn´t changed after all.
Perhaps this is meant to be that way in a rolling distro

Well:

sudo pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra                        8.3 MiB  1952 KiB/s 00:04 [##############################] 100%
:: Starting full system upgrade...
 there is nothing to do

seems to suggest the system is up-do-date now.

Thanks to all of you for your help.

Many greetings from Rosika

nevj · February 10, 2024, 12:07am

Can anyone explain what a ‘keyring’ is, and why it would need to be updated?

I is OK to follow a recipe to get out of an impasse like this, but even after a successful recovery, we need to understand
what happened and how to avoid it in future.

nevj · February 10, 2024, 9:15am

In Gentoo, it seems to use the kernel release

$ uname -a
Linux mary 6.6.0-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 10 21:13:50 AEDT 2023 x86_64 Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz GenuineIntel GNU/Linux

ie I have kernel 6.6.0

But you are right, in a rolling release distro there are no releases.

Void is the same

Linux trinity 6.6.11_1 #1 SMP PREEMPT_DYNAMIC Sat Jan 13 23:28:15 UTC 2024 x86_64 GNU/Linux

So I tink your 5.16.3 is the kernel version, and the kernel has not been updated. Would that be right.
Dont know what you do in Arch to update a kernel?

Compare this with something like MX, which is semi-rolling

$ uname -a
Linux trinity 6.5.0-1mx-ahs-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1~mx23ahs (2023-09-17) x86_64 GNU/Linux

$ cat /etc/lsb-release
PRETTY_NAME="MX 23.2 Libretto"
DISTRIB_ID=MX
DISTRIB_RELEASE=23.2
DISTRIB_CODENAME="Libretto"
DISTRIB_DESCRIPTION="MX 23.2 Libretto"

It has a definite release number, as well as a kernel version.

Rosika · February 10, 2024, 3:06pm

Hi Neville,

thanks for you feedback.

As far as the kernel version is concerned: I just checked again, right after booting into Arch with gnome-boxes today.
Now it looks like this:

uname -a
Linux archlinux 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000 x86_64 GNU/Linux

So now it actually says it´s using kernel 6.7.4, which is the latest (for Arch) indeed.
I compared it to the info I found here.

Thinking of it, I didn´t reboot Arch after the upgrade yesterday. Might that have been it

In deb-based systems you have to reboot after a kernel is updated if you want to use the latest version. It might be the same here… .

Well, that´s well and good now, I think.

I also installed spice-vdagent in Arch, so copy-and-paste between host and guest works now.
Previously I was using the workaround of ssh-ing into Arch from the host and I could copy-and-paste from the terminal this way.

BTW: my output:

cat /etc/lsb-release
DISTRIB_ID="Arch"
DISTRIB_RELEASE="rolling"
DISTRIB_DESCRIPTION="Arch Linux"

That´s all.

As far as the topic of keyring is concerned…

That´s of interest to me, too. I put forward the question to ChatGPT to see what it has to say about it:

me:

I´d like to know a bit more about the command pacman -S archlinux-keyring. Could you explain to me what it did and how it helped in running the following command pacman -Syu successfully?

ChatGPT:

pacman -S archlinux-keyring:

This command instructs the Pacman package manager to install the archlinux-keyring package.

The archlinux-keyring package contains the GnuPG keys used to verify the authenticity of packages from the Arch Linux repositories.

These keys are used to verify the digital signatures of packages during installation or upgrade.
Installing the archlinux-keyring package ensures that your system has the necessary keys to verify the authenticity of packages retrieved from the Arch Linux repositories.

pacman -Syu:

This command is used to synchronize package databases and upgrade all packages on the system to their latest versions.

The -S flag synchronizes the package databases (pacman -Sy), and the -u flag performs a system upgrade by installing or upgrading packages as necessary.
During the system upgrade (pacman -Syu), Pacman retrieves package information and files from the Arch Linux repositories.

Before installing or upgrading packages, Pacman verifies the digital signatures of the packages using the GnuPG keys from the archlinux-keyring package.
If the GnuPG keys are missing or outdated, Pacman may fail to verify the signatures of packages, resulting in errors like “invalid or corrupted package (PGP signature).”

By installing the archlinux-keyring package before running pacman -Syu, you ensure that your system has the latest GnuPG keys required to verify the digital signatures of packages from the Arch Linux repositories.

This helps Pacman to authenticate the packages correctly during the upgrade process, preventing errors related to invalid or corrupted PGP signatures.

In summary, installing the archlinux-keyring package ensures that your system has the necessary keys to authenticate packages from the Arch Linux repositories, enabling a successful system upgrade (pacman -Syu).

Thanks a lot for your help, Neville.

Many greetings from Rosika

nevj · February 10, 2024, 10:11pm

I think uname may get its information from /proc rather than /etc, so it will report what is currently running. A new kernel
will obviously not run until you reboot… you cant switch kernels on the fly.

Thank you for the info on keys in Arch. I may need to do that in Artix.
I wonder why the .iso would not install the archlinux-keyring package when you install.?

Rosika · February 11, 2024, 1:58pm

Hi Neville,

thanks for your reply.

Yes, I thought as much (in the meantime, that is. I didn´t think of it back then).
Thanks for the confirmation.

You´re welcome. I could learn something new as well.

I was asking myself the same question. Actually I have no idea… .

Many greetings from Rosika

Winston · February 14, 2024, 11:36pm

Arch Linux is a distribution which requires quite a lot of attention, so it’s important to update frequently - I’d say at least once a week if you’re running with the main kernel, maybe every 2 weeks if you’re using the lts kernel (I’d recommend the latter for an easier time). As for the update itself, if you are using the AUR then yay -Syu should be the preferred option (note, without sudo), otherwise sudo pacman -Syu.

The archlinux-keyring is a package in itself, and it can get out of date if updates are done too infrequently (I don’t know why this isn’t handled by Pacman updating the keyring first as a matter of course, but my experience has been that this doesn’t happen). If it is out of date, the keys for some changed packages may be out of date or unavailable.

It is a good idea to reboot after updates. Sometimes you can experience curious behaviour if you just carry on working without a reboot (e.g. browser not launching).