Tag: pacman

error: blackarch: signature from “Levon ‘noptrix’ Kayan (BlackArch Developer) ” is invalid (SOLVED)

When trying to update Arch Linux with BlackArch repositories with the command

sudo pacman -Syu

an error occurred:

error: blackarch: signature from "Levon 'noptrix' Kayan (BlackArch Developer) <noptrix@nullsecurity.net>" is invalid

The error message says that the signature of one of the BlackArch developers is not valid.

To solve this error, just delete the /var/lib/pacman/sync/blackarch.db.sig file:

sudo rm /var/lib/pacman/sync/blackarch.db.sig

Then run the update as usual:

sudo pacman -Syu

The error no longer occurs:

I don't know exactly what caused this problem, perhaps a file corruption due to a network problem during a system update.

After updating the information from the package repositories, the /var/lib/pacman/sync/blackarch.db.sig file was recreated and the error no longer occurred. That is, there is no need to worry that your Linux will lose any functionality.

How to download a package without installation in Arch Linux and Manjaro. How to download the AUR package source code

How to download a package with pacman (from standard repositories)

To download a package without installing it, use the -w option:

sudo pacman -Sw PACKAGE

By default, the package will be downloaded to pacman's package cache directory, with the --cachedir option you can specify any other directory to save the package to:

sudo pacman -Sw --cachedir DIRECTORY PACKAGE

For example, the following command will download the iw package installation file to the current directory (--cachedir .):

sudo pacman -Sw --cachedir . iw

How to download an installation package and source code from the AUR

See also:

Packages from the Arch User Repository (AUR) are not so simple, since there are no ready-made installation packages in the AUR. Instead of installation packages, the AUR necessarily contains PKGBUILD files, which contain commands for building the package to be installed. In addition to the PKGBUILD file, other necessary files may also be present, such as patches for modifying the source code. Source code files and binaries are usually absent from the AUR repositories, instead, links and commands for downloading all necessary files and source code are written in the PKGBUILD file.

Therefore, there may be several options for downloading AUR packages:

  • package repository (PKGBUILD file and other related files)
  • all files needed to build the package (source code files and other files downloaded in PKGBUILD)
  • a ready-to-install package that is not available elsewhere and is built directly on the user's computer

Let's consider all these situations.

How to download the AUR repository

To download (clone) a repository from the AUR, you need to know its URL. The repository address can be viewed with a command like:

pikaur-Si PACKAGE

For example:

pikaur -Si deadbeef-git

In the output of the previous command, notice the line “AUR Git URL”:

AUR Git URL     : https://aur.archlinux.org/deadbeef-git.git

To download (clone) use the following command:

git clone AUR_GIT_URL

For example:

git clone https://aur.archlinux.org/deadbeef-git.git

How to download AUR source code

Consider the following problem:

I need to change the source code in the program (meaning not the PKGBUILD file). How to download source files and unzip them?

To download the source code, you need to start by cloning the AUR repository, for this you need to know its URL. The repository address can be viewed with a command like:

pikaur-Si PACKAGE

For example:

pikaur -Si deadbeef-git

In the output of the previous command, notice the line “AUR Git URL”:

AUR Git URL     : https://aur.archlinux.org/deadbeef-git.git

To download (clone) use the following command:

git clone AUR_GIT_URL

For example:

git clone https://aur.archlinux.org/deadbeef-git.git

Go to the folder with the downloaded repository

cd deadbeef-git/

To download and extract files, use the following command:

makepkg -o

If you want to skip dependency checking, then add the -d option:

makepkg -od

The result of the previous commands will be to download the source code files needed to build the setup file from the AUR.

You can edit the files to suit your needs, and then build the installation file and install the package from it with the following command:

makepkg -si

If, as a result of your actions, the package cannot be built due to a checksum mismatch, then use the following options:

  --nocheck        Do not run the check() function in the PKGBUILD
  --skipchecksums  Do not verify checksums of the source files
  --skipinteg      Do not perform any verification checks on source files
  --skippgpcheck   Do not verify source files with PGP signatures

How to download the installation file from the AUR

As mentioned above, this is a slightly incorrect formulation of the problem, since the installation files are missing in the AUR.

To get the installation file, use the following set of commands:

git clone AUR_GIT_URL
cd PACKAGE_DIRECTORY
makepkg -s

For example, downloading the source code, compiling the program, and building the installation package for deadbeef-git:

git clone https://aur.archlinux.org/deadbeef-git.git
cd deadbeef-git/
makepkg -s

The command completed without errors:

As a result of the command, a file with the *.pkg.tar.zst extension was created (in this case, it is deadbeef-git-r10944.4469d86c7-1-x86_64.pkg.tar.zst):

“Error: failed to commit transaction (invalid or corrupted package)” (SOLVED)

When updating or installing packages in Arch Linux, Manjaro and their derivatives, you may encounter the “error: failed to commit transaction (invalid or corrupted package). Errors occurred, no packages were upgraded.” issue.

Full error log:

:: Retrieving packages...
 libinih-55-2-x86_64                                15.4 KiB   385 KiB/s 00:00 [############################################] 100%
(40/40) checking keys in keyring                                               [############################################] 100%
(40/40) checking package integrity                                             [############################################] 100%
error: libinih: signature from "Maxime Gauduin <alucryd@gmail.com>" is marginal trust
:: File /var/cache/pacman/pkg/libinih-55-2-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

In this case, the error occurs when trying to update the libinih package, but it can occur for other packages as well.

First, try delete the package, as recommended, and run the update again to download the installation package file. This will resolve the issue if the error is caused by a corrupted package, such as a network outage.

If this does not help, then instead of a complete update of the system, run the update of the archlinux-keyring package:

sudo pacman -Sy archlinux-keyring

This should fix the PGP signature verification issue.

This error and the problem with incorrect PGP signature can occur on systems that are rarely updated (updated with long breaks). The error lies in the fact that packages with “invalid” PGP signatures are signed with keys that are contained in the updated version of the archlinux-keyring package. Therefore, by starting with updating archlinux-keyring you get new versions of the keys, which then successfully verify the PGP signatures of the package files.

error: failed to synchronize all databases (unable to lock database) (SOLVED)

When trying to update Arch Linux or a distribution based on it (for example, Manjaro or BlackArch), an error “failed to synchronize all databases (unable to lock database)”" may occur.

For example, when entering the command

sudo pacman -Syu

It can be output:

:: Synchronizing package databases...
error: failed to synchronize all databases (unable to lock database)

This means that a file has been created that indicates that the package database is locked for processing, because another program is currently working with the package database.

If this is indeed the case (for example, you have already started pacman in another tab), then it is recommended that you wait for this command to complete so that there are no errors in the cache and database of installed packages later.

If you are sure that this message is displayed exclusively by mistake – for example, you updated packages via SSH using pacman, but the session was unexpectedly terminated and you reconnect to the remote computer, but this error appears when you try to use pacman, then in this case for fixing it is enough to delete the file /var/lib/pacman/db.lck file as follows:

sudo rm /var/lib/pacman/db.lck

After that, run pacman again – the problem should be completely resolved.

If you are unsure whether to delete the db.lck file, you can check its creation date as follows:

ls -l /var/lib/pacman/db.lck

The creation date can tell you why this file is present in the system.

If the problem is not solved, then the second reason may be the disk is full – there is no space left on it to write the lock file. In this case, clean the disk and retry the command to update the system.

You can start the cleanup by deleting the logs. For example, to remove web server logs:

rm /var/log/httpd/*

To delete temporary files:

rm -rf /tmp/*

To remove installation package files:

pacman -Scc

Error “cannot resolve dependency lib32 (32-bit library)” (SOLVED)

When installing a package on Arch Linux or a distro derived from it, for example, by running the following command:

sudo pacman -S trid

an error may occur stating that dependencies could not be resolved. The name of this dependency can contain the number “32” or the string “lib32”, that is, it is a 32-bit package, for example:

resolving dependencies...
warning: cannot resolve "lib32-ncurses", a dependency of "trid"
:: The following package cannot be upgraded due to unresolvable dependencies:
      trid

:: Do you want to skip the above package for this upgrade? [y/N]

To fix this error, multilib must be enabled.

The multilib repository is the official repository that allows the user to run and build 32-bit applications on 64-bit Arch Linux.

To enable multilib, open the text file /etc/pacman.conf:

sudo gedit /etc/pacman.conf

Find and uncomment the lines in it (make sure to uncomment both lines, otherwise the changes will not take effect):

[multilib]
Include = /etc/pacman.d/mirrorlist

Update package information:

sudo pacman -Sy

And re-run the package installer – this time all dependencies should be resolved.

Error “ruby-bundler: /usr/share/man/man5/gemfile.5.gz exists in filesystem (owned by ruby)” (SOLVED)

Whenever operating system packages are updated (as well as when new packages are installed), in addition to checking dependencies, package managers also check that there is no file conflict. That is, a package containing files that are already on disk and do not belong to this package will not be updated or installed.

During a regular system update (Arch Linux, for example) with the command

sudo pacman -Syu

you may run into error:

(8/8) checking for file conflicts                  [######################] 100%
(8/8) checking for file conflicts
error: failed to commit transaction (conflicting files)
ruby-bundler: /usr/share/man/man5/gemfile.5.gz exists in filesystem (owned by ruby)
Errors occurred, no packages were upgraded.

This issue is specific to the ruby-bundler-2.2.16-1 package. The essence of the error is that the gemfile.5.gz file already exists in the file system, it belongs to the ruby package, and this file is also present in the new version of the ruby-bundler package. As a result, the update cannot complete due to file conflicts.

Apparently, this problem will be solved in the ruby-3.0.1-1 package, which is currently at the testing stage (the [testing] repository).

You do not have to wait for the upgrade from ruby 2 to ruby 3, especially since this process can be delayed, you can use one of the following workarounds.

Please note that the file /usr/share/man/man5/gemfile.5.gz is just a manual file, documentation, that is, this file is not critical for the operating system.

You can overwrite this file right during the update, for this run the command:

sudo pacman -Syu --overwrite /usr/share/man/man5/gemfile.5.gz

Related article: Analogue of the --force option in pacman

Another option is just delete this file before updating:

sudo rm /usr/share/man/man5/gemfile.5.gz
sudo pacman -Syu

These methods are equivalent, choose any of them to update the packages in the operating system.

pacman error “warning: failed to retrieve some files” (SOLVED)

This article focuses on errors that occur due to problems with the mirror list.

pacman error “The requested URL returned error: 404”

There is a cache for the package manager to work - this cache contains information about existing packages for installation, their versions and download links. To update (or download for the first time) this cache, you need to run the command:

sudo pacman -Sy

Then you can perform a system update or package update.

If the cache is out of date and you are trying to install a package whose version has been updated and for which there is an old link in your local cache, you may receive an error similar to the following:

error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirrors.evowise.com : The requested URL returned error: 404

To fix it, you need to run the above command, and then repeat the installation.

But a similar problem can occur when starting a system update - this is strange, since the following command starts with updating the cache, therefore, the cache is the newest and the “file not found” error should not occur:

sudo pacman -Syu

This command resulted in an error:

error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirrors.evowise.com : The requested URL returned error: 404
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.rackspace.com : The requested URL returned error: 404
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.rackspace.com : The requested URL returned error: 404
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.dkm.cz : The requested URL returned error: 404
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.dkm.cz : The requested URL returned error: 404
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from europe.mirror.pkgbuild.com : The requested URL returned error: 404
....................................................................
....................................................................
....................................................................
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Repeating the command many times does not change anything.

The reason is this: pacman is downloading the cache from a bad mirror that contains incorrect information. To fix it, you need to select another mirror, or move another mirror to the top of the list if you are using multiple mirrors.

Let's start by switching to a new list of mirrors. The fact is that when installing the pacman-mirrorlist package (this package contains a list of mirrors), the new /etc/pacman.d/mirrorlist file does not replace the existing one, but is saved under the name /etc/pacman.d/mirrorlist.pacnew. That is, even if you have the latest version of the pacman-mirrorlist package, this does not mean that you have an up-to-date version of the /etc/pacman.d/mirrorlist file. Check if the /etc/pacman.d/mirrorlist.pacnew file exists:

ls -l /etc/pacman.d/mirrorlist.pacnew

If the file exists, then run the following two commands (otherwise, skip them):

sudo mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.back
sudo mv /etc/pacman.d/mirrorlist.pacnew /etc/pacman.d/mirrorlist

This is not all - the point is that in the /etc/pacman.d/mirrorlist file, by default, all mirrors are commented out, that is, disabled. To fix this, open this file:

sudo gedit /etc/pacman.d/mirrorlist

and uncomment, that is, remove the # character at the beginning of the line. Choose those mirrors and countries that are closer to you.

In my case, the problematic mirror that caused the error described above was the following (do not use it):

#Server = http://mirrors.evowise.com/archlinux/$repo/os/$arch

Arch Linux has stopped updating

If you run the command “sudo pacman -Syu” every day, you may have noticed that on rare days there are no updates. If your system suddenly stopped receiving updates for several days, this may mean that the package cache is being downloaded from a low-quality mirror.

To fix - follow exactly the same steps as described for the previous error. That is, you need to switch to another mirror.

error: failed to update core (no servers configured for repository)

Another possible error after you have done any work with the list of installation package mirrors:

:: Synchronizing package databases...
error: failed to update core (no servers configured for repository)
error: failed to update extra (no servers configured for repository)
error: failed to update community (no servers configured for repository)
error: failed to update multilib (no servers configured for repository)
error: failed to synchronize all databases

The reason for this is that all lines in the /etc/pacman.d/mirrorlist file are commented out. Open this file:

sudo gedit /etc/pacman.d/mirrorlist

and uncomment, that is, remove the # symbol at the beginning of the line for those mirrors and countries that are closer to you.

How to view package information in Arch Linux (BlackArch, Manjaro)

For each package in the system, you can find out such information as: version number, description, developer site, dependencies, recommended dependencies, packages with which there is a conflict, size, etc.

The commands described in this post work the same in Arch Linux, as well as all distributions based on it, such as BlackArch, Manjaro and others.

If you are interested in very brief information about the package - description, version number, and whether the package is installed, then you can use a command like this:

pacman -Ss PACKAGE-NAME

To display all available information about a package, use a command like:

pacman -Si PACKAGE_NAME

To view information about a package installed from the AUR, use a command like:

pikaur -Si PACKAGE NAME

For pikaur see the detailed article “Automatic installation and update of AUR packages”.

In addition to the usual information such as version, description, site address, dependencies, and more, the pikaur command will also show information typical of the AUR: ratings, popularity, when it was first presented, and so on.

So, using the -Si option and pacman or pikaur commands, you can display information about any package.

Analogue of the --force option in pacman

If you update or install a new package, then if the files included in this package are already present in the file system, the update/install operation is aborted and the files that are already present in the system are displayed. In my practice, the reasons are usually packages installed with pip and the same packages that are trying to install with pacman - in which case the package files already exist and installation is not possible.

By the way, in this case, you definitely don't need to use the --force option, but you need to remove the interfering package with a command like:

pip uninstall PACKAGE

Previously, pacman had the --force option - if you specify it along with the install/update command, then it overwrites files already existing on the system.

There are situations when it is really necessary. But the maintainers of the distribution considered that the --force option only harm. And they removed it. It was replaced by the --overwrite <PATH> option. It overwrites conflicting files (can be used multiple times).

That is, according to the authors' idea, it should be used with each file separately, so that we have a clear idea of what exactly we are rewriting.

I ran into a situation where my OS stopped booting. I tried to uninstall GNOME Display Manager and found out that this package is considered to be NOT INSTALLED. Consequently, it could not be updated, and also some of its dependencies were removed as orphaned. That is, the system does not boot explicitly due to GDM, the easiest way to fix is to completely uninstall and do a clean install. But pacman doesn't uninstall GDM because it doesn't think it is installed. But on the other hand, when you try to install the gdm package, pacman does not allow you to install it, since the files of this package are present on the system.

Now it's time to use the --overwrite option, but there are a lot of GDM files and it is impossible to list them manually. In general, by experience, I found out that you can specify folders, for example:

sudo pacman -S --overwrite /usr/share/locale/* gdm

And to get a complete analog of --force, you need to specify it as “--overwrite '/*'”.

I ran the following commands to push install, complete uninstall and clean install of GNOME Display Manager:

sudo pacman -S --overwrite '/*' gdm
sudo pacman -Rn gdm
sudo pacman -S gdm

As a result, my problem was resolved. Do not overuse “--overwrite '/*'”, use this syntax only when you really understand what you are doing and when you are sure that there is no other way to remove interfering files - usually this can be done by third-party Python, PERL and others package managers - those the ones that installed these packages.

How to completely uninstall a package along with dependencies on Arch Linux (as well as BlackArch and Manjaro)

This tutorial uses pacman as the package management (uninstallation) program, but you can also use pikaur or yay instead, since the options discussed are the same for all these package managers.

Related: Automatic installation and update of AUR packages

A typical command to uninstall a program that will remove all package files:

sudo pacman -R PACKAGE

Indeed it will remove the specified package, but the configuration files of the package will remain, which will be renamed - the .pacsave extension has been added, and the dependencies that were installed for this package will remain.

To completely remove the program along with all its dependencies and without saving the configuration files, use a command like this:

sudo pacman -Rscun PACKAGE

This command uses the following options:

-c, --cascade

Remove all target packages, as well as all packages that depend on one or more target packages. This operation is recursive and must be used with caution as it can remove many potentially needed packages.

-n, --nosave

Instructs pacman to ignore backup configuration files. Usually, when a package is removed from the system, the database checks whether the configuration file should be renamed (the .pacsave extension is appended to it). When using this option, this does not happen - the configuration files are completely deleted.

-s, --recursive

Removes every specified target, including all its dependencies, provided that: (A) they are not required by other packages; and (B) they were not explicitly installed by the user. This operation is recursive and similar to the reverse --sync operation, and it helps to keep the system clean without orphans. If you want to skip condition (B), write the option twice.

-u, --unneeded

Removes targets that are not required by other packages. This is mostly useful when removing a group without using the -c option to avoid breaking any dependencies.

Loading...
X