Ubuntu/Debian: dpkg was interrupted — как восстановить apt и починить пакеты

Что означает «dpkg was interrupted» и почему apt перестаёт работать

В Debian/Ubuntu пакеты устанавливаются и настраиваются через dpkg, а apt — «обёртка», которая скачивает пакеты, рассчитывает зависимости и вызывает dpkg. Сообщение вида dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem означает, что предыдущая операция установки или обновления была прервана, и в системе остались пакеты в промежуточном состоянии.

Важно: это не «сломанный apt», а незавершённая транзакция dpkg. Пока в базе dpkg есть пакеты со статусами вроде unpacked или half-configured, apt часто отказывается продолжать, чтобы не ухудшить ситуацию.

Типичные причины:

• перезагрузка или потеря SSH-сессии во время apt upgrade;
• принудительное завершение процесса установки (kill, OOM, зависание);
• нехватка места на диске в / или /var (или закончились inode);
• конфликт зависимостей после частичного апдейта и смены репозиториев;
• пакеты в hold (held packages), из-за которых решатель зависимостей упирается в запреты.

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

Цель — вернуть систему в консистентное состояние. Перед «ремонтными» командами сделайте три короткие проверки: это экономит время и снижает риск случайно поломать больше.

1) Убедитесь, что нет параллельного apt/dpkg

Если сейчас реально работает другой процесс установки, чинить поверх нельзя. Проверьте процессы:

ps aux | grep -E "apt|dpkg" | grep -v grep

Если видите активный apt/dpkg, дождитесь окончания. Если процесс «завис», сначала убедитесь, что он не ждёт интерактивного ввода (например, вопроса про конфиг в текущем терминале).

2) Проверьте свободное место (самая частая причина)

df -h
df -i

Если заполнены / или /var (или нет inode), сначала освободите место: логи, кэши, старые ядра, большие временные файлы. Если начать «ремонт» при нулевом месте, вы легко зациклите проблему.

3) Если обновляете по SSH — фиксируйте сессию на будущее

Это не обязательный шаг для текущего ремонта, но правильная привычка: запускайте большие обновления в tmux или screen, чтобы разрыв SSH не прервал настройку пакетов.

Если вы обслуживаете несколько проектов на одном сервере, удобно держать инфраструктуру на VDS: больше контроля над диском и снапшотами, проще переживать аварийные обновления и откаты.

Быстрый и безопасный путь восстановления (90% случаев)

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

Шаг 1. Донастроить распакованные пакеты: dpkg --configure -a

sudo dpkg --configure -a

Это ключевая команда из текста ошибки. Она запускает конфигурационные скрипты пакетов, которые уже распакованы, но не были настроены. Если проблема была в прерывании, на этом шаге система часто полностью восстанавливается.

Если во время dpkg --configure -a появляется диалог (про конфиги или службы), на сервере обычно безопаснее сохранить текущие файлы, если вы правили их вручную. Но если вы не меняли конфиг, чаще выбирают вариант мейнтейнера пакета.

Шаг 2. Починить зависимости: apt --fix-broken или apt-get install -f

Если после конфигурации остались проблемы зависимостей (dependency problems), выполните один из вариантов:

sudo apt --fix-broken install

или эквивалент старого синтаксиса:

sudo apt-get install -f

Идея: apt постарается доставить недостающие зависимости или предложит план действий, чтобы убрать «broken packages».

Шаг 3. Повторить обычное обновление

sudo apt update
sudo apt upgrade

Если вам нужен full-upgrade (например, для обновления ядра или крупного стека), делайте его только после успешного upgrade и отсутствия ошибок:

sudo apt full-upgrade

Если не помогло: диагностируем broken packages и dependency problems

Когда dpkg --configure -a и apt --fix-broken не завершаются, задача — найти конкретные пакеты и понять, в каком состоянии они застряли. Дальше ремонт обычно становится точечным.

Посмотреть пакеты в проблемных состояниях

dpkg -l | awk '$1 ~ /^(iU|iF|iH|iW|rc|un)$/ {print}'

В выводе чаще всего важны такие статусы:

• iU — установлен, но не настроен (часто чинится dpkg --configure -a);
• iF — наполовину настроен (обычно есть ошибка в postinst/trigger);
• iH — удержан (hold), apt может не обновлять/не трогать такой пакет;
• rc — удалён, но конфиги остались (не ошибка, просто след).

Понять, что apt считает сломанным

sudo apt -o Debug::pkgProblemResolver=yes -f install

Вывод будет многословным, но он помогает увидеть, какой пакет ломает план установки и на каком конфликте зависимостей всё упирается.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Частый стоп-фактор: held packages (пакеты на удержании)

held packages — это пакеты, которые помечены как «не обновлять». Их ставят в hold осознанно (например, чтобы зафиксировать версию PHP/NGINX/ядра), но иногда удержание остаётся случайно после тестов.

Как проверить hold

apt-mark showhold

Если список не пустой, и apt ругается на невозможность разрешить зависимости, снимите hold с конкретного пакета (только если понимаете последствия):

sudo apt-mark unhold имя_пакета

После этого повторите цикл:

sudo apt --fix-broken install
sudo apt upgrade

Когда dpkg падает на скриптах пакета: что делать аккуратно

Иногда dpkg --configure -a останавливается на конкретном пакете из-за ошибки в postinst-скрипте, сломанной миграции конфигов, отсутствия пользователя или группы, проблем со стартом службы и т.д. В таком случае сначала вытащите имя пакета из сообщения об ошибке и действуйте точечно.

Переустановить проблемный пакет

Если пакет известен, часто помогает переустановка:

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

Проверить логи dpkg, если ошибка уже «прокрутилась»

sudo tail -n 200 /var/log/dpkg.log

Лог помогает быстро понять, на каком пакете и на каком этапе всё остановилось.

Осторожнее с планом удаления

Если apt предлагает удалить часть пакетов, остановитесь и оцените список. На сервере «автоудаление» иногда уносит критические компоненты (веб-сервер, SSH, сети, системные библиотеки).

Ремонт в условиях проблемного окружения: сеть, DNS, репозитории

Бывает, что ошибка «dpkg was interrupted» всплывает после частично скачанного обновления: индексы обновились, часть пакетов скачалась, а дальше сеть «упала». В итоге dpkg остался в промежуточном состоянии, а apt не может докачать недостающее.

Очистить кэш и обновить индексы

sudo apt clean
sudo apt update

Если вы точно убедились, что активных процессов apt/dpkg нет, иногда требуется убрать lock-файлы, оставшиеся после аварии:

sudo rm -f /var/lib/apt/lists/lock
sudo rm -f /var/cache/apt/archives/lock

Удалять lock-файлы имеет смысл только после проверки процессов. Иначе можно повредить состояние из-за параллельной работы пакетного менеджера.

Проверить, не смешаны ли релизы в sources.list

Dependency problems и broken packages часто возникают, когда в /etc/apt/sources.list случайно смешали разные релизы (например, stable/testing) или добавили несовместимый сторонний репозиторий. Проверьте активные строки:

grep -R "^[^#]" /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

Если видите «мешанину», приведите репозитории к одному релизу, затем выполните apt update и снова пройдите цикл восстановления.

Минимальный runbook: короткий чек-лист восстановления

Если ситуация неприятная (много broken packages, dpkg постоянно прерывается), держите под рукой короткий runbook. Он закрывает большинство кейсов без экстремальных мер.

1. Проверить место и процессы:

   df -h
   df -i
   ps aux | grep -E "apt|dpkg" | grep -v grep

2. Донастроить распакованное:

   sudo dpkg --configure -a

3. Выровнять зависимости:

   sudo apt --fix-broken install

4. Проверить hold и снять при необходимости:

   apt-mark showhold

   sudo apt-mark unhold имя_пакета

5. Повторить обновление:

   sudo apt update
   sudo apt upgrade

Если подобные инциденты случаются на боевых сайтах, заранее продумайте план миграции и отката. В этом помогает отдельный материал про переезд с виртуального хостинга на VDS — особенно когда апдейты и зависимости становятся сложнее.

Чего лучше не делать (или делать только понимая риск)

• Не удаляйте наугад файлы из /var/lib/dpkg/ и не правьте /var/lib/dpkg/status вручную без бэкапа. Ошибка может «уйти», но база пакетов останется тихо повреждённой.

• Не запускайте подряд много команд «на удачу». Двигайтесь по циклу: dpkg --configure -a → apt --fix-broken → диагностика конкретного пакета.

• Не соглашайтесь автоматически на массовое удаление пакетов, если не прочитали список. Особенно опасно удалять базовые библиотеки, SSH, сеть, init-систему.

Профилактика: как реже ловить прерванный dpkg/apt

• Запускайте апдейты в tmux/screen, особенно по SSH.

• Перед большим обновлением проверяйте место в /var и /, а также inode.

• Не смешивайте репозитории разных релизов и осторожно добавляйте сторонние источники пакетов.

• Если фиксируете версии — документируйте held packages, чтобы позже не забыть, почему пакет удержан.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Контрольный чек: что считать успешным восстановлением

Считайте проблему решённой, если выполняются три условия:

• sudo dpkg --configure -a завершается без ошибок;

• sudo apt --fix-broken install ничего не чинит или завершается успешно;

• sudo apt upgrade работает штатно, без сообщений про broken packages и dependency problems.

FAQ: короткие ответы на частые вопросы

Можно ли просто удалить lock-файлы?

Только если вы убедились, что нет активных процессов apt/dpkg. Lock-файл сам по себе не «причина», он защищает от параллельных запусков. Удаление lock при работающем apt — риск повреждения состояния.

Почему apt-get install -f и apt --fix-broken рекомендуют вместе с dpkg --configure -a?

Потому что они закрывают разные части проблемы: dpkg --configure -a завершает настройку уже распакованных пакетов, а apt --fix-broken подтягивает недостающие зависимости и приводит граф пакетов в согласованное состояние.

Что делать, если ошибка повторяется после каждого reboot?

Это признак постоянного стоп-фактора: нехватка места, падение на конкретном пакете (скрипт настройки), либо проблемы с репозиториями/зависимостями. Ищите пакет, на котором падает dpkg --configure -a, и разбирайтесь с первопричиной (лог /var/log/dpkg.log обычно помогает).