Почему dnf не находит пакеты в Rocky Linux и AlmaLinux

Почему dnf не находит нужный пакет

EPEL и CRB — это два репозитория, которые не предоставляются «из коробки» на свежеустановленном сервере Rocky Linux или AlmaLinux, поэтому dnf install htop на новой машине отвечает No match for argument: htop, а затем Error: Unable to find a match: htop. Ничего не сломано, и зеркала работают исправно. Базовый дистрибутив намеренно содержит ограниченный набор пакетов, CRB присутствует в системе, но отключен, а EPEL — это отдельный репозиторий сообщества, который необходимо добавить вручную.

В Ubuntu тот же пакет находится в universe, а universe включен почти в каждом облачном образе, поэтому такой вопрос там не возникает. Семейство Red Hat распределяет пакеты иначе и по умолчанию предлагает меньше компонентов. Решение состоит из трех команд. Остальная часть этого руководства — то, о чем обычно не говорят на первой неделе: что гарантируют эти репозитории, чего они не гарантируют и как предотвратить ситуацию, когда сторонний репозиторий незаметно берет под контроль вашу базовую систему.

Как проверялись эти команды. Наши тестовые контейнеры работают только на Ubuntu, поэтому команды dnf, приведенные ниже, не выполнялись на наших собственных тестовых машинах. Они следуют документации Rocky Linux и AlmaLinux. Каждый шаг содержит описание ожидаемого вывода, поэтому проверяйте каждый из них на своем сервере, вместо того чтобы копировать весь блок целиком.

Что такое BaseOS, AppStream и CRB?

BaseOS — это сама операционная система: ядро, glibc, systemd и базовые компоненты пользовательского пространства. Версии здесь редко меняются в течение жизненного цикла мажорного релиза. Большинство исправлений, включая патчи безопасности, бэкпортируются в уже имеющуюся у вас версию, хотя в минорных релизах иногда происходит обновление ключевого компонента до более новой версии из апстрима (например, в AlmaLinux 9.2 пакеты пользовательского пространства SELinux были обновлены до версии 3.5). Если номер версии в BaseOS выглядит устаревшим на несколько лет, это не значит, что пакет не обновлялся. Это пропатченная старая версия, в чем и заключается суть корпоративного дистрибутива.

AppStream содержит ПО, которое вы запускаете поверх системы: веб-серверы, базы данных, среды выполнения языков программирования, редакторы и агенты мониторинга. В версии 8 большая часть AppStream поставлялась в виде модулей с альтернативными потоками, поэтому dnf module list имел значение, и вы выбирали, например, один поток PHP. В версии 9 стандартная версия каждого приложения поставляется как обычный пакет, поэтому в Rocky 9 и Alma 9 простая команда dnf install устанавливает нужную версию без необходимости предварительно включать модуль. Альтернативные версии по-прежнему доступны в виде потоков модулей: в документации RHEL 9 PHP 8.0 указан как обычный пакет php, а PHP 8.1 и 8.2 — как потоки php:8.1 и php:8.2; в AlmaLinux 9.8 были добавлены новые потоки, такие как MariaDB 11.8, PostgreSQL 18 и Ruby 4.0. Если вам нужна версия, отличная от стандартной, dnf module list по-прежнему важен в версии 9.

Extras включен по умолчанию и содержит очень мало пакетов. В основном он хранит пакеты релизов для других репозиториев, откуда и берется сам epel-release. Именно поэтому вам никогда не нужно доверять случайным URL для установки EPEL в Rocky или Alma.

CRB — это репозиторий CodeReady Builder, который в версии 8 назывался PowerTools. Он содержит инструменты для сборки: заголовочные файлы для разработки, статические библиотеки, а также инструменты для тестирования и документации, необходимые пакетам на этапе сборки. Он уже присутствует на зеркале, но по умолчанию отключен. В продуктах Red Hat этот же контент называется CodeReady Linux Builder, он входит в подписку, но Red Hat заявляет, что на него не распространяется техническая поддержка. Rocky и Alma наследуют как сам контент, так и состояние «отключено по умолчанию».

Для тех, кто перешел с Debian или Ubuntu: main объединяет пакеты среды выполнения и -dev заголовочные файлы в одном архиве, поэтому там не нужно включать CRB. Ближайшим аналогом EPEL является universe, который поддерживается сообществом и не имеет гарантий поддержки от вендора.

Что такое EPEL и кто за ним стоит

EPEL расшифровывается как Extra Packages for Enterprise Linux. Это проект Fedora: пакеты, существующие в Fedora, пересобираются для текущего корпоративного релиза. Их сопровождает специальная группа EPEL Special Interest Group, состоящая преимущественно из добровольцев сообщества Fedora. Red Hat предоставляет инфраструктуру для сборки и зеркалирования, а некоторые инженеры Red Hat сопровождают в нем отдельные пакеты. На этом отношения заканчиваются. EPEL не является продуктом Red Hat. Для пакетов EPEL не предусмотрены контракты на поддержку или SLA (соглашения об уровне обслуживания), независимо от того, используете вы RHEL или его пересборки.

Безопасность использования EPEL обеспечивается одним правилом: пакет EPEL никогда не должен заменять пакет из базового дистрибутива. Если AppStream поставляет nginx, EPEL этого делать не будет. Это правило соблюдается участниками, проверяющими пакеты EPEL, поэтому оно касается только EPEL. Оно не защищает вас от других сторонних репозиториев, которые вы можете добавить позже.

Жизненный цикл пакетов также отличается от базового дистрибутива, и именно это создает проблемы на третий год эксплуатации. Пакет BaseOS обычно сохраняет свою версию на протяжении всего десятилетнего срока жизни мажорного релиза, получая лишь бэкпорты исправлений и редкие запланированные обновления версий. Сопровождающий EPEL берет на себя обязательства на гораздо более короткий срок: согласно предложению о жизненном цикле пакетов EPEL, это как минимум один минорный релиз RHEL или 13 месяцев, в зависимости от того, что наступит раньше. На практике большинство пакетов сопровождаются гораздо дольше. Некоторые пакеты удаляются, когда сопровождающий прекращает работу над ними, а некоторые переходят на новую мажорную версию в середине жизненного цикла вашего дистрибутива, так как EPEL следует за Fedora. Поэтому обычное обновление dnf upgrade может предоставить вам новую мажорную версию инструмента EPEL на машине, которую вы считали стабильной, а пакет, от которого вы зависите, может перестать получать обновления без какого-либо уведомления. Новая версия также не применяется автоматически к уже запущенному сервису, поэтому команда needs-restarting подскажет, какие процессы все еще используют старый бинарный файл после завершения транзакции.

Еще одно следствие, о котором стоит знать перед включением репозитория: EPEL не собирается под старые минорные релизы, на которых вы можете удерживать сервер. Согласно политике Fedora, EPEL 10 собирается для актуальной минорной версии CentOS Stream 10 и для конкретных минорных релизов RHEL 10, а для EPEL 8 и 9 существуют свои определения целей. Если вы удерживаете сервер на старом минорном релизе, используя замороженное зеркало или репозиторий конкретного точечного релиза вендора, пакет EPEL может потребовать более новую базовую библиотеку, чем та, что установлена у вас. dnf сообщит об этом как об отсутствующей зависимости, и это будет выглядеть как проблема с зеркалом, хотя на самом деле это проблема расхождения версий.

Включение CRB и установка EPEL на Rocky или Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

Команда dnf repolist --enabled теперь должна выводить baseos, appstream, extras, crb и epel. Вы также можете увидеть небольшую запись epel-cisco-openh264, которую добавляет epel-release. Если crb отсутствует в этом списке, значит, этап включения не был выполнен, и следующая секция объясняет причину.

В Rocky 8 и Alma 8 репозиторий по-прежнему называется PowerTools, поэтому средняя команда принимает вид sudo dnf config-manager --set-enabled powertools. Идентификаторы репозиториев чувствительны к регистру, а в старой документации CentOS 8 используется написание PowerTools с заглавными буквами, которое не сработает. В AlmaLinux 10 репозиторий CRB включен по умолчанию начиная с версии 10.0 (изменение вступило в силу в сентябре 2025 года), поэтому там требуется только шаг epel-release.

Пакет epel-release поставляется из extras, который уже включен, поэтому нет необходимости доверять URL или импортировать ключ вручную. Пакет записывает /etc/yum.repos.d/epel.repo и устанавливает ключ подписи EPEL в /etc/pki/rpm-gpg/. Убедитесь в наличии gpgcheck=1 в этом файле и игнорируйте любые руководства, предлагающие обойти ошибку подписи с помощью --nogpgcheck. Ошибка проверки подписи означает, что пакет не является тем, за что себя выдает, либо на вашей системе неверно настроены часы.

В Rocky пакет epel-release также устанавливает небольшую вспомогательную утилиту по пути /usr/bin/crb, поэтому sudo crb enable и crb status выполняют одну и ту же задачу без использования плагина. Проверьте наличие этой утилиты с помощью command -v crb, прежде чем полагаться на неё, так как она присутствует не во всех ветках каждого пересборочного дистрибутива.

Чтобы убедиться, что репозиторий EPEL доступен, а не просто числится в списке, запросите пакет, который есть только в нём:

dnf repoquery --repo=epel htop

Команда выведет имя пакета, версию и архитектуру. Отсутствие вывода означает, что репозиторий включен, но не возвращает данные; обычно это проблема зеркала или метаданных, а не конфигурации, поэтому попробуйте выполнить sudo dnf clean all && sudo dnf makecache.

Почему dnf сообщает, что команда config-manager не найдена

Это первая проблема, с которой сталкиваются пользователи, и она возникает именно на тех образах, которые предоставляют большинство VPS-провайдеров.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager — это плагин, а не встроенная подкоманда dnf. Он поставляется в составе dnf-plugins-core, который устанавливается при полной установке сервера, но отсутствует в минимальных образах, облачных образах и образах контейнеров. Подсказка самого dnf работает, так как пакет объявляет эту виртуальную возможность:

sudo dnf install -y 'dnf-command(config-manager)'

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

Если вы не можете установить плагин, потому что нужный репозиторий отключен, отредактируйте файл вручную. Найдите файл, содержащий нужную секцию, откройте его и установите enabled=1 в разделе [crb]:

grep -rl crb /etc/yum.repos.d/

Это именно то, что делает config-manager, поэтому при ручном редактировании данные не теряются. dnf repolist --enabled подтверждает результат.

Некоторые пакеты EPEL не устанавливаются, пока включен CRB

Вторая распространенная ловушка приводит к ошибке, в которой не упоминается CRB. Пакет EPEL, который ссылается на библиотеку, поставляемую только в CRB, вызывает сбой при разрешении зависимостей. В сообщении об ошибке указывается имя библиотеки и пакета, которому она потребовалась:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

Причина заключается в том, что CRB отключен, поэтому dnf не видит единственный репозиторий, предоставляющий эту библиотеку. Проверьте два условия по порядку:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Если вторая команда называет пакет, а обычная установка по-прежнему завершается с ошибкой, значит, CRB выключен. Этот класс ошибок встречается настолько часто, что в AlmaLinux версии 10 репозиторий CRB включили по умолчанию, чтобы предотвратить подобные ситуации. Флаг --enablerepo=crb также работает для разовой установки, но если вы используете EPEL, оставьте CRB включенным постоянно. Следующее обновление EPEL может потребовать новую зависимость из CRB без предварительного уведомления.

Из какого репозитория был установлен этот пакет?

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

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info для установленного пакета выводит строку From repo. dnf list installed отображает ту же информацию в третьем столбце с префиксом @, поэтому @epel означает установку из EPEL, а @System указывает на то, что dnf не знает источник пакета, что обычно происходит после выполнения rpm -i для скачанного файла. Строка repoquery показывает количество пакетов для каждого репозитория — это самый быстрый способ обнаружить, что на унаследованном вами сервере есть сорок пакетов из репозитория, о котором вы никогда не слышали. Последняя команда выводит точный список того, что было установлено из конкретного репозитория; этот перечень необходим перед принятием решения об удалении репозитория.

Аналогом в apt является apt-cache policy <package>, а таблицу эквивалентов команд dnf и apt стоит держать открытой во второй вкладке в течение первого месяца, так как концепции легко сопоставляются, даже если флаги различаются.

Как предотвратить замену базового пакета сторонним репозиторием?

EPEL гарантирует, что не будет этого делать. Другие репозитории таких гарантий не дают. Сторонний репозиторий с базой данных, агентом или средой выполнения может поставлять собственную сборку библиотеки, которая уже есть в BaseOS. dnf установит её, так как правило по умолчанию простое: побеждает более высокая версия, независимо от источника.

Два параметра решают большую часть задач, оба находятся в файле репозитория в разделе /etc/yum.repos.d/.

priority= определяет, какой репозиторий имеет приоритет, если один и тот же пакет есть в нескольких источниках. Побеждают меньшие числа, значение по умолчанию — 99. Установите для базовых репозиториев низкий приоритет, а для сторонних — высокий. Тогда dnf будет выбирать базовый пакет, даже если версия в стороннем репозитории новее. Современный dnf справляется с этим самостоятельно, поэтому отдельный пакет yum-plugin-priorities, использовавшийся в эпоху CentOS 7, больше не требуется.

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

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

В версии 8 есть еще один важный параметр. Пакет из стороннего репозитория может быть скрыт, если модуль AppStream предоставляет пакет с тем же именем. Параметр module_hotfixes=1 в секции репозитория указывает dnf не фильтровать его. Если пакет, который точно есть в стороннем репозитории, не находится или не устанавливается на системе версии 8, причина обычно в этом: модульная фильтрация делает его невидимым для большинства команд dnf вместо сообщения о конфликте. В версии 9 модулей меньше, но потоки модулей (module streams) остались, поэтому такая фильтрация может применяться, если пакет поставщика совпадает по имени с модульным.

Чтобы закрепить конкретную версию пакета, установите python3-dnf-plugin-versionlock и используйте sudo dnf versionlock add <package>. Это аналог apt-mark hold. Учтите разницу, которая часто сбивает с толку тех, кто перешел с Debian: в apt побеждает более высокий Pin-Priority, а в dnf — более низкий priority.

Почему смешивание репозиториев, близких к RHEL, делает сервер невозможным для обновления

Rocky, Alma, CentOS Stream, Oracle Linux и RHEL достаточно близки, чтобы их пакеты устанавливались друг на друга, но при этом достаточно далеки, чтобы результат перестал быть системой, которую кто-либо может поддерживать. Почему они настолько близки и почему Stream теперь находится перед RHEL, а не рядом с ним — это история о том, как Red Hat Linux разделился на Fedora и RHEL и что стало с CentOS.

Механизм заключается в номерах версий. CentOS Stream 9 опережает RHEL 9, и Red Hat описывает код Stream как то, что станет следующим минорным релизом RHEL. Если указать для системы Rocky 9 репозиторий Stream, даже один раз и даже для одного пакета, вы получите пакеты, версии которых выше тех, что Rocky поставляет сегодня. Более поздний минорный релиз Rocky может догнать их, но нет никаких гарантий, что он будет содержать этот пакет в той же или более высокой версии, и пока этого не произойдет, dnf upgrade не будет его обновлять. Машина теперь работает на комбинации, которую никто не тестировал, и она может оставаться в таком состоянии годами, пока вы будете считать, что она обновлена.

Симптомом является то, что dnf upgrade сообщает об отсутствии задач, в то время как sudo dnf distro-sync предлагает понизить версию (downgrade) длинного списка пакетов. distro-sync — это инструмент для исправления: он принудительно приводит каждый установленный пакет в соответствие с тем, что предлагают включенные репозитории, включая понижение версий. Сначала отключите сторонний репозиторий, затем запустите команду и внимательно прочитайте предложенный список перед тем, как подтвердить его. Исправление не удастся, если старая версия RPM больше не находится на зеркале, и в этот момент переустановка сервера с чистого образа будет быстрее и безопаснее, чем борьба с разрешением зависимостей.

Остатки эпохи ELevate — еще один распространенный вариант этой проблемы. ELevate — это инструмент миграции AlmaLinux, построенный на базе Leapp, который используется для обновления системы CentOS 7 или конвертации между пересборками (rebuilds). Поспешная миграция оставляет файлы репозиториев EL7 в /etc/yum.repos.d/ и установленные пакеты EL7. Найдите их с помощью rpm -qa | grep el7. Каждый из них — это пакет, который не может обновить ни один включенный репозиторий, и при последующем запуске Leapp они отображаются как пакеты, которые он не может сопоставить, что становится блокировщиком обновления, который приходится устранять вручную. Удаляйте их, пока сервер работает в штатном режиме, а не в день, когда вам потребуется следующее мажорное обновление.

Репозиторий поставщика, перекрывающий пакет из AppStream, — это мягкая форма той же болезни, и строка includepkgs выше является лекарством. Инструменты для контейнеров — типичный случай, так как containerd.io из собственного репозитория Docker конфликтует с runc из AppStream, поэтому один из них должен быть удален. Примите решение один раз, запишите исключение и следуйте проверенному порядку: руководство по установке Docker на Rocky Linux описывает, какие пакеты дистрибутива нужно удалить в первую очередь.

Переход от apt к dnf при работе с репозиториями

• /etc/apt/sources.list.d/*.sources заменяется на /etc/yum.repos.d/*.repo, где один файл может содержать несколько [sections], каждый со своим идентификатором.
• add-apt-repository universe заменяется на dnf install epel-release, с той разницей, что universe по-прежнему находится в собственном архиве Ubuntu, а EPEL является отдельным проектом.
• apt update не имеет прямого аналога, это нужно учитывать. dnf обновляет метаданные по собственному расписанию, а dnf makecache принудительно запускает этот процесс сейчас.
• apt-cache policy <pkg> заменяется на dnf info <pkg>, плюс dnf list --showduplicates <pkg> для просмотра всех доступных версий.
• apt-mark hold заменяется на dnf versionlock add из python3-dnf-plugin-versionlock.
• Pinning в /etc/apt/preferences.d/ заменяется на priority= в секции репозитория, при этом нумерация приоритетов работает в обратном порядке.
• dpkg -S /path/to/file заменяется на rpm -qf /path/to/file.

Автоматические обновления переносятся как концепция, а не как синтаксис, поскольку здесь нет unattended-upgrades. Таймер, файл конфигурации и вопрос о необходимости перезагрузки описаны в dnf-automatic в Rocky и Alma.

Поддерживайте список репозиториев в актуальном состоянии

Включите CRB, установите epel-release, а затем задокументируйте выполненные действия и их причины в системе управления конфигурациями или в текстовом файле на самом сервере. Эта заметка будет крайне полезна через три года, когда сервер перейдет под управление другого администратора.

Выполняйте поиск перед добавлением новых источников. Запустите dnf search, затем dnf info, и только после этого рассматривайте возможность подключения нового репозитория. Значительная часть пакетов, ради которых пользователи подключают EPEL, уже присутствует в AppStream. Мониторинг системы — самый наглядный пример: Performance Co-Pilot входит в базовые репозитории и не требует сторонних источников. Каждый дополнительный репозиторий — это еще один поставщик, который может выпустить обновление в любой момент, и каждый из них усложняет последующее крупное обновление дистрибутива.

Если вы все еще выбираете между двумя дистрибутивами, имейте в виду, что структура системы в них идентична, а epel-release работает одинаково. Реальные различия кроются в другом: сравнение Rocky Linux и AlmaLinux подробно описывает философию пересборки, поскольку AlmaLinux теперь ориентируется на ABI-совместимость (интерфейс двоичного уровня), а не на побайтовую идентичность исходному коду.

FAQ

Как включить EPEL в Rocky Linux 9 или AlmaLinux 9?

Выполните sudo dnf install -y dnf-plugins-core, затем sudo dnf config-manager --set-enabled crb и sudo dnf install -y epel-release. Подтвердите действие командой dnf repolist --enabled, которая должна вывести список baseos, appstream, extras, crb и epel. Включите CRB перед установкой пакетов из EPEL, так как многие из них зависят от библиотек, доступных только в CRB. В версии 8 идентификатор репозитория — powertools, а не crb.

Безопасно ли включать EPEL на сервере в production?

Этот репозиторий широко используется и основан на политике, согласно которой пакеты EPEL никогда не заменяют пакеты из базового дистрибутива, поэтому его включение не влияет на компоненты BaseOS или AppStream. Нюанс заключается в поддержке: EPEL — это волонтерский проект Fedora без соглашения об уровне обслуживания (SLA), а правила жизненного цикла пакетов EPEL требуют от мейнтейнера поддержки пакета в течение всего одного минорного релиза RHEL или 13 месяцев. Ведите учет установленных пакетов с помощью dnf repository-packages epel list installed и используйте dnf versionlock для любого пакета EPEL, от которого зависит клиентский сервис.

Почему dnf сообщает, что команда config-manager не найдена?

Потому что config-manager — это плагин для dnf, а не встроенная команда, и минимальные образы или образы контейнеров поставляются без dnf-plugins-core. Само сообщение содержит решение: sudo dnf install -y 'dnf-command(config-manager)' (команду нужно взять в кавычки, чтобы оболочка не интерпретировала скобки). Если вы пока не можете ничего установить, выполните grep -rl crb /etc/yum.repos.d/, откройте указанный файл и вручную установите enabled=1 в секции [crb].

В чем разница между CRB и PowerTools?

Это один и тот же репозиторий под разными названиями. В версии 8 он называется PowerTools с идентификатором powertools, в версии 9 и новее — CRB с идентификатором crb, а в продуктах Red Hat этот контент называется CodeReady Linux Builder. Он содержит заголовочные файлы для разработки, статические библиотеки и инструменты для сборки; в Rocky и AlmaLinux 9 он отключен по умолчанию. В AlmaLinux 10 он включен по умолчанию начиная с версии 10.0, поэтому проверьте dnf repolist --enabled перед выполнением команды включения.

Как удалить EPEL, ничего не сломав?

Сначала составьте список установленных пакетов с помощью dnf repository-packages epel list installed, так как удаление только пакета epel-release не удаляет ничего, что было установлено из EPEL. Эти пакеты останутся на диске, потеряют источник обновлений и перестанут получать исправления безопасности без каких-либо уведомлений. Принимайте решение по каждому пакету отдельно, удалите или замените те, которые вам больше не нужны, и только после этого выполняйте sudo dnf remove epel-release. Если какой-либо пакет из EPEL не был заменен и его необходимо удалить, sudo dnf repository-packages epel remove очистит набор за одну транзакцию, поэтому внимательно изучите предложенный список перед подтверждением.