ActiveScaleинженерная практика

Stage-1: установка ОС через iso_installer

Установка installstage1pxebootordermodelnetwork

Коротко. Stage-1 — интерактивный мастер iso_installer.py: он определяет профиль железа, раскладывает ОС на диски и оставляет на диске /usr/bin/marvin_install для следующего этапа. Два места, где ошибаются чаще всего: выбор сетевого интерфейса по индексу (имена портов в установщике переименовываются) и финальный ENTER без переключения BMC на диск в режиме UEFI. Успех проверяется не по «Installation complete», а по findmnt / уже после ребута.


1. Что делает stage-1

Установщик — не «образ на флешке», а мастер внутри live-среды. Он:

  1. определяет модель железа (identify_hardware()) и берёт профиль из /opt/ampli/cfg/product/hardware/types/;
  2. выбирает диски под ОС и раскладывает корневую ФС из squashfs на диски (mdadm-массивы, EFI);
  3. назначает остальным дискам роли blockstore / meta по профилю;
  4. копирует пакеты на диск, пишет сетевые конфиги, включает serial console;
  5. создаёт /usr/bin/marvin_install — точку входа для stage-2.

Приложения и S3 на этом этапе не появляются: stage-1 даёт только ОС и разметку.


2. Предусловия

  • Профиль железа на месте. На установленном диске тип железа есть, в live его нет. Если профиль не подложен в hardware/types/ до установки, диски разложатся по generic-шаблону — и дальше поедет вся модель (вплоть до пустых страниц в GUI). В наших сборках профиль вшит в образ; при установке со стока копировать вручную.
  • Диски пусты. Остатки прошлых прогонов (md-суперблоки, старые разделы) мешают раскладке.
  • Доступ к BMC и понимание BootOrder (см. PXE и live).
  • Учётная запись sysadmin в live доступна (в наших сборках ключ вшит).

Если ставите не первый узел — помните: имена интерфейсов в одной модели различаются. Снимать их надо с конкретной машины.


3. Запуск

Из меню live-среды пункт 1 (Start AMUR S3 installation). Если меню не появилось или нужен ручной запуск из шелла:

sudo /opt/ampli/apps/marvinbase/venv/bin/python \
     /opt/ampli/apps/marvinbase/tools/iso_installer.py

Дальше мастер задаёт вопросы по одному. Ответы:

Промпт Ответ
enter the number of your choice 1 — установка ОС и management-сервисов
continue installation? [y/n] y
>>> hostname <NODE_HOSTNAME>
>>> select interface to add IP address (index) индекс mgmt-порта (см. п. 4)
>>> IP address <MGMT_IP>
>>> subnet mask маска подсети (для /24 — стандартная)
>>> default gateway (optional) <MGMT_GW>
>>> DNS address ENTER — останется значение по умолчанию
>>> Reuse existing filesystems? [y/N] y
>>> Machine role (optional) SPXCTRLSTORAGEMGMT

4. Главная ловушка: интерфейс выбирается по индексу

Во время установки имена enp*/eth* переименовываются (remap systemd). Индекс в промпте — это позиция в списке, а не имя порта, и после установки имя может смениться ещё раз. Выбирать надо порт, который реально несёт mgmt-сеть.

Порядок действий до ответа на промпт — в live, до запуска установщика:

ip -br link        # список портов
ip -br a           # на каком порту появился адрес из mgmt-сети

Индекс берётся у порта, на котором живёт mgmt-адрес. Если ошибиться, после ребута адрес окажется на storage-порту: узел не пингуется по mgmt, установка формально «прошла». Лечится не переустановкой, а правкой модели на stage-3 — там сеть настраивается по MAC, а не по имени порта.


5. Reuse existing filesystems и роль

Промпт Reuse existing filesystems? на чистом диске переиспользовать нечего, но ответ y включает ветку, где установщик спрашивает роль. Роль вводится только при reuse=y; без неё ОС ставится как generic, приложения не моделируются, и configure на следующем этапе конфигурировать нечего.

Для кластера из трёх равноправных нод роль одна на всех — SPXCTRLSTORAGEMGMT (combined: управление и хранилище на одной ноде). Подробнее о выборе роли — Роли нод.


6. Финальный ENTER: сначала Boot, потом ребут

Установщик заканчивается приглашением Press ENTER to restart. Жать сразу нельзя: он делает жёсткий ребут, а дисковая ОС ставит UEFI-grub. BMC к этому моменту должен смотреть на диск:

curl -sk -u <BMC_USER>:<BMC_PASS> -X PATCH -H 'Content-Type: application/json' \
  -d '{"Boot":{"BootSourceOverrideTarget":"Hdd","BootSourceOverrideEnabled":"Once","BootSourceOverrideMode":"UEFI"}}' \
  https://<BMC_IP>/redfish/v1/Systems/system/

BootSourceOverrideMode=UEFI обязателен: без него OpenBMC подставит Legacy, и узел после ребута не выйдет в сеть. Только после PATCH — ENTER.


7. Проверка после ребута

Узел должен пинговаться по mgmt-адресу через 2–4 минуты, дальше по SSH:

findmnt /                 # корень на md-устройстве (у нас /dev/md4 ext4), НЕ overlay
id sysadmin               # учётная запись на диске существует
hostname                  # <NODE_HOSTNAME>
ls -la /usr/bin/marvin_install
  • findmnt / показывает /dev/md4 (в другой аппаратной раскладке встречается /dev/md3) — значит вы на диске. Если видно overlay или /cow — вы всё ещё в live, установка не прошла.
  • /usr/bin/marvin_install присутствует и является точкой входа stage-2.
  • initial_environment.json пока отсутствует — это норма, его создаст stage-2.

8. Если узел не поднялся

Симптом Что смотреть
не пингуется, KVM молчит Boot остался Legacy; повторить PATCH с UEFI и power cycle
снова ушёл в PXE BootOrder смотрит на сеть; переключить на Hdd
пингуется, но mgmt-адрес на чужом порту ошибка индекса интерфейса (п. 4)
корень overlay загрузились в live, а не с диска; проверить, что установка дошла до конца
нет marvin_install установка не дошла до post_install; смотреть лог установщика

9. Источники

  • Software Documentation Center (дата доступа 2026-11-07)
  • X200 Getting Started Guide (дата доступа 2026-11-07)
  • Наша практика (обезличено): прогоны stage-1 на 3-нодных стендах, две аппаратные платформы.
  • Обновлено: 2026-11-07.

Нужен инженер? Разберу вашу ситуацию и скажу, что делать — по шагам, с проверками.

Обсудить задачу