Можно ли заменить centos-release и репозитории вручную?

Нет. Массовая замена centos-release, файлов .repo или GPG-ключей не считается универсальным переходом на поддерживаемую ОС. Такой подход может оставить смешанный набор пакетов, вызвать неразрешимые зависимости или сделать систему незагружаемой. Для CentOS Linux 8 используйте документированный конвертер выбранного проекта, а для CentOS 7 — только подтверждённый маршрут ELevate/Leapp либо новую установку.

Можно ли обновить CentOS 7 сразу до EL9?

Зависит от актуальной матрицы ELevate для конкретной версии, архитектуры и целевого профиля. Не следует предполагать, что CentOS 7 автоматически обновляется сразу до EL9: технически допустимый маршрут определяется документацией инструмента. Даже переход на EL8 возможен только после проверки совместимости, устранения всех inhibitors Leapp и подтверждения приложения для целевого выпуска.

Что делать, если Leapp показывает inhibitor?

После leapp preupgrade просмотрите /var/log/leapp/leapp-report.txt: Leapp также обычно создаёт JSON-отчёт в /var/log/leapp/. Каждый inhibitor нужно разобрать применительно к серверу, его загрузке, сети, драйверам, пакетам и прикладным службам. Перед повторной проверкой убедитесь, что действия соответствуют актуальному руководству для точной пары релизов и выбранного профиля ELevate. Не используйте универсальные ответы из случайных инструкций: допустимые изменения answerfile, пакетов и конфигурации зависят от версии инструмента и профиля. После каждого исправления повторяйте предварительную проверку. К leapp upgrade переходят только при отсутствии inhibitors, после внесения требуемых ответов и проверки плана восстановления. Если блокировку нельзя устранить без неподтверждённых изменений, не продолжайте обновление на месте: разверните новую систему на подходящем целевом выпуске и перенесите данные и настройки по плану приложения.

Достаточно ли snapshot виртуальной машины для отката?

До окна работ определите конкретную точку восстановления: образ системы, проверенную резервную копию файлов и данных приложения, snapshot виртуальной машины либо запасной узел. Проверьте не только наличие копии, но и то, что её можно прочитать и восстановить на совместимое оборудование или виртуальную платформу. Отдельно спланируйте данные, которые могут измениться после создания копии: остановку записи, репликацию, журналирование, экспорт или повторный ввод. Назначьте ответственных за решение об откате, допустимый простой и момент, после которого возврат уже нецелесообразен. Нужен также независимый от SSH доступ через KVM/IPMI/iDRAC/iLO, консоль гипервизора или физический доступ. После тестового восстановления должно быть возможно поднять сеть, войти в систему и запустить критичную службу.

Как понять, что миграция завершилась успешно?

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

Переход с CentOS на Rocky Linux или AlmaLinux

Переход с CentOS на Rocky Linux или AlmaLinux начинается с выбора маршрута, а не со смены репозиториев. Для CentOS Linux 8 иногда допустима документированная конвертация в дистрибутив того же поколения EL8; CentOS 7 может переходить на EL8 только как межпоколенческое обновление через ELevate на базе Leapp. Если конкретная пара релизов, архитектура, пакеты или приложение не входят в актуальную документацию инструмента, безопаснее развернуть новую систему и перенести данные.

Не заменяйте release-пакеты и репозитории вручную

Массовая подмена centos-release, файлов .repo или GPG-ключей по случайной инструкции не является универсальным переходом на поддерживаемую ОС. Она может оставить смешанный набор пакетов, неразрешимые зависимости и систему, которая не загружается. Операции с RPM-пакетами, репозиториями и ключами выполняют только по документированному маршруту выбранного проекта.

Сначала разделите CentOS 7, CentOS Linux 8 и CentOS Stream

CentOS 7 и CentOS Linux 8 — разные исходные платформы: у них отличаются поколения библиотек, ядра, менеджер пакетов и допустимые пути обновления. CentOS Linux 8 можно рассматривать для конвертации внутри EL8. Маршрут CentOS 7 → EL8 меняет основное поколение ОС и потому не является простой конвертацией.

CentOS Stream — отдельный дистрибутив и не «переименованный» CentOS Linux. Не используйте его как промежуточный этап, если такой путь прямо не описан в актуальной документации средства миграции. О статусе CentOS и различиях выпусков — в статье «CentOS Stream и CentOS 7: статус поддержки, различия и выбор сценария».

Выбор маршрута перехода

Исходная система	Возможный маршрут	Когда допустим	Когда выбрать новую установку
CentOS Linux 8	Конвертация в Rocky Linux 8 или AlmaLinux 8	Актуальное руководство выбранного инструмента прямо включает точный исходный выпуск, целевой EL8-выпуск, архитектуру и тип системы; предварительные проверки не выявляют блокирующих проблем	Нет документированного маршрута; есть неподдерживаемые сторонние пакеты, драйверы или приложение; нужна смена архитектуры, схемы дисков или роли сервера
CentOS 7	Межпоколенческое обновление до EL8 через ELevate и Leapp	Матрица ELevate включает исходный CentOS 7, выбранный целевой профиль, архитектуру и вариант системы; все блокирующие проверки устранены	Целевой профиль не подтверждён матрицей; отчёт Leapp содержит неустранённые inhibitors; приложение или его поставщик не подтверждают EL8
CentOS 7 или CentOS Linux 8	Новая установка Rocky Linux или AlmaLinux с переносом данных и конфигурации	Целевой выпуск поддерживает оборудование, архитектуру и приложение, а план предусматривает перенос данных, проверку результата и допустимое окно работ	Выбирайте при отсутствии документированного маршрута миграции на месте, необходимости изменить платформу или разметку либо при неприемлемом риске обновления существующей системы

Срок сопровождения целевого поколения

На момент подготовки плана сверяйте страницу жизненного цикла конкретного проекта. Для семейства EL8 Rocky Linux и AlmaLinux указывают окончание жизненного цикла в 2029 году, для EL9 — в 2032 году. Переход CentOS 7 на EL8 может быть технически допустимым, но срок сопровождения EL8 следует сопоставить с плановым сроком службы сервера. Не предполагайте, что маршрут CentOS 7 сразу ведёт на EL9: это определяется матрицей ELevate для конкретной версии.

Проверьте, поддержан ли маршрут именно для этого сервера

Сначала откройте актуальное официальное руководство migrate2rocky для Rocky Linux либо almalinux-deploy для AlmaLinux — для конвертации CentOS Linux 8. Для CentOS 7 используйте актуальную матрицу ELevate и документацию Leapp. В ней должны одновременно совпадать исходный и целевой релизы, архитектура, тип установки, требования к свободному месту и состояние установленных пакетов.

Наличие целевого профиля в ELevate означает, что такой профиль доступен инструменту; само по себе это не доказывает официальную поддержку маршрута со стороны Rocky Linux или AlmaLinux. Если целевой проект не публикует отдельного подтверждения сценария CentOS 7 → его EL8-выпуск, не приписывайте ему такую гарантию.

Сверьте архитектуру: не переносите выводы для x86_64 на другую архитектуру без прямого указания в матрице.
Уточните, является ли система обычной установкой ОС, а не специализированным образом, appliance или узлом с вендорским стеком.
Проверьте наличие свободного места в корневой файловой системе и в /boot; конкретные требования берите из руководства используемой версии инструмента.
Убедитесь, что установленная система приведена в требуемое инструментом состояние: отсутствуют незавершённые транзакции, повреждённая база пакетов и исключённые из обновления критичные пакеты.
Отдельно подтвердите совместимость прикладной нагрузки, лицензий, агентов, драйверов и интеграций с выбранным целевым выпуском.

Инвентаризация до окна работ

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

inventory-before-migration.sh

mkdir -p /root/migration-inventory
cat /etc/os-release | tee /root/migration-inventory/os-release.txt
uname -a | tee /root/migration-inventory/uname.txt
uname -m | tee /root/migration-inventory/architecture.txt
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort \
  > /root/migration-inventory/rpm-list.txt
rpm -qa --qf '%{NAME}\t%{VENDOR}\t%{PACKAGER}\n' | sort \
  > /root/migration-inventory/rpm-origin-hints.txt
rpm -qa --qf '%{NAME}\n' | sort > /root/migration-inventory/rpm-names.txt
systemctl list-unit-files --type=service --state=enabled \
  > /root/migration-inventory/enabled-services.txt
systemctl --failed > /root/migration-inventory/failed-services-before.txt
findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS > /root/migration-inventory/mounts.txt
lsblk -f > /root/migration-inventory/lsblk.txt
cat /proc/cmdline > /root/migration-inventory/kernel-command-line.txt
rpm -q grub2-efi shim grub2-pc 2>&1 | tee /root/migration-inventory/boot-packages.txt

Дополните каталог инвентаризации копиями /etc/fstab, настроек сети и DNS, конфигураций приложений, списков локальных пользователей и групп, заданий по расписанию, описаний монтируемых сетевых ресурсов и сведений о сертификатах. Не копируйте секреты в незащищённое хранилище: зафиксируйте их расположение, владельца и способ безопасного восстановления. Порядок учётных записей и прав описан в материале о пользователях, группах, sudo и правах.

На CentOS Linux 8 сохраните включённые и выключенные репозитории. Если в системе используется YUM или команда `dnf` недоступна, примените эквивалентную команду `yum repolist all`.

dnf repolist --all 2>&1 | tee /root/migration-inventory/repositories.txt

На CentOS 7 сохраните перечень репозиториев до установки ELevate. Проверяйте также файлы в `/etc/yum.repos.d/` и локальные репозитории организации.

yum repolist all 2>&1 | tee /root/migration-inventory/repositories.txt

Зафиксируйте критичные системные службы: базы данных, веб-службы, очереди, мониторинг, резервное копирование, аутентификацию и собственные units.
Запишите адреса, порты, DNS-имена, внешние API, LDAP/AD, NFS/iSCSI, балансировщики, почтовые шлюзы и другие точки интеграции.
Определите фактический способ загрузки: BIOS или UEFI, наличие Secure Boot, используемый загрузчик, отдельный /boot, LVM, RAID, шифрование и особенности виртуальной платформы.
Составьте критерии приёмки приложения: кто выполняет проверку, какие запросы, задания и интеграции должны сработать, какой результат считается нормальным.
Зафиксируйте версию и запущенное ядро Linux, а также параметры командной строки ядра. Загрузка старого ядра после обновления не подтверждает успешную миграцию.

Разберите сторонние пакеты до начала миграции

Пакеты из EPEL, сторонних репозиториев, локальные RPM, проприетарные драйверы, DKMS-модули, модули ядра, агенты мониторинга и резервного копирования не становятся совместимыми автоматически. После смены основного поколения меняются ABI ядра, версии библиотек и зависимости пакетов.

Проверка нестандартных компонентов

Выполните её до запуска любого средства миграции.

1
Выделите пакеты не из штатных репозиториев
Сопоставьте rpm-list.txt, rpm-origin-hints.txt и перечень репозиториев с базовым составом системы. Не считайте поле Vendor единственным доказательством происхождения: используйте также внутреннюю документацию и договорённости с поставщиками.
2
Проверьте модули и драйверы
Зафиксируйте вывод lsmod, modinfo для нестандартных модулей и установленное ПО драйверов. Получите у поставщика подтверждение для конкретного целевого выпуска и ядра либо подготовьте поддерживаемую замену.
3
Подтвердите приложение
Проверьте требования приложения к версии интерпретатора, библиотек, Java, PHP, Python, СУБД и криптографических политик. Если поставщик поддерживает только новую чистую установку, не обходите это ограничение миграцией на месте.
4
Выберите действие для каждого компонента
Для каждого неподдерживаемого пакета заранее определите: удалить перед миграцией, заменить поддерживаемой версией, отключить и установить заново после перехода либо отказаться от миграции на месте. Не удаляйте пакет, пока не понятны его зависимости и последствия для приложения.

Подготовьте восстановление, а не только копию

Снимок не равен плану отката

Резервная копия, snapshot виртуальной машины, загрузка со старым ядром и откат пакетной транзакции — разные сценарии с разными ограничениями. Не рассчитывайте, что dnf history undo, старое ядро или снимок автоматически вернут согласованное состояние ОС и данных приложения после межпоколенческой миграции.

Определите точку восстановления: образ системы, проверенная резервная копия файлов и данных приложения, snapshot виртуальной машины или развёртывание запасного узла.
Проверьте, что копию можно прочитать и что есть процедура восстановления именно на совместимое оборудование или виртуальную платформу.
Назначьте консольный доступ, независимый от SSH: KVM/IPMI/iDRAC/iLO, virtual console гипервизора или физический доступ. Проверьте права доступа до окна работ.
Определите допустимый простой, ответственных за решение об откате и момент, после которого откат уже нецелесообразен.
Опишите судьбу данных, изменившихся после создания копии: остановка записи, журналирование, репликация, экспорт, повторный ввод или другой согласованный способ.
Проверьте, что после восстановления можно поднять сеть, войти в систему и вернуть критичную службу в работу.

Откат пакетной операции допускается только в пределах, описанных менеджером пакетов и средством миграции; восстановление snapshot зависит от гипервизора и согласованности дисков; резервное восстановление зависит от продукта резервного копирования. Детали общего восстановления загрузки вынесены в статью о GRUB, initramfs и kernel panic, а технологии резервного копирования в этой инструкции не рассматриваются.

Проведите пробный переход и назначьте контрольные точки

План работ перед продуктивной миграцией

1
Соберите аналог непроизводственной системы
По возможности используйте копию виртуальной машины или сервер с теми же пакетами, конфигурацией и интеграциями без рабочих данных. Проверьте выбранный маршрут и зафиксируйте фактические изменения.
2
Согласуйте окно и критерии остановки
Остановите задания и записи в приложение по его регламенту. До начала определите, какие ошибки означают немедленную остановку: неустранённый inhibitor Leapp, отсутствие совместимой замены драйвера, недоступная консоль или неработоспособная резервная копия.
3
Сделайте свежую копию и проверьте консоль
Создайте согласованную с приложением копию после остановки или перевода в подходящий режим. Убедитесь, что можно открыть консоль и выбрать загрузочное устройство, не полагаясь на работающую сеть.
4
Выполните предварительную проверку средства миграции
Установите только те пакеты средства и источники пакетов, которые перечислены в текущем официальном руководстве для вашей пары релизов. Не подставляйте имена пакетов, URL, ключи и параметры из руководства для другой версии.
5
Проанализируйте отчёт до необратимых действий
Не переходите к перезагрузке, пока не устранены все блокирующие сообщения и не оценены предупреждения, относящиеся к вашим службам, загрузке и сети. Повторяйте проверку после каждого изменения.

Конвертация CentOS Linux 8 в Rocky Linux 8 или AlmaLinux 8

Для перехода в пределах EL8 используйте собственный документированный конвертер выбранного проекта: migrate2rocky для Rocky Linux или almalinux-deploy для AlmaLinux. Такие средства заменяют дистрибутивные пакеты и метаданные согласованной процедурой; это не то же самое, что ручная правка репозиториев.

Процедура конвертации CentOS Linux 8

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

1
Подтвердите совместимую исходную версию
Сопоставьте /etc/os-release, архитектуру и инвентаризацию с матрицей конвертера. Если исходный выпуск, архитектура или тип установки не указаны, не продолжайте.
2
Подготовьте штатные источники пакетов
Подключите только репозитории и ключи, которые требует руководство конвертера. Отключите или удалите сторонние источники в той мере, которую предписывает документация, предварительно зафиксировав их и зависимости приложений.
3
Запустите конвертер по документации проекта
Не добавляйте произвольные флаги для игнорирования проверок и не меняйте список заменяемых пакетов вручную. Сохраните вывод команды, журнал и перечень планируемых замен.
4
Остановитесь при ошибке или неясном предупреждении
При ошибке пакетной операции, конфликте зависимостей, проблеме с ключом, нехватке места или нераспознанном пакете не продолжайте перезагрузкой. Вернитесь к инвентаризации, устраните причину по документации инструмента либо выберите новую установку.
5
Перезагрузите сервер только после успешного завершения процедуры
Следите за первой загрузкой через консоль. После запуска не считайте работу завершённой до проверки ОС, репозиториев, служб и приложения.

Обновление CentOS 7 до EL8 через ELevate и Leapp

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

Типичная документированная предварительная проверка ELevate/Leapp после установки пакетов ELevate для точно поддержанной пары релизов. Запускайте её только после выполнения шагов из актуального руководства для выбранного целевого профиля.

leapp preupgrade

Leapp обычно формирует текстовый и JSON-отчёты в /var/log/leapp/, включая leapp-report.txt и leapp-report.json. Блокирующие сообщения обозначаются как inhibitors. Точные наборы файлов, ответы в answerfile и допустимые действия зависят от версии ELevate и данных целевого профиля; ориентируйтесь на отчёт и официальную документацию, а не на универсальный список ответов из интернета.

Просмотрите отчёт после `leapp preupgrade`. Наличие inhibitor означает, что переход нельзя продолжать, пока причина не устранена документированным способом.

less /var/log/leapp/leapp-report.txt

Команда подготовки обновления для ELevate/Leapp. Выполняйте её только когда `leapp preupgrade` завершился без inhibitors, все требуемые ответы внесены по документации и план восстановления проверен.

leapp upgrade

Не обходите inhibitors автоматически

Inhibitor — не косметическое предупреждение, а блокировка продолжения перехода. Не удаляйте пакеты, не редактируйте answerfile и не применяйте флаги обхода только ради успешного запуска. Если действие не описано для вашей версии ELevate и целевого профиля, остановите миграцию и рассмотрите чистую установку.

После успешной подготовки leapp upgrade требуется перезагрузка в среду обновления. Контролируйте её через консоль, а не только по SSH. Если сервер не загружается, не выполняйте случайные исправления поверх частично изменённой системы: используйте согласованный план восстановления и материалы о восстановлении загрузки Linux.

Когда вместо миграции нужна новая установка

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

В этом сценарии поднимите новый сервер на поддерживаемом целевом выпуске, перенесите данные и настройки по плану приложения, проведите функциональную приёмку и только затем переключайте трафик. Подробности установки вынесены в «Rocky Linux и AlmaLinux: установка и первичная настройка сервера» и «Установка Linux на физический сервер: подготовка и первый запуск».

Проверьте ОС, службы и прикладную нагрузку после перехода

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

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

cat /etc/os-release && uname -r && uname -m

Проверьте, что подключены штатные репозитории целевого дистрибутива и не остались случайно включённые репозитории CentOS Linux, тестовые либо сторонние источники. На EL8 команда `yum repolist all` обычно может быть совместимым интерфейсом, но для проверки используйте штатный менеджер пакетов целевой ОС.

dnf repolist --all

Проверьте список служб в состоянии failed. Затем выполните `systemctl status имя.service` для каждой критичной службы, подставляя реальные имена юнитов из инвентаризации; статус `active` не заменяет проверку прикладного ответа.

systemctl --failed

Просмотрите сообщения текущей загрузки с уровнем warning и более серьёзными приоритетами. [journalctl](/baza-znaniy/glossariy/journalctl) показывает системный журнал; отфильтруйте вывод по конкретной службе, устройству или времени, если это предусмотрено вашим чек-листом.

journalctl -b -p warning

Сверьте /etc/os-release, запущенное ядро, архитектуру и схему монтирования с ожидаемым результатом.
Подтвердите доступ администратора через штатный канал, работу сети, DNS, синхронизации времени и требуемых хранилищ — в объёме критериев приложения.
Проверьте критичные для приложения состояния SELinux, правил межсетевого экрана, TLS-сертификатов и криптографических политик по заранее подготовленному чек-листу.
Проверьте, что нет неожиданно включённых репозиториев исходной ОС и что нужные пакеты получаются из ожидаемых источников.
Для каждой критичной службы проверьте состояние через systemctl, автозапуск, журнал и реальную функцию: соединение, запрос, обработку задания или обмен с внешней системой.
Проверьте задания Cron и systemd timers, если они участвуют в работе приложения; не ограничивайтесь фактом наличия их файлов.
Сравните с предмиграционной инвентаризацией отсутствующие пакеты, units, точки монтирования и конфигурационные файлы.
Зафиксируйте результаты приёмки, известные отклонения и действия по восстановлению отключённых сторонних компонентов.

Команды systemctl и анализ журналов здесь служат только контрольным списком. Подробная работа со службами описана в «systemd и systemctl: управление службами и автозагрузкой Linux», а с журналами — в «Журналы Linux: journalctl, rsyslog и logrotate».

Термины в статье

Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Зависимость пакета: Зависимость пакета — требование пакета к другому пакету или его версии, без выполнения которого установка, запуск либо корректное обновление ПО невозможны или ограничены.
Менеджер пакетов: Менеджер пакетов — средство установки, обновления, удаления и учёта программных пакетов; высокоуровневые менеджеры также работают с репозиториями и разрешают зависимости.
Пакетная транзакция: Пакетная транзакция — согласованный набор действий по установке, обновлению, удалению и настройке пакетов, формируемый менеджером пакетов в рамках одной команды или задания.
Репозиторий пакетов: Репозиторий пакетов — структурированный источник пакетов и метаданных, из которого менеджер пакетов получает версии ПО, зависимости, обновления и информацию о подписях.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Ядро Linux: Ядро Linux — центральный компонент ОС, управляющий аппаратными ресурсами и предоставляющий системные интерфейсы; оно не включает пользовательские утилиты и менеджер пакетов.
AlmaLinux: AlmaLinux — корпоративный дистрибутив Linux, поддерживаемый сообществом и AlmaLinux OS Foundation, ориентированный на совместимость с интерфейсами и экосистемой RHEL.
CentOS Linux: CentOS Linux — прекращённый свободно доступный дистрибутив Linux, создававшийся из исходных пакетов RHEL и ориентированный на бинарную совместимость с соответствующим выпуском RHEL.
Cron: Cron — служба-планировщик в Unix-подобных ОС, запускающая команды по расписаниям из таблиц crontab, обычно с минутной дискретностью.
DNF: DNF — менеджер пакетов для RPM-дистрибутивов, разрешающий зависимости и выполняющий операции с репозиториями; в современных системах он заменил классический YUM.
ELevate: ELevate — набор инструментов миграции Enterprise Linux между основными версиями, использующий Leapp и дополнительные данные для поддерживаемых путей перехода.
EOL: EOL — установленная поставщиком дата или стадия завершения жизненного цикла версии ПО либо модели оборудования; её последствия определяются политикой поставщика.
journalctl: journalctl — консольная утилита чтения и фильтрации журнала systemd, выводящая сообщения по времени, юниту, загрузке системы, приоритету и другим полям.
Leapp: Leapp — фреймворк для контролируемого обновления Enterprise Linux между основными версиями, выполняющий проверки совместимости и координирующий подготовку и выполнение перехода.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
Rocky Linux: Rocky Linux — корпоративный дистрибутив Linux, создаваемый из исходных пакетов экосистемы RHEL и ориентированный на совместимость с RHEL без использования его товарных знаков.
RPM-пакет: RPM-пакет — файл формата RPM для распространения бинарного ПО или исходного кода. Он содержит метаданные и обычно полезную нагрузку; зависимости и сценарии необязательны.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
systemctl: systemctl — командная утилита управления systemd, которая запускает и останавливает юниты, показывает их состояние и настраивает автоматическую активацию.
systemd: systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
YUM: YUM — менеджер пакетов для RPM-дистрибутивов Linux, который устанавливает, обновляет и удаляет ПО, автоматически разрешая зависимости из репозиториев.