Tag: package managers

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
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.

Is it safe to remove configuration files left over from removed packages? (SOLVED)

What does the package status “[residual-config]” mean?

When searching the package repository using the apt utility, you may encounter programs that have a status like this instead of “installed” or not installed.


See also: How to check if a package is installed on Linux Mint

There can be quite a lot of such files.

This raises the question: is it safe to delete such files, will this lead to unexpected failures in the programs? If these files can be removed, then how can this be done for all packages whose configuration files remain in the system at once?

apt autoremove”, as well as “apt clean” and “apt autoclean”, do not help to remove these files because the packages have already been removed.

Is it safe to delete settings files

To begin with, we note that if the package has the status “[residual-config]”, then it has already been removed and, therefore, cannot work. For this reason, deleting its configuration file will mean that if you want to install the same package in the future, you may need to configure the package again.

To display a list of packages that have been removed from the system, but for which configuration files remain, run the program:

dpkg -l | grep '^rc' | awk '{print $2}'

I ended up with a rather long list that didn't even fit on the screen. That said, most of the list is made up of packages that I never want to install again: previous versions of the kernel, previous versions of PHP, previous versions of the MariaDB server and client.

However, upon closer examination of the list, I found phpMyAdmin in it, which I installed and actually use. That is, this package was removed automatically, most likely during a major update of the PHP version. So not only do I not want to delete the phpMyAdmin config files, I re-installed the package. That is, do not rush to mindlessly remove the configuration files of missing packages – at least take a quick look at it.

Note that a package with the status “[residual-config]” is considered to be installed even if any of its files other than configuration files are missing. In a practical sense, this means that the dependencies of these already removed packages are still stored in the system. Therefore, after clearing the configuration files, the package is considered permanently removed. And this can lead to the fact that the dependencies that were installed automatically are no longer required. For this reason, launch

sudo apt autoremove

may cause packages to be removed.

This is usually not a problem as it removes automatically installed packages that are no longer needed by any of the programs. But if there are packages that are no longer needed, check the list of configuration files to clean up even more carefully – there may be something useful there, as in my case it was phpMyAdmin.

How much space will be freed up when clearing settings files

As for the question of how much this is necessary, users have different opinions. One user wrote that deleting the configuration files for 342 missing packages freed him up to just 2.6 MiB. Other users report that the configuration files filled up all the free space in the root directory. In fact, configuration files usually take up very little space and you shouldn't expect to free up a lot of disk space after deleting them.

Why settings files remain

This is not a mistake – the settings files of remote applications are saved intentionally. On Linux, installing a package from a repository can be done with a single command. But the subsequent setup, which may involve editing the configuration file, can take a long time. For this reason, the apt command has two kinds of program uninstalls:


Removes packages. Note that when a package is removed, its configuration files remain on the system.


purge is similar to remove except packages are removed and purged (any configuration files are also removed).

Thus, when you remove packages, usually using “sudo apt remove”, programs leave their configuration files on the system.

How to remove all configuration files for missing packages at once

To clear all configuration files, use the following command:

dpkg -l | grep '^rc' | awk '{print $2}' | xargs sudo apt --purge --yes remove

Do not forget to review the list of affected packages before running it, as shown above – it may turn out that, for reasons beyond your control, the packages you need were removed and you don’t want their configuration files to be removed at all.

While cleaning configuration files, you may encounter messages like:

dpkg: warning: while removing php7.3-cli, directory '/etc/php/7.3' not empty so not removed


rmdir: failed to remove '/lib/modules/5.10.0-kali4-amd64': Directory not empty

This means that these directories, in addition to the configuration files of the package, contain extraneous files. In all these cases, you need to remove the specified directories manually.

Updating packages: whether to update the config file

Consider a situation when the package manager of your Linux distribution (Debian, Linux Mint, Ubuntu, Kali Linux) asks about updating the configuration file – what to do and how to get the latest version of the configuration file? Let’s figure it out.

With some updates of some packages, the structure of the configuration file changes. As a rule, the new file contains directives and settings that are necessary for the new version of the program, without which it cannot work.

Setting up a services is almost always changing configuration files. The end file can be the result of lengthy configuration work and many tests. This can take hours or even days.

Therefore, if it is necessary to update the configuration, a dilemma arises:

  • do not update the config, as a result of which the new version of a package will not work normally
  • update config and erase service configuration results

It is for this reason that the system asks you every time what needs to be done if the configuration file is updated with the program update?

An example of a message in which the package manager asks what to do with the new config file:

Configuration file '/etc/squid/squid.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** squid.conf (Y/I/N/O/D/Z) [default=N] ? 

The options are:

  • Y or I – install a new config file
  • N or O – save the currently used config file
  • D – show differences between versions
  • Z – open the shell to examine the situation

The default option is to save the current config file (N).

If in reality you have not used this program, or the settings made are of no value to you, then always agree to update the configuration file. If the settings made are important to you, then:

  • refuse to update the config file
  • make a backup copy of your config, update the config file to the new version, and then make the necessary settings in it

For some packages, like Tor, the config file is just a set of comments with no setting active – for such files (if you haven't changed them), the update is more of a formality.

How to view the new config file

Typically, system administrators and users save the current configuration file. But how do you view the new file? After all, it is quite possible that there are important changes in it.

One way to do this is to download the latest version of a package and see the configuration file for the latest version in that package.

Download the package with a command like:

apt download PACKAGE

For example, to download the squid package

apt download squid

Unpack the downloaded installation file with a command like:

ar x FILE.deb

For example:

ar x squid_5.1-2_amd64.deb

Now we need to unpack a file called data.tar.gz or data.tar.xz.

Look at the contents of the folder to find out the name of the file:

ls -l

If the file has a .tar.gz extension, then the command is as follows:

tar xzf data.tar.gz

If the file has the extension .tar.xz, then the command is as follows:

tar xf data.tar.xz

Let's check the contents of the current directory again in search of unpacked folders and files:

ls -l

Configuration files on the system are usually placed in the /etc/ directory, when you unpack the package, you will find this folder under the path ./etc/ (that is, in the current folder).

For example, the command to view the configuration file of the latest version of the squid package I am interested in:

gedit ./etc/squid/squid.conf

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:

:: 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):

Include = /etc/pacman.d/mirrorlist

Update package information:

sudo pacman -Sy

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

How to simulate package installation on Linux (How to create and install a dummy package)

Sometimes, when installing packages from source code, you may encounter the problem that the required dependency is missing from the system. Usually you need to solve this problem by installing the necessary dependencies from the standard repository, or by compiling them from source.

Sometimes the required package is present, but its version is not suitable, a similar example and solution is described in the article “How to install a package for which there is no dependency of the required version”.

But I ran into a situation where the required dependency is:

a) does not exist at all (the package was removed from the package repository)

b) functionality has been moved to another package that can be installed

Take a look at the following message:

Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 detectiteasy : Depends: qt5-default but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

The program installed from source requires the qt5-default package. This package contains one single configuration file. The package itself was removed as unnecessary or due to the fact that its functionality was transferred to the qtchooser package that I installed. That is, from a practical point of view, the dependency is not needed, but I cannot update the system, because, as the package manager thinks, the dependencies are broken.

The way out of this situation is to install a dummy package.

How to create and install a dummy package on Linux (Debian, Linux Mint, Kali Linux, Ubuntu)

There is a Debian package called equivs that can create fake packages. Install it by running

sudo apt install -y equivs

Due to unresolved dependencies, I was unable to install the equivs package on the problematic OS – I used another computer to help.

After installation, you create a “control” template file using the following command:

equivs-control FILE_NAME

For example:

equivs-control qt5-default

Alternative package name can be used like postfix-custom for postfix or something else.

Let's open the generated file for editing:

gedit qt5-default

An example of the content in my case:

### Commented entries have reasonable defaults.
### Uncomment to edit them.
# Source: <source package name; defaults to package name>
Section: misc
Priority: optional
# Homepage: <enter URL here; no default>
Standards-Version: 3.9.2

Package: <package name; defaults to equivs-dummy>
# Version: <enter version here; defaults to 1.0>
# Maintainer: Your Name <yourname@example.com>
# Pre-Depends: <comma-separated list of packages>
# Depends: <comma-separated list of packages>
# Recommends: <comma-separated list of packages>
# Suggests: <comma-separated list of packages>
# Provides: <comma-separated list of packages>
# Replaces: <comma-separated list of packages>
# Architecture: all
# Multi-Arch: <one of: foreign|same|allowed>
# Copyright: <copyright file; defaults to GPL2>
# Changelog: <changelog file; defaults to a generic changelog>
# Readme: <README.Debian file; defaults to a generic one>
# Extra-Files: <comma-separated list of additional files for the doc directory>
# Links: <pair of space-separated paths; First is path symlink points at, second is filename of link>
# Files: <pair of space-separated paths; First is file to include, second is destination>
#  <more pairs, if there's more than one file to include. Notice the starting space>
Description: <short description; defaults to some wise words> 
 long description and info
 second paragraph

The lines with comments indicate which defaults will be applied when creating the package – you can delete these lines or uncomment and specify your own value.

Also in the line “Package” enter the name of the package, I got it like this:

Section: misc
Priority: optional
Standards-Version: 5.15.2+dfsg-7
Version: 5.15.2
Package: qt5-default

The “Provides” line indicates that my package provides the capabilities offered by another package that one is trying to spoof.

Finally, after generating the template control file, use the equivs-build command to create a fake package like


In my case, this is:

equivs-build qt5-default

It will take a few seconds to build the package and then you can run

sudo dpkg -i PACKAGE_NAME*.deb

For example, in my case, after transferring the package to the problem system, the command is as follows:

sudo dpkg -i qt5-default_5.15.2_all.deb

After installing the package, the work of the package manager returned to normal – it is again possible to install and remove packages, update the system.

For advanced users, if your template control file has the “Requires” line, you can create metapackages to install a group of programs.

See also:

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.

Warning: apt-key is deprecated (SOLVED)

The apt-key command manages keys that are responsible for verifying the signature of application package repositories.

Now, whenever you use the apt-key command, you will receive the message:

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

It means that the apt-key program is now deprecated. Now we should use trusted.gpg.d to manage keyfiles. Translated into human language, now we have to add files ourselves to the /etc/apt/trusted.gpg.d/ folder.

This method will use the /etc/apt/trusted.gpg.d/ directory to store the public GPG key ring files. It has been available since early 2017.

If you look at the recommended man page (man apt-key), it says that this command and all its functions are deprecated.

There are two options for how you can proceed in this situation.

You can continue to use apt-key

Despite the assurances in the documentation, the apt-key program works as usual and performs all its functions.

At the same time, the apt-key command will not be removed for quite a long time, at least several years. It may not be removed at all for compatibility.

Therefore, basically, you can ignore the warning “apt-key is deprecated”.

How to add keys in a new way

The new “modern” version is poorly documented, let's try to fill this gap.

Now the keys need to be added with the following commands.

If a remote key file is added:

curl -s URL | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/NAME.gpg --import

If a local key file is added:

cat URL.pub | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/NAME.gpg --import

In these commands, you need to substitute:

  • URL - address of the .pub file
  • NAME - you can choose any file name
  • FILE - filename of the .pub file

Then be sure to run the following command to set the correct file permissions:

sudo chmod 644 /etc/apt/trusted.gpg.d/NAME.gpg

Example. If you already know the URL of the required public key, use wget or curl to download and import it. Remember to update the file permissions from 600 to 644.

curl -s https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/earth.gpg --import
sudo chmod 644 /etc/apt/trusted.gpg.d/earth.gpg

Alternatively, you can get the key from the keyserver:

sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/rabbit.gpg --keyserver keyserver.ubuntu.com --recv 6B73A36E6026DFCA
sudo chmod 644 /etc/apt/trusted.gpg.d/rabbit.gpg

How to view information about installed keys

To view information about the installed key, run a command of the form:

gpg --list-keys --keyring /etc/apt/trusted.gpg.d/FILE.gpg

For instance:

gpg --list-keys --keyring /etc/apt/trusted.gpg.d/earth.gpg

As said, the old command also works:

apt-key list

How to remove a key added by a new method

If you need a command analogue:

sudo apt-key del 7D8D08F6

Now, to remove the key, simply delete the file with commands like:

cd /etc/apt/trusted.gpg.d/
sudo rm NAME.gpg

But “apt-key del” also works.

How to remove a key added with apt-key add

If you want to delete individual keys, then use a command like this:

sudo apt-key del KEY_ID

To find out the KEY_ID, run the command

apt-key list

find the key you want, for example:

pub   rsa4096 2016-04-12 [SC]
      EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
uid         [ неизвестно ] Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
sub   rsa4096 2019-07-22 [S] [   годен до: 2022-07-21]

Look at the sequence of numbers and letters in the pub field - this is a hash. In this example, we are interested in the line

      EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796

To delete this key, you need to run the command (note that spaces have been removed from the hash):

sudo apt-key del EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796

How to remove all keys added with apt-key add

Just delete the /etc/apt/trusted.gpg file:

sudo rm /etc/apt/trusted.gpg