Как устранять распространенные сбои управления пакетами (APT/YUM)

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

APT распространен в системах Debian и Ubuntu. YUM и DNF распространены в системах семейства Red Hat, причем DNF заменяет YUM во многих новых релизах. Примеры ниже сосредоточены на сбоях, с которыми администраторы действительно сталкиваются: прерванные транзакции, проблемы с метаданными репозитория, конфликты зависимостей, блокировки, ошибки GPG и проблемы с базой данных пакетов.

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

Распространенные сбои APT и их устранение

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

1. Нарушенные пакеты или неудовлетворенные зависимости

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

Error: dpkg was interrupted, you might need to run 'sudo dpkg --configure -a' to correct the problem.

Unpacking ... (reading database ... xxxx files and directories currently installed.)

Preparing to unpack .../some-package_version_arch.deb ...

Unpacking some-package (version) ...

dpkg: error processing archive /var/cache/apt/archives/some-package_version_arch.deb (--unpack):

 trying to overwrite '/path/to/file', which is also in package other-package:amd64

Errors were encountered while processing:

 some-package
 E: Sub-process /usr/bin/dpkg returned an error code (1)

Шаги по устранению:

• Настройка ожидающих пакетов: Если dpkg был прерван, первым шагом будет попытка исправить это:

  sudo dpkg --configure -a
  

  Эта команда пытается настроить все пакеты, которые распакованы, но еще не настроены.

• Исправление нарушенных зависимостей: Если вышеуказанное не помогло, можно попробовать исправить нарушенные зависимости:

  sudo apt --fix-broken install
  

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

• Удаление проблемных пакетов: Иногда конкретный пакет может вызывать постоянные проблемы. Можно попробовать удалить его:

  sudo apt remove <package-name>
  

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

  sudo dpkg --remove --force-remove-reinstreq <package-name>
  

• Очистка кэша APT: Поврежденный кэш также может привести к ошибкам:

  sudo apt clean
  sudo apt update
  

  apt clean удаляет загруженные файлы пакетов из /var/cache/apt/archives/, а apt update обновляет список пакетов.

2. Проблемы с репозиторием

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

Примеры ошибок:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Temporary failure resolving 'archive.ubuntu.com'
E: Some index files failed to download. They have been ignored, or old ones used instead.

Шаги по устранению:

• Проверьте DNS и сетевое подключение: Сбои DNS распространены на только что созданных серверах и при нарушенных VPN-путях.

  getent hosts archive.ubuntu.com
  curl -I http://archive.ubuntu.com/ubuntu/
  

• Проверьте источники репозитория: Проверьте содержимое /etc/apt/sources.list и файлов в /etc/apt/sources.list.d/. Убедитесь, что URL-адреса правильные и доступны.
  • Ищите опечатки.
  • Закомментируйте или удалите подозрительные записи репозитория.
• Попробуйте другое зеркало: Если конкретное зеркало недоступно, APT может автоматически попробовать другое. Если нет, вручную отредактируйте sources.list, чтобы выбрать другое зеркало.
• Обновите списки пакетов: После внесения любых изменений всегда запускайте:

  sudo apt update
  

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

3. Прерванные установки или обновления

Если процесс apt install или apt upgrade был прерван (например, из-за отключения электроэнергии или перезагрузки системы), это может привести к несогласованному состоянию системы.

Шаги по устранению:

• Запустите sudo dpkg --configure -a: Как упоминалось ранее, это первый шаг для исправления любых проблем с конфигурацией dpkg.
• Запустите sudo apt --fix-broken install: Это может решить проблемы с зависимостями, возникшие из-за прерывания.
• Повторно запустите команду: Иногда простой повторный запуск команды, которая не удалась, может решить проблему, если она была временной.

Распространенные сбои YUM/DNF и их устранение

YUM и DNF — это мощные инструменты для управления пакетами в системах на основе Red Hat. Как и в APT, сбои часто возникают из-за проблем с зависимостями, репозиторием или поврежденного кэша.

1. Ошибки зависимостей

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

Пример ошибки (YUM):

Error: Package: some-package-1.0-1.el8.x86_64 (epel)

Requires: another-package >= 2.0

You could try: rpm -e --nodeps some-package

Пример ошибки (DNF):

Error: 
 Problem: cannot install the best candidate for this package (root means installing process)
  - nothing provides dependency 'another-package >= 2.0' needed by 'some-package-1.0-1.el8.x86_64'

Шаги по устранению:

• Обновите информацию о пакетах: Убедитесь, что ваш локальный кэш пакетов актуален:

  sudo yum makecache # Для YUM
  sudo dnf makecache # Для DNF
  

• Установите зависимости вручную: Если вы знаете требуемую зависимость, попробуйте установить ее явно:

  sudo yum install another-package # Для YUM
  sudo dnf install another-package # Для DNF
  

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

  sudo yum install yum-utils
  sudo package-cleanup --cleandupes # Очистка дублирующихся пакетов
  sudo package-cleanup --orphans # Удаление осиротевших пакетов
  
  sudo dnf install dnf-plugins-core
  sudo dnf clean all
  

• Избегайте rpm -e --nodeps, если у вас нет плана отката: Это может удалить пакет, оставив установленные зависимые пакеты, что может удовлетворить команду, но нарушить работу системы.

2. Проблемы с конфигурацией репозитория

Проблемы с репозиториями YUM/DNF могут помешать поиску или установке пакетов.

Шаги по устранению:

• Проверьте файлы репозитория: Определения репозиториев обычно находятся в /etc/yum.repos.d/. Проверьте эти файлы .repo на:
  • Правильные записи baseurl или mirrorlist.
  • Включенные репозитории (enabled=1).
  • Проблемы с проверкой ключей GPG (часто указывается gpgcheck=1).
• Проверьте сетевой доступ: Как и в случае с APT, убедитесь, что ваша система может связаться с серверами репозитория.

  ping <адрес-сервера-репозитория>
  

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

  # Пример импорта ключа
  sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-your-repo
  

  Избегайте установки gpgcheck=0 на производственных системах. Это обменивает задачу по ремонту на риск для цепочки поставок.
• Очистите кэш: Поврежденный кэш может вызвать проблемы:

  sudo yum clean all
  sudo dnf clean all
  

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

  sudo yum makecache
  sudo dnf makecache
  

3. Ошибки неполной транзакции

Эти ошибки возникают, когда процесс установки, обновления или удаления пакета прерывается.

Шаги по устранению:

• Повторно запустите транзакцию: Часто простой повторный запуск команды (yum update, dnf install и т.д.) может решить проблему, если это был временный сбой.
• Очистите кэш: Как указано выше, очистка кэша может помочь:

  sudo yum clean all
  sudo dnf clean all
  

• Проверьте закрепленные пакеты: Хотя это менее распространено в YUM/DNF, чем в APT, некоторые конфигурации могут препятствовать обновлению пакетов. Обычно это управляется конфигурациями плагинов, а не прямыми командами 'hold'.
• Проверьте журналы: Проверьте /var/log/yum.log (для YUM) или /var/log/dnf.log (для DNF) на наличие подробных сообщений об ошибках.

Блокировки и зависшие процессы пакетов

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

В Debian или Ubuntu вы можете увидеть сообщения о /var/lib/dpkg/lock-frontend или /var/lib/apt/lists/lock. В системах семейства Red Hat вы можете увидеть другой процесс dnf или yum, удерживающий блокировку базы данных RPM.

Сначала проверьте наличие активного процесса:

ps aux | grep -E 'apt|dpkg|dnf|yum|rpm' | grep -v grep

Если unattended upgrades или cloud-init выполняется, подождите. Убийство реальной транзакции пакета может оставить пакеты полунастроенными. Если вы уверены, что процесс завершен и осталась только устаревшая блокировка, восстановите базу данных пакетов с помощью обычных инструментов:

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

Для систем на основе RPM:

sudo dnf clean all
sudo rpm --rebuilddb

rpm --rebuilddb — это не первая реакция на каждую проблему DNF. Используйте его, когда сама база данных RPM повреждена, а не когда URL репозитория неверен.

Конфликты версий из сторонних репозиториев

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

В системах APT проверьте политику:

apt-cache policy <package-name>
apt-cache madison <package-name>

В системах DNF:

dnf repoquery --show-duplicates <package-name>
dnf repolist --enabled

Если один сторонний репозиторий является проблемой, временно отключите его и повторите транзакцию:

sudo dnf --disablerepo='repo-name' update

Для APT закомментируйте подозрительную запись в /etc/apt/sources.list.d/, запустите sudo apt update и проверьте снова. Не оставляйте систему в загадочном состоянии; задокументируйте, какой репозиторий был отключен и почему.

Когда обновление релиза или крупное обновление не удается

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

В Debian или Ubuntu проверьте файлы релиза и закрепленные пакеты:

cat /etc/os-release
apt-mark showhold
sudo dpkg --audit

В системах на основе DNF проверьте включенные репозитории и поведение синхронизации дистрибутива:

cat /etc/os-release
dnf repolist --enabled
sudo dnf distro-sync

distro-sync может понизить версию или заменить пакеты в соответствии с включенными репозиториями, поэтому прочитайте предлагаемую транзакцию, прежде чем принять ее. В важных системах сначала сделайте снимок или резервную копию. Менеджеры пакетов хороши в математике зависимостей, но они не могут знать, от каких локальных файлов конфигурации, модулей ядра или агентов поставщиков зависит ваш бизнес.

Общие советы по устранению неполадок

Независимо от менеджера пакетов, несколько общих практик могут сэкономить вам время и избавить от головной боли:

• Внимательно читайте сообщения об ошибках: Вывод apt или yum/dnf часто содержит конкретные подсказки о проблеме.
• Проверяйте системные журналы: /var/log/apt/history.log и /var/log/apt/term.log для APT, а также /var/log/yum.log или /var/log/dnf.log для YUM/DNF могут предоставить подробную историю транзакций и информацию об ошибках.
• Регулярно обновляйтесь: Поддерживайте актуальность системы и списков пакетов, чтобы свести к минимуму вероятность столкновения с устаревшими зависимостями или проблемами репозитория.
• Используйте sudo: Всегда запускайте команды управления пакетами с привилегиями суперпользователя.
• Резервируйте критически важные данные: Перед выполнением крупных обновлений системы или установок создавайте резервные копии любых критически важных данных. Это страховочная сетка, если что-то пойдет не так.
• Изолируйте проблему: Если несколько пакетов не работают, попробуйте обновить или установить их по одному, чтобы определить конкретный пакет, вызывающий проблему.
• Прочитайте предлагаемую транзакцию, прежде чем вводить yes: Удаления имеют значение. Если менеджер пакетов хочет удалить сервер базы данных, пакет ядра, SSH-сервер или основную среду выполнения, остановитесь и поймите, почему.
• Предпочитайте исправления репозитория флагам принуждения: Большинство сбоев пакетов происходит из-за метаданных, репозитория или состояния зависимостей. Флаги принуждения могут скрыть симптом, оставляя систему более сложной в обслуживании.

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