PXE и загрузка live AMUR: что должно работать, чтобы узел поднялся

1. Два штатных способа попасть в live

Оба способа штатные. PXE удобнее для серии, virtual media — когда инфраструктуры нет или она под вопросом. Дальше речь про PXE: именно он даёт больше всего «молчаливых» отказов.

2. Зачем ProxyDHCP, если DHCP уже есть

Основной DHCP (роутер или сервер площадки) выдаёт адрес, шлюз и DNS. Про загрузку он не знает ничего. Поэтому рядом поднимается ProxyDHCP: он отвечает только клиентам, пришедшим с опцией 60 = PXEClient, и говорит, где взять загрузчик.

На DHCP площадки нужны опции: 66 — адрес TFTP-хоста (next-server), 67 — имя файла загрузчика, 60 — класс PXEClient, по которому выбирается набор опций. На самом PXE-хосте в dnsmasq нужны оба объявления:

dhcp-boot=amur.efi,,<ADMIN_NODE>
pxe-service=x86-64_EFI,Boot AMUR,amur.efi

pxe-service важнее: UEFI-стек сначала спрашивает именно ProxyDHCP, и без этого ответа клиент получает только адрес. Firewall/NAT на шлюзе трогать не нужно — ProxyDHCP не конфликтует с основным DHCP, пока next-server не меняется.

3. HTTP-раздача ISO и требование к url=

Live-среда грузится не целиком по TFTP: по сети уходит только ядро и initrd, а корневая ФС подтягивается по HTTP. Раздача поднимается на admin-узле:

cd /srv/http && sudo ln -sfn <ISO_PATH> /srv/http/<IMAGE>.iso
sudo python3 -m http.server 8080 --bind <BIND_ADDR> --directory /srv/http &

<BIND_ADDR> — адрес, на котором слушает раздача; в наших прогонах это «все интерфейсы», чтобы узел мог забрать образ по mgmt-сети.

Ключевое требование — аргумент url= в загрузчике обязан оканчиваться на .iso. В сценарии casper матчится шаблон url=*.iso; любое другое расширение молча игнорируется: NETBOOT пуст, дальше 60 секунд сканирования локальных дисков, паника и ребут. Подсунуть squashfs напрямую (url=...squashfs) нельзя — это не работает.

Второе требование — сам эндпоинт /pxe/. Он должен отдавать реальный файл (порядка нескольких сотен байт), а не строку LOCALBOOT: LOCALBOOT означает «грузи с диска», и узел честно уйдёт в ребут.

⚠️ И python3 -m http.server, и dnsmasq в этой схеме — не systemd-юниты. После ребута admin-узла их нужно поднимать вручную теми же командами. Это самая частая причина «вчера работало, сегодня нет».

4. Загрузчик и меню AMUR

Загрузчик (amur.efi) собирается заранее, конфиг GRUB вшивается в образ на этапе сборки (grub-mkimage -c). Поэтому стоковый EFI-grub меню не покажет — это ожидаемо, DHCP при этом работает штатно. Модули GRUB при этом тянутся по HTTP: каталог grub/x86_64-efi/ на раздаче должен быть непустым (порядка двух сотен .mod и нескольких .lst), иначе на экране будет error: file not found.

После загрузки появляется меню live-среды:

1) Start AMUR S3 installation (ActiveScale iso_installer)
2) Check Hardware
3) Drop to shell

Пункт 1 ведёт в установщик ОС, пункт 2 — проверка железа без установки, пункт 3 — шелл (через него удобно снимать ip -br link и MAC до установки). Вход в live — по учётной записи sysadmin.

5. UEFI против Legacy: где переключается и что ломается

Есть два разных места, и путать их нельзя.

До загрузки (BIOS/BMC). На стоковом BIOS Redfish BootOverride=Pxe может не сработать: BMC рапортует «Force PXE», а машина грузится с диска (видно по BootCurrent). Лечение — вручную через KVM включить Network Stack/PXE и поставить сетевой порт первым в BootOrder. Делается на каждом новом узле; на узле, который уже однажды грузился в live, галки сохраняются.

После stage-1. Установщик делает жёсткий ребут. Дисковая ОС ставит UEFI-grub, поэтому BMC к этому моменту должен смотреть на диск в режиме UEFI:

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 обязателен. Если его не задать, OpenBMC подставляет Legacy, и UEFI-grub с диска не загрузится: узел «молчит» и не появляется в сети. Это же и ответ на вопрос «почему после установки нода не пингуется».

6. Сеть: mgmt-адрес должен появиться раньше storage

На узле два рабочих порта: management (публичная сеть) и storage (приватная). Если storage-порт поднимается первым и DHCP отвечает в приватной сети, PXE и загрузка уходят не туда. Правило: сначала mgmt-адрес, потом storage; привязка адресов — по MAC, а не по именам интерфейсов.

Снимать факты надо с каждой машины отдельно: в одной и той же модели имена различаются (enp3s0 на первой, enp3s0f0 на остальных). Копировать строку из machine.json соседнего узла нельзя.

ip -br link | sort                  # имена и состояние
cat /sys/class/net/<if>/address     # MAC конкретного порта

7. Что проверить на первом узле (до серии)

1. curl -sI http://<ADMIN_NODE>:8080/<IMAGE>.iso → 200 и размер образа.
2. curl -s http://<ADMIN_NODE>/pxe/ | head -c 200 → реальный файл, не LOCALBOOT.
3. tftp <ADMIN_NODE> -c get grub-net-efi64-marvin /tmp/x && ls -l /tmp/x → файл ненулевого размера, совпадающий по размеру с эталоном сборки.
4. curl -sk -u <BMC_USER>:<BMC_PASS> https://<BMC_IP>/redfish/v1/Systems/system/ | jq '.Boot' → BootSourceOverrideTarget: Pxe, BootSourceOverrideMode: UEFI.
5. bootmode=PXE в machine.json и в модели. При bootmode=DISK установщик вообще не заходит в ветку osinstall и молча пропускает установку ОС.

Только после этого запускать серию. Проверять PXE на первом узле дешевле, чем разбирать «полустановленный» кластер.

8. Типовые отказы и что они означают

9. Источники

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