Устранение неполадок APT в Ubuntu: исправление сломанных пакетов, блокировок и ошибок GPG

Неудачи с APT — обычное явление на машинах с Ubuntu, которые используются длительное время. Они обычно возникают после обновления версии, изменения стороннего репозитория, удаления PPA, ручной установки пакета .deb или прерванного процесса установки пакетов.

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

APT пытается ответить на четыре вопроса:

1. Какие репозитории включены?
2. Какие версии пакетов доступны?
3. Какие пакеты уже установлены?
4. Какие изменения пакетов разрешены?

Когда ответы противоречат друг другу, возникают удерживаемые пакеты, сломанные зависимости, отсутствующие открытые ключи, ошибки PPA или пакеты, которые откладываются на время обновления. Это руководство предлагает практическую последовательность действий для устранения неполадок с Ubuntu APT, написанную для разработчиков, инженеров DevOps и пользователей Linux, которые хотят исправить систему, не вставляя слепо случайные команды из форумных тем. Используйте его вместе с нашей шпаргалкой по Ubuntu APT и dpkg для повседневных команд установки и обновления, а также ознакомьтесь с более широкой коллекцией Инструменты разработчика для связанных рабочих процессов Linux.

Краткая версия

Если ваша система повреждена незначительно, начните с этого:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
sudo apt upgrade

Если пакеты отложены на потом (kept back):

apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Если PPA или сторонний репозиторий не работает:

ls /etc/apt/sources.list.d/
sudo apt update

Прочитайте строку с ошибкой репозитория, затем отключите или исправьте этот репозиторий. Если вы видите NO_PUBKEY, не импортируйте слепо случайные ключи с сервера ключей — найдите официальные инструкции репозитория, установите ключ репозитория в /etc/apt/keyrings и привяжите его к этому репозиторию с помощью signed-by.

Прежде чем исправлять что-либо: прочитайте ошибку APT

Сначала выполните это:

sudo apt update

Не пропускайте этот шаг. apt update обновляет метаданные пакетов. Он не обновляет пакеты. Он сообщает, может ли Ubuntu прочитать все настроенные репозитории и проверить их метаданные.

Затем проверьте версию Ubuntu и кодовое имя — устаревшее имя релиза в /etc/apt/sources.list.d/ является частой причиной ошибок 404 и ошибок файла Release. Если вы не уверены, какую версию вы используете, см. как проверить версию Ubuntu:

lsb_release -a

Или:

cat /etc/os-release

Также проверьте, какие пакеты можно обновить:

apt list --upgradable

И проверьте, нет ли удерживаемых пакетов:

apt-mark showhold

Это дает вам первое разделение в дереве решений — определение класса сбоя в первую очередь облегчает устранение неполадок, так как каждый класс имеет свой собственный первый шаг исправления:

• Проблема репозитория: apt update завершается ошибкой.
• Проблема зависимостей: apt update работает, но установка или обновление завершается ошибкой.
• Проблема удерживаемого пакета: APT отказывается изменять определенные пакеты.
• Проблема смешанных источников: PPA, ручной .deb или старый репозиторий предоставляет несовместимые версии.
• Проблема прерванной установки: dpkg распаковал пакеты, которые никогда не были настроены.

Распространенные типы сбоев Ubuntu APT

Отложенные пакеты (Packages Kept Back)

Отложенный пакет не всегда является ошибкой; это означает, что APT решил не обновить пакет с помощью текущей команды. Это часто происходит, когда для обновления требуется установка новых зависимостей, удаление старых пакетов или изменение пакета таким образом, который обычная команда apt upgrade не выполнит.

Проверьте детали:

apt list --upgradable
apt-cache policy package-name

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

sudo apt full-upgrade

full-upgrade разрешает устанавливать новые пакеты и удалять пакеты при необходимости для завершения обновления. Это полезно, но именно поэтому вы должны прочитать предлагаемые изменения перед их принятием. На рабочей станции full-upgrade обычно нормально после проверки; на сервере прочитайте список удаляемых пакетов дважды.

Удерживаемые пакеты (Held Packages)

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

Список удерживаемых пакетов:

apt-mark showhold

Удерживать пакет:

sudo apt-mark hold package-name

Снять удержание:

sudo apt-mark unhold package-name

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

Сломанные зависимости

Сломанные зависимости означают, что APT не может найти действительный набор пакетов, что обычно указывает на конфликт версий, а не на поврежденную загрузку.

Распространенные причины включают:

• Пакету требуется версия, которая недоступна.
• PPA предоставляет более новую библиотеку, чем ожидает Ubuntu.
• Ручной .deb зависит от пакетов из другого релиза.
• Установка пакета была прервана.
• Включен репозиторий для неправильного релиза Ubuntu.
• Привязка пакетов или удержания предотвращают необходимое изменение версии.

Начните с:

sudo dpkg --configure -a
sudo apt --fix-broken install

Затем проверьте пакет:

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Затем используйте эти команды, чтобы найти конфликт версий пакета, который блокирует APT, вместо того чтобы запускать каждую команду восстановления по порядку.

Ошибки ключа GPG и NO_PUBKEY

Ошибка NO_PUBKEY означает, что APT получил метаданные репозитория, но не может проверить подпись, потому что отсутствует требуемый открытый ключ — это проблема доверия, а не просто проблема загрузки.

Типичная ошибка выглядит так:

The following signatures could not be verified because the public key is not available: NO_PUBKEY ABCD1234EF567890

Старые инструкции часто использовали apt-key add, но избегайте этого для новой настройки репозиториев. В современных системах Ubuntu следует использовать кольцеобразный ключ репозитория (keyring) и signed-by.

Более правильный паттерн выглядит так:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/repo-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Замените URL и строку репозитория официальными инструкциями от поставщика.

Важная часть здесь:

signed-by=/etc/apt/keyrings/example.gpg

Эта строка signed-by привязывает ключ к одному репозиторию, что чище и безопаснее, чем помещение каждого стороннего ключа в глобальное хранилище доверия.

Ошибки плохого PPA или файла Release

Сбои PPA часто выглядят так:

The repository does not have a Release file.

Или:

404 Not Found

Распространенные причины:

• PPA не поддерживает ваш релиз Ubuntu.
• Вы обновили Ubuntu, но PPA все еще указывает на старое кодовое имя.
• PPA был удален.
• Поддерживающий прекратил публикацию пакетов.
• Вы добавили PPA, предназначенный для другой версии Ubuntu.

Проверьте ваше кодовое имя:

. /etc/os-release
echo "$VERSION_CODENAME"

Список файлов сторонних источников:

ls /etc/apt/sources.list.d/

Осмотрите их:

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

Отключите подозрительный источник, переименовав его:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

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

Безопасный рабочий процесс устранения неполадок APT

Шаг 1: Обновить метаданные

sudo apt update

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

Ищите строки, содержащие:

NO_PUBKEY
Release file
404 Not Found
does not have a Release file
The repository is not signed

Это проблемы репозитория или доверия, и их следует исправить, прежде чем пытаться выполнить любое восстановление пакетов.

Шаг 2: Завершить прерванную конфигурацию пакетов

Если установка пакета была прервана, dpkg мог распаковать файлы, но не настроить пакет.

Запустите:

sudo dpkg --configure -a

Если это успешно, продолжите:

sudo apt --fix-broken install

Если это не удается, внимательно прочитайте имя пакета и ошибку. Пакет, указанный внизу ошибки, часто важнее, чем пакет, который вы изначально пытались установить.

Шаг 3: Попросить APT исправить зависимости

sudo apt --fix-broken install

Эта команда просит APT исправить проблемы зависимостей, установив отсутствующие зависимости или удалив пакеты, которые не могут быть удовлетворены. Внимательно прочитайте предлагаемое действие, особенно любые удаления.

Будьте осторожны, если APT хочет удалить:

• ubuntu-desktop
• ubuntu-server
• linux-generic
• пакеты менеджера дисплеев
• сетевые пакеты
• пакеты баз данных
• пакеты среды выполнения контейнеров
• пакеты среды рабочего стола

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

Шаг 4: Проверить удерживаемые пакеты

apt-mark showhold

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

apt-cache policy package-name

Если удержание больше не нужно:

sudo apt-mark unhold package-name
sudo apt update
sudo apt upgrade

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

Шаг 5: Проверить версии пакетов

Для пакета с проблемами зависимостей:

apt-cache policy package-name

Это показывает:

• Установленную версию
• Кандидатную версию
• Доступные версии
• Какой репозиторий предоставляет каждую версию

apt-cache policy — одна из самых полезных команд отладки APT, потому что она показывает, откуда берется каждая доступная версия.

Пример:

apt-cache policy docker-ce

Если кандидатная версия поступает из неожиданного PPA или старого репозитория, вы нашли вероятную причину конфликта зависимостей.

Шаг 6: Искать смешанные репозитории

Список включенных источников:

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

Ищите:

• Старые кодовые имена Ubuntu
• Репозитории Debian в Ubuntu
• PPAs для другого релиза Ubuntu
• Дублированные репозитории поставщиков
• Смешанные инструкции Snap и APT для одного и того же инструмента
• Старые файлы .list, оставшиеся после удаления программного обеспечения

Распространенным антипаттерном является установка инструмента из репозитория поставщика, а затем позже добавление PPA или ручного .deb, который предоставляет перекрывающиеся библиотеки. APT может обрабатывать многие источники, но он не может согласовать противоречивые намерения, если вы сами не согласуете репозитории.

Шаг 7: Попробовать смоделированную установку или обновление

Прежде чем вносить изменения, смоделируйте:

apt -s install package-name

Или:

apt -s full-upgrade

Опция -s моделирует операцию. Она полезна, когда вы хотите увидеть, что сделает APT, не изменяя систему.

Исправление удерживаемых пакетов

Список удерживаемых пакетов

apt-mark showhold

Если ничего не выведено, пакеты не удерживаются с помощью apt-mark, и вы можете перейти к проверке зависимостей или репозиториев.

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

sudo apt-mark hold package-name

Хорошие причины удерживать пакет:

• Версия ядра известна как работающая с вашим оборудованием.
• Обновление базы данных требует планирования.
• Обновление драйвера ломает вашу графическую карту.
• Версия среды выполнения должна соответствовать производственной.
• Пакет поставщика несовместим с последней зависимостью.

Плохие причины удерживать пакет:

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

Снять удержание

sudo apt-mark unhold package-name

Затем обновите и обновите пакеты:

sudo apt update
sudo apt upgrade

Если пакет по-прежнему не обновляется, это была не только проблема удержания. Проверьте политику:

apt-cache policy package-name

Исправление сломанных зависимостей

Стандартная последовательность восстановления

Используйте эту последовательность, когда установка или обновление пакета завершились ошибкой на полпути:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

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

Удалить плохо установленный локальный пакет

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

dpkg -l | grep package-name
apt-cache policy package-name

Удалите его:

sudo apt remove package-name

Если конфигурационные файлы также вызывают проблемы:

sudo apt purge package-name

Затем восстановите:

sudo apt --fix-broken install

Переустановить поврежденный пакет

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

sudo apt install --reinstall package-name

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

Исправление проблем PPA и сторонних репозиториев

Найти PPAs и сторонние репозитории

ls /etc/apt/sources.list.d/

Показать активные строки репозиториев:

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

В новых системах Ubuntu вы также можете увидеть файлы .sources, использующие формат deb822:

ls /etc/apt/sources.list.d/*.sources

Отобразить их:

cat /etc/apt/sources.list.d/*.sources

Безопасно отключить PPA

Переименуйте файл источника:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Для файлов deb822:

sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt update

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

Удалить пакеты из PPA

Отключение PPA прекращает будущие загрузки пакетов из него. Оно не автоматически понижает версии пакетов, уже установленных из этого PPA.

Если PPA вызвал конфликты библиотек, вам может потребоваться понизить версии пакетов до версий Ubuntu.

Установите ppa-purge:

sudo apt install ppa-purge

Затем очистите PPA:

sudo ppa-purge ppa:owner/name

Используйте ppa-purge осторожно и прочитайте предлагаемые изменения перед их принятием, поскольку он может удалить или понизить версии нескольких связанных пакетов.

После обновления версии

После обновления Ubuntu старые PPAs являются распространенным источником ошибок.

Проверьте наличие старых кодовых имен:

grep -R "jammy\|noble\|oracular\|plucky" /etc/apt/sources.list /etc/apt/sources.list.d/

Отрегулируйте кодовые имена для вашей реальной системы. Например, если вы используете Ubuntu 24.04, ваше кодовое имя — noble. Если сторонний источник все еще указывает на более старое кодовое имя, проверьте, поддерживает ли этот поставщик ваш текущий релиз Ubuntu. Если вы настраиваете новую машину, а не восстанавливаете обновление, наше руководство по установке Ubuntu 24.04 проходит через добавление репозиториев поставщиков с signed-by с самого начала.

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

Исправление ошибок GPG и NO_PUBKEY

Что означает NO_PUBKEY

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

Современный паттерн хранилища ключей

Создайте директорию хранилища ключей:

sudo install -d -m 0755 /etc/apt/keyrings

Скачайте и деармируйте ключ поставщика:

curl -fsSL https://example.com/repository-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

Установите права на чтение:

sudo chmod 0644 /etc/apt/keyrings/example.gpg

Добавьте репозиторий с signed-by:

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/example.list

Затем обновите:

sudo apt update

Замените noble на ваше кодовое имя Ubuntu, если необходимо:

. /etc/os-release
echo "$VERSION_CODENAME"

Почему apt-key — плохая привычка

Старые руководства часто используют:

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

Избегайте apt-key add для новых настроек. Старый стиль apt-key добавляет ключи в широкую область доверия, что затрудняет понимание, какому ключу доверяют для какого репозитория, тогда как современный стиль signed-by ограничивает ключ определенным репозиторием и является базовой гигиеной цепочки поставок.

Найти устаревшие доверенные ключи

У вас могут быть старые ключи в:

/etc/apt/trusted.gpg
/etc/apt/trusted.gpg.d/

Список файлов:

ls -l /etc/apt/trusted.gpg.d/

Не удаляйте ключи случайным образом — сначала сопоставьте каждый ключ с репозиторием, затем перенесите один репозиторий за раз в /etc/apt/keyrings и signed-by.

Распространенные ошибки GPG

Не используйте случайные серверы ключей как первый выбор при исправлении ошибок NO_PUBKEY.

Лучший порядок:

1. Используйте официальную документацию по установке поставщика.
2. Скачайте ключ с официального HTTPS URL поставщика.
3. Сохраните его в /etc/apt/keyrings.
4. Привяжите его с помощью signed-by.
5. Запустите sudo apt update.

Избегайте этих ярлыков:

sudo apt update --allow-unauthenticated
sudo apt install --allow-unauthenticated package-name

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

Исправление “Репозиторий не подписан”

Эта ошибка обычно означает одно из следующего:

• Репозиторий не публикует подписанные метаданные.
• URL репозитория неверен.
• Репозиторий больше не поддерживает вашу версию Ubuntu.
• Прокси или зеркало возвращает неверный контент.
• Вы используете HTTP, где поставщик теперь ожидает HTTPS.
• В файле источника указан неправильный набор или компонент.

Найдите сбойший источник:

sudo apt update

APT выведет URL. Затем найдите его:

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/

Временно отключите его:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Если APT снова работает после отключения файла, переустановите этот репозиторий из текущих официальных инструкций поставщика, а не повторно включайте старую конфигурацию.

Исправление предупреждений о дублировании репозиториев

APT может предупредить, что цель настроена несколько раз.

Список совпадающих записей:

grep -R "repo-url-or-domain" /etc/apt/sources.list /etc/apt/sources.list.d/

Дублированные репозитории часто появляются после многократного запуска скриптов установки поставщика.

Сохраните один файл источника. Отключите остальные:

sudo mv /etc/apt/sources.list.d/duplicate.list /etc/apt/sources.list.d/duplicate.list.disabled
sudo apt update

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

Исправление пакетов из неправильного релиза Ubuntu

Одна из худших проблем APT — смешение релизов Ubuntu — например, машина на Ubuntu 24.04 не должна беспечно тянуть пакеты из Ubuntu 22.04 или Debian testing. Иногда это работает некоторое время, но в конечном итоге граф зависимостей становится головоломкой, которую APT не может решить чисто.

Проверьте ваш релиз:

. /etc/os-release
echo "$VERSION_CODENAME"

Поиск источников:

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

Ищите чужие кодовые имена в включенных источниках, затем проверьте затронутый пакет:

apt-cache policy package-name

Если установленная версия пришла из старого или чужого репозитория, отключите этот репозиторий и понизьте или переустановите затронутый пакет из репозиториев Ubuntu.

Консервативный путь восстановления:

sudo apt update
sudo apt install --reinstall package-name

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

Очистка кэша APT и неиспользуемых пакетов

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

Удалите пакеты, которые были установлены автоматически и больше не нужны:

sudo apt autoremove

Очистить загруженные файлы пакетов:

sudo apt clean

Или удалить только устаревшие файлы пакетов:

sudo apt autoclean

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

Практические рецепты устранения неполадок APT

Рецепт: Пакет отложен (Kept Back)

sudo apt update
apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Если APT предлагает разумные изменения после моделирования, примите их. Если он предлагает большие удаления, остановитесь и проверьте:

apt-cache policy package-name

Рецепт: Удерживаемый пакет блокирует обновление

apt-mark showhold
apt-cache policy package-name
sudo apt-mark unhold package-name
sudo apt upgrade

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

Рецепт: Прерванная установка

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Рецепт: Ошибка NO_PUBKEY

1. Идентифицируйте репозиторий из sudo apt update.
2. Найдите текущие официальные инструкции по установке поставщика.
3. Установите ключ в /etc/apt/keyrings.
4. Используйте signed-by в файле источника.
5. Запустите sudo apt update.

Пример структуры:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Рецепт: У PPA нет файла Release

sudo apt update
ls /etc/apt/sources.list.d/
grep -R "ppa.launchpadcontent.net\|launchpad" /etc/apt/sources.list.d/

Отключите PPA:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Затем решите, удалить, заменить или очистить пакеты из этого PPA.

Рецепт: Ручной .deb сломал зависимости

dpkg -l | grep package-name
apt-cache policy package-name
sudo apt remove package-name
sudo apt --fix-broken install

Если вам все еще нужно программное обеспечение, предпочтите текущий репозиторий APT поставщика повторным ручным установкам .deb, которые со временем склонны накапливать конфликты зависимостей.

Основные команды устранения неполадок APT

Репозиторий и метаданные

sudo apt update
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/
ls /etc/apt/sources.list.d/

Состояние пакетов

apt list --installed
apt list --upgradable
apt-mark showhold
dpkg -l | grep package-name

Политика пакетов и зависимости

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Восстановление

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt install --reinstall package-name
sudo apt full-upgrade

Очистка

sudo apt autoremove
sudo apt autoclean
sudo apt clean

Моделирование

apt -s install package-name
apt -s full-upgrade

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

Не удаляйте /var/lib/dpkg случайным образом

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

Не отключайте проверку подписей

Избегайте:

--allow-unauthenticated

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

Не смешивайте релизы Ubuntu беспечно

Не добавляйте репозитории для другого релиза Ubuntu, если вы не понимаете привязку APT и последствия зависимостей.

Это особенно относится к:

• средам рабочего стола
• графическим драйверам
• стекам Python
• средам выполнения контейнеров
• пакетам Kubernetes
• пакетам баз данных

Не считайте PPAs безвредными

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

Дерево решений по устранению неполадок APT

Используйте эту ментальную модель:

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

Рекомендуемая базовая линия для машин разработчиков

Для чистой рабочей станции разработчика Ubuntu я предпочитаю эту базовую линию:

• Сохраняйте репозитории Ubuntu стандартными.
• Используйте репозитории APT поставщиков только когда они официальные и поддерживаются.
• Используйте /etc/apt/keyrings и signed-by для сторонних репозиториев.
• Избегайте старых инструкций apt-key.
• Избегайте смешивания PPAs, которые заменяют основные системные библиотеки.
• Используйте контейнеры, uv, pipx, asdf, mise или инструменты родных языков для быстро меняющихся зависимостей разработчика.
• Держите APT ответственным за операционную систему, драйверы, службы и стабильные CLI-инструменты.

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

Финальный чек-лист по устранению неполадок APT

Когда APT сломан в Ubuntu, пройдите через этот чек-лист:

[ ] Запустите sudo apt update и прочитайте первую реальную ошибку.
[ ] Проверьте кодовое имя Ubuntu с помощью /etc/os-release.
[ ] Завершите прерванные установки с помощью dpkg --configure -a.
[ ] Восстановите зависимости с помощью apt --fix-broken install.
[ ] Проверьте удерживаемые пакеты с помощью apt-mark showhold.
[ ] Проверьте версии пакетов с помощью apt-cache policy.
[ ] Отключите сломанные PPAs или сторонние репозитории.
[ ] Замените репозитории стиля apt-key на хранилища ключей signed-by.
[ ] Смоделируйте рискованные операции с помощью apt -s.
[ ] Прочитайте удаления перед принятием full-upgrade или autoremove.

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