Tag: apt

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.

Package configuration

Another option for reporting a new version of the configuration file:

Package configuration

  ┌──────────────────────────────────┤ Configuring privoxy ├──────────────────────────────────┐
  │ A new version (/etc/privoxy/config.ucftmp) of configuration file /etc/privoxy/config is   │ 
  │ available, but the version installed currently has been locally modified.                 │ 
  │                                                                                           │ 
  │ What do you want to do about modified configuration file config?                          │ 
  │                                                                                           │ 
  │                   install the package maintainer's version                                │ 
  │                   keep the local version currently installed                              │ 
  │                   show the differences between the versions                               │ 
  │                   show a side-by-side difference between the versions                     │ 
  │                   show a 3-way difference between available versions                      │ 
  │                   do a 3-way merge between available versions                             │ 
  │                   start a new shell to examine the situation                              │ 
  │                                                                                           │ 
  │                                                                                           │ 
  │                                          <Ok>                                             │ 
  │                                                                                           │

By default, the option “keep the local version currently installed” is selected. This is the best option if you want to keep your previous settings. To continue updating packages, press the “Tab” key, as a result you will switch to the “<Ok>” button.

And press the “Enter” key.

If you do not want to save the settings you made earlier, but want to get a new version of the configuration file, then use the cursor keys to select the “install the package maintainer's version” option. Then press “Tab” and “Enter” again.

Should I update configuration files in the /etc/default/ directory

A special case, in my opinion, is the /etc/default/ directory.

For example, the following screenshot shows that a request is being made to update the /etc/default/grub file.

As the name of the directory itself implies, it contains default configuration files, which, most likely, do not change even if you configured a particular service or program.

Therefore, by default, these configuration files can be updated, except in special cases when you specifically make changes to them.

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

dpkg: error: fgets gave an empty string from ‘/var/lib/dpkg/triggers/Unincorp’ (SOLVED)

When trying to use the apt package manager, for example:

sudo apt install linux-image-amd64

An error occurred:

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

The error is caused by disk problems or package upgrade failure.

When trying to use the recommended command:

sudo dpkg --configure -a

There was another error:

dpkg: error: fgets gave an empty string from '/var/lib/dpkg/triggers/Unincorp'
E: Sub-process /usr/bin/dpkg returned an error code (2)

To fix the issue, run the following commands:

sudo rm /var/lib/dpkg/triggers/Unincorp
sudo touch /var/lib/dpkg/triggers/Unincorp
sudo dpkg --configure -a

After that, run

sudo dpkg --configure -a

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.

Do services need to be restarted when updating packages

Package configuration: whether to restart the service

During the installation of package updates and their configuration, the apt program may ask you to restart the service:

There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you will normally be prompted on each upgrade for the list of services you wish to restart. You can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade. Restart services during package upgrades without asking?

This message can be confusing, especially the phrase “cause interruptions of service for the system”. In fact, the essence is quite simple – the binaries have been updated and you need to restart the services that use them so that they start using the updated versions of the files.

The name of the package that requires the service to be restarted is in the upper left corner, in the screenshot it is libc6, i.e. “GNU C Library: Shared libraries”. It contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others.

What kind of interruptions can a service restart cause?

Examples of the consequences of restarting services:

  • at the time of restarting the web server service, sites will be unavailable to users
  • when restarting the caching proxy server, the cache stored in RAM will be deleted
  • restarting network services can lead to connection drops (but in practice this does not always happen)

That is, the possible consequences of restarting services on the home computer are insignificant – you can safely restart.

As far as restarting services on a server, for example, restarting the SSH server usually doesn't break the connection. You need to evaluate the consequences of restarting other services based on your situation.

See also:

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:

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