Anaconda kickstart: Сделайте загрузочный носитель доступным на этапе установки.

Вопрос или проблема

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

Я создал собственный RPM-пакет, который устанавливаю во время кастомной минимальной установки Rocky Linux (9.5) с помощью kickstart. Пакет требует доступа к сборочному носителю, чтобы увидеть детали конфигурации (которые могут изменяться) для полной установки и настройки.

Кажется, что сборочный носитель автоматически недоступен на этапе установки chroot в kickstart. Я могу видеть его на этапах %pre и %post.

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

%pre
MOUNT_SCRIPT_PATH="/tmp/mount_build_media.sh"
cat << EOF > "$MOUNT_SCRIPT_PATH"
SYS_ROOT_MOUNT="/mnt/sysimage"
MEDIA_PATH="\$SYS_ROOT_MOUNT/media"
while true; do
    if [ -d "\$MEDIA_PATH" ]; then
        mkdir "\$MEDIA_PATH/install"
        mount --bind "/run/install/repo" "\$MEDIA_PATH/install"
        break
    else
        sleep 1
    fi
done
EOF
chmod +x "$MOUNT_SCRIPT_PATH"
setsid "$MOUNT_SCRIPT_PATH" >/dev/null 2>&1 < /dev/null &

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

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

Вау, я искал нечто подобное для RHEL 9.5. Я делал это другим способом в более ранней версии, но это не сработало на RHEL 9.5. Следующий скрипт – мой текущий:

%pre
cat << EOF > /tmp/mounta
while true; do
    if [ -d /mnt/sysroot/root ]; then
          sleep 10
          mount --bind /run/install/repo /mnt/sysroot/opt
        break
    else
        sleep 5
    fi
done
EOF
chmod +x /tmp/mounta
setsid /tmp/mounta >/dev/null 2>&1 < /dev/null &

%end
%post --interpreter=/usr/bin/bash
#!/bin/bash

/opt/path-to-your-application-torun-from-DVD
%end

он ищет /mnt/sysroot/root, и как только он становится доступным, он монтирует DVD в каталог opt, но вот в чем дело. После того как /mnt/sysroot/root становится доступным, /mnt/sysroot/opt требует некоторое время, чтобы появиться, так как система ещё строится. Сначала это не сработало, потом я заметил, что он появился, и вставил 10-секундную задержку – Вуаля!

Ответ или решение

Вопрос о том, как сделать загрузочный носитель доступным во время установки через Anaconda и Kickstart в Rocky Linux, затрагивает довольно специфическую проблему, которая была явно недооценена в сообществе. Большинство существующих решений и документации не предусматривают этот сценарий напрямую, что вынуждает пользователей искать кастомные способы достижения цели. В данном случае, рассматривается пример, когда пользователь создает собственный RPM-пакет, требующий доступ к сборочному носителю для получения конфигурационных данных во время минимальной установки.

Теория

Anaconda — это программа для установки операционной системы в системах на базе Red Hat, включая Rocky Linux. Процесс установки часто автоматизируется с помощью файлов Kickstart, которые содержат все нужные параметры и сценарии для автоматизированной установки системы без вмешательства пользователя. Однако одна из сложностей, с которыми сталкиваются пользователи, заключается в том, что не все этапы установки предоставляют одинаковый доступ к системным ресурсам и носителям. Например, сборочный носитель, на котором находится весь инсталляционный контент, может быть недоступен в chroot окружении, которое используется Anaconda для установки пакетов.

Пример

Описанное в источнике решение начинает с выполнения скриптов на этапе %pre. Здесь создается и начинает выполняться скрипт, предназначенный для периодического опроса состояния установки и выполнения монтирования как только определённые каталоги системы становятся доступными. Скрипт ждет появления каталога /mnt/sysimage, в который в дальнейшем должен быть примонтирован сборочный носитель (/run/install/repo), и в котором находится система, будучи установленной. Монтирование осуществляется с помощью команды mount --bind.

Аналогичный подход предложен и другим пользователем для RHEL 9.5, где скрипт развертывания ждет появления каталога /mnt/sysroot/root. После его появления также выполняется монтирование через mount --bind, обеспечивая доступ к данным на носителе.

Применение

Для тех, кто хочет воспроизвести такие подходы в своих установленных системах, необходимо понимать, что такие решения могут не быть идеальными с точки зрения надежности. Основной проблемой является потенциальная зависимость от времени, так как система не всегда может создать нужные каталоги точно в предсказуемые моменты. Это требует внедрения временных задержек (sleep) и циклов опроса (polling) для асинхронного ожидания нужных событий, но это может оказаться неустойчивым подходом в более сложных сценариях развертывания.

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

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