Администрирование Linux-серверов

Не устанавливаются пакеты в Linux: блокировки, dpkg и зависимости

Как найти причину ошибки APT или DNF: активную транзакцию, незавершённый dpkg, конфликт версий, удержание пакета или несовместимые репозитории.

15 минут
абстрактная иллюстрация диагностики конфликтов пакетов Linux
Не удаляйте файлы блокировки и не игнорируйте зависимости: сначала найдите владельца транзакции и причину конфликта.
Ошибка установки или обновления пакета не означает, что нужно немедленно удалять lock-файл или запускать принудительную установку. Сначала сохраните полный текст ошибки и команду, определите пакетный стек: APT и dpkg для Debian-подобных систем либо DNF или YUM, в зависимости от выпуска, и RPM для RHEL-подобных. Затем проверьте активную пакетную транзакцию, состояние базы, доступные версии и источники пакетов; только после этого применяйте штатное восстановление.

Сначала зафиксируйте ошибку и определите пакетную систему

Сохраните команду, полный вывод и время сбоя до повторных попыток. Последующие apt install пакет, dnf update или перезапуск автоматического задания могут изменить состояние и затруднить диагностику. Узнать семейство и выпуск ОС обычно можно по /etc/os-release: Debian и Ubuntu Server используют DEB, dpkg и APT. Современные выпуски RHEL, Rocky Linux, AlmaLinux и CentOS Stream используют RPM и DNF; в старых RHEL-подобных выпусках основным высокоуровневым инструментом может быть YUM.

Показывает идентификатор и версию дистрибутива. По ним выбирают документацию и команды именно для целевого выпуска.
cat /etc/os-release

DEB- и RPM-системы используют разные базы, форматы пакетов и средства диагностики.

СимптомЧто это может означатьПервое действие
Could not get lock, Unable to acquire the dpkg frontend lockДругая APT/dpkg-транзакция, автоматическое обновление, ошибка доступа или состояние после сбояНайти процесс-владелец и его источник; не удалять файл блокировки
dpkg was interruptedПредыдущая операция дошла до распаковки, но не завершила настройку пакетовИсключить параллельную транзакцию, проверить dpkg --audit
Unable to correct problems, held broken packagesНедоступна подходящая версия, действует hold/pinning или смешаны источники APTСравнить кандидата, версии и репозитории
Error: Transaction test error, conflicting requests в DNFКонфликт RPM-версий, сторонний репозиторий, исключение пакета или несовместимый выпускПроверить установленные и доступные версии, репозитории, историю и ограничения
Ошибка блокировки DNF/RPMАктивный DNF, RPM или управляющий им сервис; реже — последствия аварийного завершения или проблема доступаУстановить процесс и объект, на котором он ожидает блокировку

Не переносите команды между экосистемами

DEB-пакет, dpkg и APT не являются аналогами RPM один к одному. Команды и файлы состояния Debian/Ubuntu не следует применять на RHEL-подобной системе, и наоборот. Обычные операции установки описаны отдельно: APT в Ubuntu и Debian: установка, обновление, удаление и очистка пакетов и DNF и YUM: установка, обновление и удаление пакетов.

Ошибка блокировки APT, DNF или RPM: найдите владельца

Блокировка менеджера пакетов нужна, чтобы две операции не меняли пакетную базу одновременно. Владелец может быть законным: интерактивный администратор в другой SSH-сессии, автоматическое обновление, задача Cron, systemd timer, средство конфигурационного управления или сценарий развёртывания. Сообщение об ошибке часто называет файл либо другой объект блокировки и иногда PID процесса — это отправная точка, а не повод удалять объект.

Как проверить процесс, удерживающий пакетную блокировку

Подставляйте путь из фактического сообщения об ошибке. Команды выполняйте с правами, достаточными для просмотра процессов и открытых файлов.

  1. 1
    Найдите PID в тексте ошибки
    Если APT, DNF или RPM указал PID, проверьте его командную строку, владельца и время запуска. PID отсутствует или уже не существует — не считайте блокировку автоматически устаревшей: переходите к проверке объекта и журналов.
  2. 2
    Проверьте процесс и его родителя
    Команда ps показывает, запущен ли процесс и кем. Родительский процесс помогает отличить ручной запуск от службы, таймера, агента автоматизации или сценария.
  3. 3
    Проверьте, кто использует объект из ошибки
    Если ошибка называет путь, fuser может показать процессы, работающие с этим объектом. Утилита может отсутствовать в минимальной системе; не устанавливайте её через тот же заблокированный менеджер пакетов ради этой проверки.
  4. 4
    Установите источник запуска
    Проверьте родительскую цепочку, активные systemd units, таймеры и журналы за время начала процесса. Для systemd-службы сначала выясните её назначение и расписание, затем решайте, можно ли ждать или останавливать работу.
Замените `<PID>` числом из ошибки. Ожидаемый результат — строка с пользователем, временем запуска и командой. Если PID не найден, зафиксируйте это вместе с исходной ошибкой.
ps -fp <PID>; ps -o pid,ppid,user,lstart,etime,args -p <PID>
Показывает PID процессов, использующих указанный объект. Пустой вывод не доказывает, что состояние можно безопасно удалять: блокировка и база могут быть реализованы иначе в другой версии пакетного стека.
sudo fuser -v <путь-из-сообщения-об-ошибке>
Показывает цепочку предков указанного процесса и помогает увидеть systemd, shell, cron или агент автоматизации, запустивший пакетный инструмент. Если `pstree` отсутствует в минимальной системе, используйте PPID из вывода `ps` и последовательно проверяйте каждый родительский процесс через `ps -fp <PPID>`; не устанавливайте утилиту через заблокированный менеджер пакетов.
pstree -aps <PID>

Работающую штатную транзакцию обычно лучше дождаться, особенно если процесс выполняет настройку пакетов, обновляет критичные компоненты или работает в согласованном окне обслуживания. Остановка допустима только когда установлен владелец и источник запуска, понятны последствия для приложения и есть основание считать задачу зависшей либо ошибочно запущенной. Если процесс принадлежит systemd-службе, останавливают управляющий unit штатным способом, а не посылают сигнал дочернему dpkg, dnf или rpm. Подробности диагностики расписаний — в статье Cron и systemd timers: задачи по расписанию и диагностика сбоев.

Почему нельзя просто удалить lock-файл

Удаление файла не завершает работающий процесс и не отменяет его операции записи. В результате две транзакции могут одновременно менять базу пакетов и файлы системы. Расположение, роль и даже наличие видимых lock-файлов зависят от версии APT, dpkg, DNF, RPM и дистрибутива; сообщение может быть связано также с правами доступа, а не с «забытым» файлом. Не редактируйте вручную базы dpkg или RPM и не используйте rm как универсальное исправление.

Если активного владельца не найдено, это ещё не доказательство безопасной «старой» блокировки. Проверьте, не завершился ли только что сервис, не идёт ли операция в контейнере или другой области видимости процессов, не было ли перезагрузки, нехватки места, ошибки ввода-вывода либо аварийного завершения. Дальнейшие действия сверяйте с официальной документацией пакетного менеджера и конкретного выпуска ОС. Пути журналов и глубина истории зависят от дистрибутива, настроек и версий; системные записи удобно отбирать по времени и unit через journalctl.

dpkg was interrupted: как завершить незавершённую настройку

Сообщение dpkg was interrupted означает, что предыдущая операция dpkg не завершилась штатно и часть пакетов может быть распакована, но не настроена. Причиной бывают прерванная сессия, выключение сервера, сбой сценария настройки, нехватка места или конфликт зависимостей. Это не обязательно повреждение базы и не повод вручную менять её содержимое.

Порядок восстановления DEB-транзакции

Начинайте только после проверки, что другой APT/dpkg-процесс не выполняет транзакцию.

  1. 1
    Проверьте незавершённые и проблемные пакеты
    Запустите dpkg --audit. Он выводит пакеты, которые требуют действий, например не настроены или имеют неполное состояние. Сохраните вывод: он укажет, какой пакет или сценарий нужно исследовать, если автоматическая настройка не пройдёт.
  2. 2
    Завершите настройку штатным средством dpkg
    Команда dpkg --configure -a пытается настроить все распакованные, но ещё не настроенные пакеты. Она не загружает недостающие пакеты из репозиториев и может остановиться на реальной ошибке сценария настройки.
  3. 3
    Проверьте зависимости APT
    После успешного завершения или при сообщении о недостающих зависимостях используйте apt check. Команда диагностирует проблемы в зависимостях, но не исправляет их.
  4. 4
    Рассмотрите исправление зависимостей
    apt --fix-broken install может предложить установить требуемые пакеты, настроить ранее распакованные либо удалить конфликтующие. До подтверждения прочитайте весь план. Если предлагается удалить критичный системный компонент, переходить на другой выпуск или затрагивать приложение без согласованного окна — остановитесь и исследуйте источники и версии.
Диагностика состояния базы dpkg. Пустой вывод обычно означает, что dpkg не видит пакетов, требующих аудита, но не доказывает отсутствие проблем в репозиториях или прикладной конфигурации.
sudo dpkg --audit
Пытается завершить конфигурацию всех распакованных, но ненастроенных пакетов. Не запускайте при активной параллельной транзакции.
sudo dpkg --configure -a
Проверяет целостность зависимостей с точки зрения APT. При ошибке сохраните названия пакетов и требуемые версии перед исправлением.
sudo apt check
Формирует транзакцию для исправления нарушенных зависимостей. Подтверждайте её только после проверки списка установок, обновлений и удалений.
sudo apt --fix-broken install

Остановитесь при ошибке сценария настройки

Если dpkg --configure -a снова завершается на конкретном сценарии postinst, который пакет выполняет после установки, запуске службы, нехватке места, ошибке файловой системы или несовместимости приложения, не повторяйте команду бесконечно и не обходите проверку зависимостей. Зафиксируйте вывод и журналы, устраните подтверждённую первопричину либо обратитесь к документации поставщика проблемного ПО.

Зависимости пакетов Linux в APT: кандидат, источник, hold и pinning

Зависимость пакета не разрешается, когда требуемой версии нет среди доступных, она несовместима с уже установленными пакетами либо запрещена политикой выбора версий. Типичные причины: отключённый или устаревший репозиторий пакетов, смешение выпусков Debian/Ubuntu, сторонний PPA или локально установленный пакет, удержание пакета, а также закрепление версии пакета.

Показывает установленную версию, Candidate и доступные версии вместе с их источниками. Если Candidate равен `(none)` или нужной версии нет, проблема обычно не решается повтором `apt install`.
apt-cache policy <пакет>
Без имени пакета показывает приоритеты источников, известных APT. Используйте вывод вместе с конфигурацией источников, чтобы заметить неожиданный выпуск или внешний репозиторий.
apt-cache policy
Выводит пакеты, удерживаемые средствами APT. Отсутствие пакета в выводе не исключает pinning или ограничения, заданные другой политикой.
apt-mark showhold

Pinning задаётся конфигурацией APT и правилами приоритетов конкретной системы; обычно проверяют основной файл preferences и фрагменты preferences.d, а также списки источников. Не снимайте hold и не меняйте pinning только для прохождения одной транзакции: сначала выясните, для какой совместимости или политики они были заданы. После изменения источников обновите индекс пакетов, затем снова сравните apt-cache policy для конфликтующих пакетов.

Для расследования также полезны журналы APT и dpkg, но их имена и расположение различаются. Во многих Debian-подобных системах встречаются история APT и журнал dpkg в /var/log, однако это не универсальный контракт. Сопоставляйте время ошибки с историей транзакций, выводом автоматического обновления и системным журналом.

Ошибка зависимостей DNF: версии, репозитории и исключения

В RPM-системе DNF рассчитывает транзакцию по установленным RPM-пакетам и метаданным включённых репозиториев. Конфликт часто появляется после подключения стороннего репозитория, установки RPM не из штатного источника, частичного обновления, смены основного выпуска или исключения нужного пакета. В старых выпусках может использоваться самостоятельный YUM, а в более новых команда yum может служить совместимым интерфейсом к DNF. Доступные подкоманды и формат вывода зависят от дистрибутива и версии.

Диагностика конфликта зависимостей DNF

Команды ниже не изменяют состав пакетов, кроме возможного обновления метаданных, если оно настроено в системе.

  1. 1
    Проверьте согласованность установленных пакетов
    dnf check ищет проблемы зависимостей и дубликаты в установленном наборе. Сохраните вывод с полными именами пакетов, архитектурой и версиями.
  2. 2
    Сравните доступные версии и источник
    dnf info --showduplicates <пакет> помогает увидеть версии, доступные из включённых репозиториев. Сверяйте их с версией, упомянутой в конфликте, и с установленной версией.
  3. 3
    Проверьте включённые репозитории и историю
    dnf repolist --enabled показывает набор источников, участвующий в расчёте. dnf history list и dnf history info <ID> позволяют установить, после какой транзакции появился конфликт.
  4. 4
    Проверьте исключения и versionlock
    Ищите ограничения в конфигурации DNF, параметрах запуска и подключённых плагинах. Для versionlock сначала убедитесь, что плагин установлен и поддерживается в данном выпуске; затем используйте его справку и список правил.
Проверяет установленный набор RPM на проблемы зависимостей и дубликаты. Вывод не объясняет автоматически, какой репозиторий следует отключить или какую версию заменить.
sudo dnf check
Показывает доступные версии указанного пакета и связанные с ними сведения. Возможности и представление источника зависят от версии DNF.
dnf info --showduplicates <пакет>
Первая часть показывает включённые репозитории, вторая — историю DNF. Для подробностей конкретной записи используйте `dnf history info <ID>`.
dnf repolist --enabled; dnf history list
Показывает правила versionlock, если соответствующий плагин установлен и команда доступна. В RHEL-подобных системах механизм, пакет плагина и поведение зависят от выпуска, версии DNF и подключённых репозиториев.
dnf versionlock list

Ограничения версий в DNF могут действовать не только через versionlock: на расчёт влияют исключения пакетов в конфигурации или профиле репозитория, параметры запуска наподобие исключения пакета, включённые и выключенные репозитории, а также модульные потоки в тех выпусках, где они используются. Поэтому отсутствие versionlock не означает отсутствия ограничений.

Не используйте distro-sync как универсальное лечение

dnf distro-sync синхронизирует установленные пакеты с версиями, доступными из включённых репозиториев. В зависимости от рассчитанной транзакции он способен понижать, обновлять, устанавливать, заменять или удалять пакеты. Операция может быть уместна только после подтверждения, что набор репозиториев относится к одному поддерживаемому выпуску и именно он является целевым состоянием. Сначала просмотрите план; на рабочем сервере учтите окно работ, проверку приложения и резервную копию по регламенту.

Перед подтверждением транзакции: что должно остановить работу

Любая команда восстановления может сформировать транзакцию с установкой, обновлением, понижением версии или удалением пакетов. Прочитайте список целиком до подтверждения, особенно изменения ядра, загрузчика, сетевого стека, SSH, systemd, libc, базы данных и пакетов приложения. Сам факт, что менеджер пакетов нашёл математически допустимый набор зависимостей, не подтверждает совместимость приложения.

  • Остановитесь, если APT или DNF предлагает удалить критичные системные компоненты либо большое число пакетов, не связанных с исходной задачей.
  • Не продолжайте при признаках смешения разных основных выпусков, Debian и Ubuntu, RHEL-совместимых систем или сторонних репозиториев без подтверждённой совместимости.
  • Отложите автоматическое исправление, если выпуск достиг EOL, штатные репозитории недоступны или пакет приложения требует определённой версии от поставщика.
  • Не обходите конфликт ключами игнорирования зависимостей, принудительной заменой RPM/DEB или отключением проверки подписей.
  • На рабочем сервере сохраните вывод, определите допустимый простой и критерии проверки приложения; плановое обновление ядра и откат рассматривайте отдельно в статье Обновление Linux-сервера: пакеты, ядро, перезагрузка и откат.

Если проблема связана с окончанием поддержки CentOS Linux или переходом между семействами ОС, смена репозиториев ради одной ошибки зависимостей не является безопасным исправлением. Сначала определите статус и сценарий: CentOS Stream и CentOS 7: статус поддержки, различия и выбор сценария. Плановую миграцию рассматривайте отдельно: Переход с CentOS на Rocky Linux или AlmaLinux.

Термины в статье

Блокировка менеджера пакетов — механизм взаимного исключения, сериализующий установку, обновление и удаление пакетов для сохранения согласованности пакетной базы и файлов.
Зависимость пакета — требование пакета к другому пакету или его версии, без выполнения которого установка, запуск либо корректное обновление ПО невозможны или ограничены.
Закрепление версии пакета — политика APT, назначающая предпочтение или запрет определённым версиям, выпускам дистрибутива либо источникам пакета.
Индекс пакетов — набор метаданных репозитория, содержащий сведения о версиях, зависимостях, архитектурах и расположении доступных пакетов.
Кэш пакетов — локально сохранённые менеджером пакетов архивы пакетов и, в зависимости от реализации, метаданные репозиториев для повторного использования.
Менеджер пакетов — средство установки, обновления, удаления и учёта программных пакетов; высокоуровневые менеджеры также работают с репозиториями и разрешают зависимости.
Пакетная транзакция — согласованный набор действий по установке, обновлению, удалению и настройке пакетов, формируемый менеджером пакетов в рамках одной команды или задания.
Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Репозиторий пакетов — структурированный источник пакетов и метаданных, из которого менеджер пакетов получает версии ПО, зависимости, обновления и информацию о подписях.
Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Удержание пакета — состояние пакета, запрещающее менеджеру пакетов автоматически устанавливать, обновлять, удалять или менять его версию.
AlmaLinux — корпоративный дистрибутив Linux, поддерживаемый сообществом и AlmaLinux OS Foundation, ориентированный на совместимость с интерфейсами и экосистемой RHEL.
APT — система управления пакетами в Debian-подобных Linux, которая получает пакеты из репозиториев, разрешает зависимости и передаёт установку низкоуровневому менеджеру dpkg.
CentOS Linux — прекращённый свободно доступный дистрибутив Linux, создававшийся из исходных пакетов RHEL и ориентированный на бинарную совместимость с соответствующим выпуском RHEL.
CentOS Stream — дистрибутив Linux с непрерывной поставкой пакетов, формирующих следующую минорную версию Red Hat Enterprise Linux; он расположен между Fedora и RHEL.
DEB-пакет — архивный формат распространения ПО в Debian-совместимых Linux, содержащий файлы программы, метаданные и сведения о зависимостях.
Debian — универсальный дистрибутив Linux с пакетами DEB и системой APT, известный консервативной веткой Stable и разделением репозиториев по веткам разработки.
DNF — менеджер пакетов для RPM-дистрибутивов, разрешающий зависимости и выполняющий операции с репозиториями; в современных системах он заменил классический YUM.
dpkg — низкоуровневый менеджер пакетов Debian, устанавливающий пакеты из локальных .deb-файлов, удаляющий установленные пакеты и ведущий их базу без загрузки зависимостей из репозиториев.
PID — числовой идентификатор экземпляра процесса, назначаемый ядром Linux для его адресации; после завершения процесса номер может быть использован повторно.
PPA — размещённый в Launchpad репозиторий DEB-пакетов для отдельных выпусков Ubuntu, который подключается к APT как дополнительный источник.
RHEL — корпоративный дистрибутив Linux от Red Hat с фиксированными основными версиями, сертификационной экосистемой и моделью сопровождения, зависящей от подписки.
Rocky Linux — корпоративный дистрибутив Linux, создаваемый из исходных пакетов экосистемы RHEL и ориентированный на совместимость с RHEL без использования его товарных знаков.
RPM-пакет — файл формата RPM для распространения бинарного ПО или исходного кода. Он содержит метаданные и обычно полезную нагрузку; зависимости и сценарии необязательны.
SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
systemd timer — юнит systemd, который по календарному или монотонному расписанию активирует другой юнит, по умолчанию одноимённый сервис.
Ubuntu Server — серверный вариант дистрибутива Ubuntu на базе Debian с APT и типовыми средствами автоматизации, доступный в виде установочных и готовых образов.
YUM — менеджер пакетов для RPM-дистрибутивов Linux, который устанавливает, обновляет и удаляет ПО, автоматически разрешая зависимости из репозиториев.

Вопросы по теме

Все вопросы и ответы

Поможет ли очистка кэша при ошибке зависимостей?

Не обязательно. Кэш пакетов и метаданные могут быть одной из причин, но конфликт чаще связан с версиями, репозиториями, удержаниями или сторонними пакетами. Сначала сравните кандидаты и источники.

Можно ли откатить проблемную транзакцию DNF через history undo или rollback?

История DNF помогает исследовать изменение и в некоторых случаях сформировать обратную транзакцию, но не гарантирует возврат всех зависимостей и данных приложения. Доступность и результат зависят от версии DNF, репозиториев и того, доступны ли прежние пакеты. Перед применением изучите предлагаемый план.

Можно ли сразу повторить apt install после ошибки?

Нет, сначала сохраните команду, полный текст ошибки и время сбоя. Повторный apt install может изменить состояние пакетов и усложнить диагностику, особенно если параллельно работает автоматическое обновление или предыдущая операция не завершилась. Сначала определите причину: блокировку, незавершённый dpkg, недоступную версию или конфликт источников.

Можно ли удалить lock-файл при ошибке Could not get lock APT?

Сначала убедитесь, что блокировку действительно удерживает процесс пакетного менеджера. Если ошибка содержит PID, проверьте его команду, пользователя и время запуска через ps; цепочку запуска можно увидеть через pstree или последовательно проверить PPID. Если в сообщении указан путь к объекту блокировки, используйте fuser -v <путь> для поиска процессов, работающих с ним.

Штатную транзакцию обычно безопаснее дождаться, особенно если она настраивает пакеты или обновляет критичные компоненты. Останавливать задачу можно только после выяснения её владельца, источника запуска и последствий для приложения. Если процесс запущен systemd-службой, останавливают управляющий unit, а не дочерний dpkg, dnf или rpm.

Отсутствие видимого процесса не доказывает, что блокировка устарела: операция могла только что завершиться, выполняться в контейнере или пострадать после сбоя, нехватки места либо ошибки ввода-вывода. Ручное удаление lock-файлов и редактирование баз dpkg или RPM не являются универсальным исправлением.

Что делать, если dpkg --configure -a снова завершается ошибкой?

Не повторяйте команду бесконечно. Сохраните вывод и определите конкретный пакет или сценарий postinst, на котором остановилась настройка. Проверьте подтверждённую причину: запуск службы, нехватку места, ошибку файловой системы, конфликт зависимостей или несовместимость приложения. Не редактируйте базу dpkg вручную и не запускайте восстановление при параллельной транзакции.

Почему Candidate равен (none) в apt-cache policy?

Обычно это означает, что APT не видит доступной версии пакета среди текущих источников. Повторный apt install проблему не исправит. Проверьте включённые репозитории, выпуск ОС, смешение Debian и Ubuntu, сторонние источники, hold и правила pinning. После подтверждённого изменения источников обновите индекс и снова сравните версии через apt-cache policy.

Можно ли запускать dnf distro-sync при любом конфликте зависимостей?

Перед dnf distro-sync проверьте установленные и доступные версии конфликтующих пакетов, список включённых репозиториев и историю транзакций. Полезны dnf check, dnf info --showduplicates <пакет>, dnf repolist --enabled и dnf history list. Также выясните, нет ли исключений пакетов, versionlock, ограничений в конфигурации или модульных потоков, если они используются в данном выпуске.

Не подтверждайте транзакцию автоматически. Внимательно просмотрите все планируемые установки, обновления, понижения версий, замены и удаления. Остановитесь, если расчёт затрагивает ядро, загрузчик, сеть, SSH, systemd, libc, базу данных, пакеты приложения или предлагает удалить критичные компоненты. На рабочем сервере заранее определите окно работ, проверку приложения и резервное копирование по принятому регламенту.