Ubuntu apt исправить ошибки

Let’s understand this error with an example:

Assume this is the error message:

The following packages have unmet dependencies:
 nginx-module-brotli : Depends: nginx (= 1.17.3-2-ppa7~bionic)
E: Unable to correct problems, you have held broken packages.

Let’s break it down into variables:

X=nginx-module-brotli
Y=nginx
Z=1.17.3-2-ppa7~bionic

Here X is the package you are trying to install. Y is the package, which is causing dependency troubles (there may be multiple Ys) and Z is the version that is required.

So in a summary:

X needs the package Y with the version Z to work.

However, apt is facing troubles while finding the version Z for Y.

So, let’s check if version Z is available for the package Y. We can use apt-cache policy <package_name> to find the available versions for the package. For example:

 $ apt-cache policy nginx
libasound2:
  Installed: nginx_1.20.2-1~bionic
  Candidate: 1.2.2-2.1ubuntu2
  Version table:
 *** nginx_1.20.2-1~bionic 100
        100 /var/lib/dpkg/status
     1.17.3-2-ppa7~bionic 500
        500 http://br.archive.ubuntu.com/ubuntu focal/main amd64 Packages

Here, you can see two versions for the package nginx is available. The version required by X is Z. According to the version table, version Z for the package Y is available. But apt always installs the latest version (I know it’s a little dumb.) So there are two ways to fix this:

1. Install the correct package version.
2. Increase the aptitude of apt.

To install the correct package version use:

sudo apt update
sudo apt install <Y>=<Z>

Where is the package causing dependency troubles and is the version needed by X. Now, the installation should be successful.

To increase the aptitude of your package manager:

sudo apt update
sudo apt install aptitude
sudo aptitude -f install <Z>

Where is the package you are trying to install. Some useful tips with aptitude:

• -f option will do advance troubleshooting. It’s pretty useful!

• selecting n for a solution will make aptitude propose more solutions!

• Running man aptitude will show a detailed manual for using aptitude. Online manual.

Is the package version not available?

First, try running sudo apt update to update the repository list. Then try installing the package again.

Still not available?

You have two options:

1. Search for the package in https://packages.ubuntu.com/ and restore the default repositories.

2. Add custom PPAs to satisfy dependencies.

Searching package and restoring default repositories:-

1. Go to https://packages.ubuntu.com

2. Scroll down to the Search section.

3. In the Keyword column, enter the name of the package.

4. In the Distribution column, select the code name of your Ubuntu version (lsb_release -c).

5. Click on search!
   

6. Select the Exact Hit.
   

7. Check the version and repository for the package.
   

Check if the version needed and version available matches. If yes then refer to How do I restore the default repositories?

Adding a custom PPA.

You have to take help from Google for that. Just google up the package and version and hopefully you’ll find a PPA.

Some helpful commands:

• sudo apt -f install <package> to force install package.
• sudo aptitude -f install <package> To force install package.
• sudo add-apt-repository whatever/ppa to add a PPA.
• sudo apt purge <package> to remove a package.

I’m asking a new question, what information should I provide?

Information such as:

• Your Ubuntu version (output of lsb_release -d.
• Output of sudo apt install <package>
• Output of apt policy <package> and apt policy <package's dependency>

Other details should be provided when asked.

Предисловие

Используя APT-GET

E: Неудовлетворённые зависимости. Попытайтесь выполнить 'apt-get -f install', не указывая имени пакета, (или найдите другое решение).

sudo apt-get clean

sudo apt-get autoremove

sudo apt-get update

sudo apt-get -f install

sudo apt-get dist-upgrade

sudo apt-get install --reinstall имя_пакета

Linux package managers, like Apt and DNF, are extremely powerful and intuitive, but that doesn’t mean things can’t go wrong. Occasionally, a package install goes wrong, and you’re left to pick up the pieces. Package managers have the ability to fix broken packages and skip broken updates to get your system working again and avoid troubles in the future.

This article covers how to fix broken packages in Linux. These fixes should help you get unstuck in most instances.

Fixing Broken Packages in Ubuntu/Mint/Debian

Apt has a couple of flags to fix missing dependencies or packages that broke for one reason or another during install. A common use here would be installing a third-party .deb and finding that it had dependencies you didn’t know about. Those dependencies probably won’t be pulled in on their own, and dpkg will complain that it can’t resolve dependencies. In any case, you can try the following steps:

Note: learn how Apt works before attempting any of the fixes below.

1. Run an update to make sure there aren’t newer versions of the required packages:

 sudo apt --fix-missing update

1. Force Apt to look for and correct any missing dependencies or broken packages when you attempt to install the offending package again. This will install any missing dependencies and repair existing installs:

Fixing DPKG Configuration Issues

Another place where an error can pop up in package installations is the configuration process. Behind the scenes, dpkg takes care of this part, so when a package fails during configuration, dpkg is the tool to fix it.

1. Start by trying to force dpkg to reconfigure any broken or partially configured packages:

1. If that doesn’t solve the problem, take a more forceful approach. Start by listing any packages that dpkg marked as requiring a reinstall:

The above command will show you the packages that cause problems. For this next step, check and make sure that the packages marked for reinstall are really broken. Do a sudo apt reinstall and pay attention to which packages fail to reinstall.

1. For each package that fails to reinstall, get the name and forcibly remove the broken package:

sudo dpkg --remove --force-remove-reinstreq [package name]

1. Dpkg should now be clean. Do a cleanup with Apt:

sudo apt clean && sudo apt update

With any luck, that’ll get you back to where you started. It won’t get you the broken packages that you tried to install, but at least Apt will be functional again, and you can go back to using it to attempt to install the package you were originally trying to install and its dependencies.

Permanent DPKG Lock

There’s a less common issue with dpkg locks preventing you from doing anything. Every time you try to use Apt or dpkg, you get an error saying another application is already using it … when it isn’t.

It’s easy to delete the lock file preventing you from using Apt and getting back to doing what you need to. Sometimes these lock files remain in place after an install error or power outage, derailing the process and preventing the file from being removed automatically. In this case, you’ll need to do it yourself.

sudo rm /var/lib/apt/lists/lock

For good measure, delete the lock in the cache.

sudo rm /var/cache/apt/archives/lock

Warning: Before removing this lock, make sure that it’s not being used. In Ubuntu, there’s an updater that starts up together with the system that locks DPKG/APT when it’s searching for updates. If you’re unsure whether the updater is running, press your Win key to bring up the Activity Center and type “Software Updater,” then press Enter to open it.

If the updater says that it can’t run, and you have no terminals open with package managers running in the background, go ahead with the above instructions.

If instead of the broken packages issue you are facing an issue with the Software Center not working, we have the fixes.

Fixing Broken Packages in Fedora/CentOS/RHEL

Fixing broken packages in Fedora/CentOS/RHEL is a less common affair. dnf does really great work making sure packages are installed correctly. That said, it’s still not perfect, and things will sometimes get mixed up in package management.

Note: learn the differences between Fedora, CentOS and RHEL.

1. List Troublesome Packages

The command to sort this out on RHEL-based systems like Fedora is:

The -V option is to verify, meaning it will go through and compare information on the installed files with the information stored in the rpm database. Attaching -a to this just verifies all core packages. This is slightly unhelpful, as it will usually give you a long list of files, but it can give you somewhere to start if you’re having issues with a particular application.

For example, seeing something marked as “missing” in your terminal will tell you that there are missing files in that particular package.

2. Attempt a Reinstall

Run a dnf reinstall on any packages you see in that list that might be giving you trouble.

sudo dnf --refresh reinstall [package name]

That will set all metadata as expired, so it will crawl through every repository you have enabled and look for a new version of that package. If you find that there are broken dependencies with that package, DNF will probably complain and tell you to use the --skip-broken flag. This will just skip that package entirely and let you update your system normally.

3. The Last Resort – Remove Packages

If you’ve reached the point where you have to use --skip-broken to complete your updates, it’s more hygienic for your system to remove it entirely.

Remembering the name of the package you failed to properly reinstall, uninstall it:

sudo dnf remove [package name]

The worst that could happen here is that you end up removing a core part of your daily flow, such as your browser, forcing you to find an alternative.

Tip: learn how to use flatpak in Fedora to better manage your packages.

Fixing Broken Packages in Arch

Although Arch’s package manager has some similarities to the others listed here (i.e, it has a database lock file and pulls dependencies in a similar way), it’s an entirely different beast of its own when it comes to how its logic is structured. The first step in diagnosing your issue is to make sure that the repositories are up to date and attempt a full upgrade:

If your attempts to install your package or do a system upgrade are still ending in failure, we have to isolate the cause according to what the terminal told you:

Note: learn how pacman works before you attempt to fix it.

“Invalid or Corrupted Package”

Making changes to “pacman.conf” in any manner can cause issues that cause pacman to incorrectly label packages as corrupt. The most likely culprit here is a partial (“.part”) file in the package manager cache, and your solution is to remove it:

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

There’s always a chance that the package you’re trying to install is indeed corrupt and doesn’t provide valid metadata to Arch’s package manager. In that case, you’ll have to wait for the package maintainer to update it. If the package is installed on your system and causing problems during an upgrade, remove it with:

sudo pacman -Rns [package name]

“Unable to Lock Database”

Like Debian’s apt, Arch’s package manager makes a lock file during operations. If you experienced a power outage or pacman experienced a hard interrupt and couldn’t remove the lock, it’s very likely to leave behind a lock file.

First, find out if some process on your computer is still using the file:

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

In the image above, a process with ID 121497 is using the file lock. If you’re curious about the process and want more information, use ps:

In my case, another pacman instance owns the lock file. The safest way to remove the lock is to first kill that process:

Now that the process is dead, remove the lock file:

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

You’re good to go now!

“Conflicting Files/File Exists in Filesystem”

This happens during upgrades where pacman detects a conflict of ownership. Before fixing anything, pay attention to the path to the file that the package manager is complaining about.

To find out who owns the file:

pacman -Qo [path to the file]

If it’s owned by a user and not another package, just remove it:

sudo rm [path to the file]

If it’s owned by another package, the safest thing to do is wait for the package’s maintainer to fix this conflict themselves. Sometimes that’s not an option, though, and you want to get things done now.

The simplest way to accomplish this is using the --overwrite flag in pacman. Just know that this is generally unsafe and could lead to some applications not working correctly in your system. I suggest making a backup prior to running this.

The --overwrite flag allows Arch’s package manager to ignore ownership rules for a particular file and just steamroll through the update. Example:

sudo pacman -Syu --overwrite [file name]

If the above command doesn’t work, replace the file name with its absolute path. Some users have reported that removing the leading slash (“/”) in front of the path makes the command work when it’s being stubborn.

Alternatively, you could also just tell pacman to overwrite everything it needs to:

sudo pacman -Syu --overwrite='*'

“Invalid or Corrupted Package (PGP Signature)”

In some packages that are poorly maintained, the developer may not have the time or willingness to properly update the digital signature that certifies their package. This will eventually result in a message in your terminal while trying to install it, such as, “signature from [someone] is marginal trust,” followed by the package manager asking if you’d like to delete the file.

Because signature updates depend entirely on the maintainer, there’s nothing you can realistically do to fix the situation from your terminal. If you’re doing an update and want to keep the package, use the --ignore flag for that package in particular:

sudo pacman -Syu --ignore [package name]

If you get this for many packages, your keyring might be out of date. Update it with:

sudo pacman -S archlinux-keyring

Frequently Asked Questions

Image credit: Flickr. All screenshots by Miguel Leiva-Gomez.