Debian и Ubuntu: почему APT пишет kept back и held packages, и как это исправить

Сообщение APT вида The following packages have been kept back или упоминание held packages — частая причина, почему администратор сомневается: можно ли спокойно продолжать обновление сервера или сначала нужно разбираться. В Debian и Ubuntu это поведение не всегда означает проблему. Иногда APT просто отказывается менять набор пакетов в режиме обычного обновления. Иногда пакет действительно поставлен на удержание. А иногда причина глубже: broken dependencies, прерванный dpkg, конфликт репозиториев или phased updates.

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

Ниже разберём, что означает kept back, чем отличаются apt upgrade и apt full-upgrade, как проверить удержание через apt-mark showhold, как распознать phased updates и что делать, если виноваты broken dependencies.

Коротко: kept back — это не диагноз, а симптом. Сначала нужно понять, APT просто осторожничает, или система уже находится в неконсистентном состоянии.

Что на самом деле означает kept back

Когда вы запускаете apt upgrade, APT обновляет только те пакеты, которые можно поднять без установки новых пакетов и без удаления существующих. Это ключевое ограничение режима. Если новая версия требует дополнительную зависимость, замену пакета или удаление конфликтующего компонента, обычный upgrade останавливается и оставляет такой пакет в статусе kept back.

Именно поэтому kept back часто появляется после обновлений ядра, метапакетов, библиотек, PHP-стека, контейнерных пакетов и других компонентов, у которых со временем меняется граф зависимостей. На серверах это особенно заметно при обновлении пакетов вроде linux-generic, postgresql, qemu-guest-agent и похожих наборов.

Отдельный случай — held packages. Это уже не просто осторожность APT, а явное удержание пакета. Его могли выставить вручную через apt-mark hold, через dpkg --set-selections, средствами панели управления или скриптом автоматизации.

Чем отличаются apt upgrade и apt full-upgrade

Путаница чаще всего начинается здесь. Администратор видит kept back, запускает apt full-upgrade, и сообщение исчезает. Но важно понимать, почему именно это произошло.

apt upgrade обновляет только «безопасные» с точки зрения состава пакетов версии. Команда не будет ставить новые зависимости, удалять уже установленные пакеты или агрессивно разруливать конфликты.

apt full-upgrade, наоборот, умеет менять набор установленных пакетов: доустанавливать зависимости, удалять мешающие пакеты, заменять метапакеты и принимать более сложные решения. По смыслу это современный аналог поведения, которое многие помнят по apt-get dist-upgrade.

Практический вывод простой: kept back после apt upgrade ещё не означает ошибку. Если apt full-upgrade --simulate показывает понятный и логичный план изменений, это часто нормальный путь завершить обновление. Но если симуляция предлагает удалить критичные пакеты, сначала нужно разбираться с причиной, а не соглашаться на операцию.

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

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

Подробнее

Если вы сопровождаете несколько серверов и хотите, чтобы обновления APT вели себя предсказуемо, удобнее держать окружения на отдельных VDS: проще контролировать репозитории, pinning и окна обслуживания без влияния соседних проектов.

С чего начать диагностику

Ниже — безопасный порядок проверки, который одинаково хорошо работает и в Debian, и в Ubuntu.

1. Обновите индексы пакетов

apt update

Без свежих индексов любой дальнейший вывод может быть просто неактуальным.

2. Посмотрите, есть ли ручное удержание

apt-mark showhold

Если команда что-то выводит, часть пакетов действительно находится в hold. В такой ситуации kept back может быть полностью ожидаемым поведением.

3. Посмотрите план полного обновления без изменений в системе

apt full-upgrade --simulate

Симуляция особенно полезна на продакшн-серверах. Смотрите не только список обновляемых пакетов, но и строки NEW packages и REMOVED.

4. Проверьте broken dependencies

apt --fix-broken install --simulate

Если APT ругается на зависимости, сначала нужно вернуть систему в согласованное состояние, и только потом разбираться с kept back.

5. Убедитесь, что dpkg не остался в прерванном состоянии

dpkg --audit

dpkg --configure -a

Незавершённая конфигурация после оборванной SSH-сессии, сбоя VM или неудачного обновления — одна из самых частых причин странного поведения APT.

Как понять, что пакет удерживается вручную

Если apt-mark showhold показывает пакет, это и есть прямой ответ на вопрос про held packages. Типичный сценарий: кто-то когда-то зафиксировал версию ядра, PHP, Docker, PostgreSQL или Nginx, чтобы избежать неожиданного обновления, а потом про это забыли.

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

apt-cache policy nginx

Снять удержание можно командой:

apt-mark unhold nginx

После этого снова проверьте обновление:

apt upgrade

Если пакет требует новые зависимости, используйте:

apt full-upgrade

Но не снимайте hold автоматически со всего списка. Иногда удержание сделано специально — например, чтобы не обновлять major-версию СУБД вне запланированного окна работ.

Phased updates в Ubuntu: частая и безобидная причина

В Ubuntu работает механизм phased updates. Обновление может раскатываться постепенно, а не приходить всем машинам одновременно. В результате один сервер уже видит новую версию пакета, а другой пока ещё нет. Внешне это похоже на kept back, хотя никакой аварии в системе нет.

Чаще всего это сбивает с толку, когда вы сравниваете несколько почти одинаковых машин и получаете разный результат при обновлении.

Проверить ситуацию можно через симуляцию:

apt upgrade --simulate

На части систем APT прямо указывает, что пакет удержан из-за phased updates. В таком случае лучший вариант для сервера — обычно просто дождаться следующего этапа раскатки, а не форсировать установку.

Если причина в phased updates, не путайте это с ручным hold и не пытайтесь срочно «чинить» систему. Чаще всего это штатная защитная механика Ubuntu.

Если у вас есть локальные зеркала, прокси или кэширующий сервер пакетов, полезно отдельно проверить, не влияют ли они на разницу в видимости обновлений. Для этого может пригодиться материал про кэширование APT через Squid.

Когда kept back — это нормальное следствие новых зависимостей

Самый частый сценарий: пакет выходит в новой сборке и начинает зависеть от дополнительной библиотеки или отдельного бинарного пакета. apt upgrade не хочет ничего доустанавливать и пишет kept back. При этом apt full-upgrade --simulate показывает одну-две новые зависимости без удалений и без странных конфликтов.

Такой случай обычно безопасен. Например, вы можете увидеть:

The following packages have been kept back:
  package-name

А симуляция полного обновления покажет:

The following NEW packages will be installed:
  package-name-data
The following packages will be upgraded:
  package-name

Если набор изменений понятен и логичен, можно выполнять полное обновление уже без симуляции.

apt full-upgrade

Когда проблема в broken dependencies

Если APT пишет про unmet dependencies, dependency problems или предлагает запустить apt --fix-broken install, это уже не просто kept back. Это признак того, что зависимостная целостность системы нарушена.

Типичные причины такие:

• смешивание репозиториев разных релизов Debian или Ubuntu;
• подключение стороннего репозитория с более высоким приоритетом;
• неполностью установленный пакет;
• ручная установка .deb без учёта зависимостей;
• прерванный процесс dpkg;
• ручное удаление важной зависимости.

Базовый маршрут восстановления обычно выглядит так:

dpkg --audit
dpkg --configure -a
apt --fix-broken install
apt update
apt full-upgrade --simulate

Если после этого конфликт остаётся, посмотрите, какие версии пакетов реально выбирает APT:

apt-cache policy package-name

Особенно внимательно проверяйте приоритеты и источник версии. Если один пакет идёт из текущего релиза, а зависимость — из стороннего репозитория или соседней ветки, проблема почти наверняка в репозиториях и pinning.

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

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

Подробнее

Проверка репозиториев: где часто прячется причина

На серверах kept back и held packages нередко оказываются побочным эффектом неаккуратно настроенных источников пакетов. Особенно после миграций, ручных апгрейдов системы или долгой истории изменений.

Быстро просмотреть активные источники можно так:

grep -R ^deb /etc/apt/sources.list /etc/apt/sources.list.d/

Насторожить должны такие признаки:

• одновременно подключены репозитории двух разных релизов;
• остался старый PPA или сторонний репозиторий без поддержки вашего релиза;
• подключены vendor-репозитории без pinning;
• часть пакетов приходит из stable, а часть из testing или backports без понимания последствий.

В таких случаях простой full-upgrade может не решить проблему, а наоборот попытаться радикально перестроить систему.

Как безопасно читать вывод apt full-upgrade --simulate

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

Новые пакеты

Если появляются вспомогательные библиотеки, пакеты данных, обновлённые метапакеты или новая обвязка ядра, это обычно нормально.

Удаляемые пакеты

Вот здесь уже нужна осторожность. Если к удалению предлагаются используемое ядро, systemd, openssh-server, grub, важные пакеты приложения или заметный пласт библиотек без понятной причины, обновление подтверждать не стоит.

Пакеты, которые остаются удержанными даже после симуляции

Если пакет не хочет обновляться даже после full-upgrade, почти наверняка есть manual hold, phased rollout, pinning, конфликт версий или сломанная зависимость.

Практический runbook для Debian и Ubuntu

Если нужен короткий рабочий алгоритм, используйте такой порядок:

1. Обновить индексы: apt update.

2. Проверить hold: apt-mark showhold.

3. Проверить незавершённые состояния: dpkg --audit, затем dpkg --configure -a.

4. Проверить broken dependencies: apt --fix-broken install --simulate.

5. Посмотреть симуляцию полного обновления: apt full-upgrade --simulate.

6. Если причина в phased updates и система работает нормально — подождать.

7. Если причина в manual hold — снять удержание только с нужных пакетов.

8. Если причина в новых зависимостях без опасных удалений — выполнить apt full-upgrade.

9. Если есть странные удаления или конфликты версий — разбирать репозитории и pinning до продолжения.

Чего делать не стоит

На практике больше всего проблем создают не сами held packages, а слишком резкие действия администратора.

• Не удаляйте пакет вручную только потому, что он kept back.
• Не запускайте подряд несколько «лечащих» команд, не читая вывод.
• Не смешивайте репозитории ради одной новой версии пакета на продакшн-сервере.
• Не снимайте hold сразу со всех пакетов.
• Не выполняйте реальный full-upgrade по SSH без понимания, не затронет ли он сеть, загрузчик, ядро или OpenSSH.

Нужно ли всегда использовать full-upgrade

Нет. Для регулярного обслуживания серверов apt upgrade остаётся полезной и предсказуемой командой: она минимально меняет систему. А apt full-upgrade — это инструмент для тех случаев, когда обновление требует перестройки зависимостей.

На практике это выглядит так:

• для повседневных обновлений — сначала apt update и apt upgrade;
• если есть kept back — анализ через apt-mark showhold, dpkg --audit и симуляцию apt full-upgrade;
• реальный full-upgrade — только после чтения плана изменений.

Если вы держите приложения на PHP, после обновлений полезно отдельно проверять поведение пулов и сервисов, особенно когда меняется связка веб-сервера и интерпретатора. По теме может помочь статья про несколько PHP-FPM пулов в Nginx.

Итог

Сообщения apt keeps back и held packages в Debian и Ubuntu чаще всего означают одну из четырёх вещей: пакет удерживается вручную, обычный apt upgrade не хочет ставить новые зависимости, Ubuntu применяет phased updates или в системе есть broken dependencies.

Правильная реакция — не паниковать и не «чинить вслепую», а пройти короткую диагностику: apt update, apt-mark showhold, dpkg --audit, проверка apt --fix-broken install --simulate и просмотр apt full-upgrade --simulate. В большинстве случаев этого достаточно, чтобы понять, перед вами проблема или обычное защитное поведение APT.

Если помнить разницу между apt upgrade и apt full-upgrade, kept back перестаёт выглядеть как загадка. Это просто сигнал: перед продолжением посмотри, как изменится состав пакетов.