PXE не грузится

Симптом

• Узел уходит в PXE, висит ~минуту и ребутится.
• Или PXE прошёл, но live-меню не появляется.
• Или после установки узел не грузится с диска и не выходит в сеть.

Что проверить первым (read-only)

1. Что отдаёт HTTP-раздача ISO: bash curl -sI http://<ADMIN_NODE>:8080/<IMAGE>.iso Ожидается 200 и размер. Если 404 — путь/имя образа неверны.

2. Что отдаёт /pxe/: bash curl -s http://<ADMIN_NODE>/pxe/ | head -c 200 Ожидается реальный файл (~480 байт), а не LOCALBOOT.

3. BootOrder и режим BMC: bash curl -sk -u <BMC_USER>:<BMC_PASS> https://<BMC_IP>/redfish/v1/Systems/system/ \ | jq '.Boot' Ожидается BootSourceOverrideTarget: Pxe, BootSourceOverrideMode: UEFI.

4. Лог dnsmasq (dnsmasq.log на admin-узле): bash grep -E "DHCPDISCOVER|DHCPOFFER|amur.efi" /srv/tftp/dnsmasq.log | tail -20 Ожидается цепочка от MAC узла: DHCPDISCOVER → DHCPOFFER → отдача amur.efi по TFTP. Тишина именно по MAC узла — запрос не дошёл (VLAN/линк), а не «dnsmasq сломался».

5. Файл загрузчика отдаётся по TFTP: bash curl -s tftp://<ADMIN_NODE>/amur.efi | wc -c Ожидается ненулевой размер. 0 — имя в dhcp-boot/pxe-service не совпадает с раскладкой TFTP-корня.

6. bootmode узла в очереди/модели: ожидается PXE (или BootOrder с сетевым портом первым). Если там HDD, узел в PXE не пойдёт вообще, сколько бы раз его ни ребутали.

7. Линк и подсеть на порту управления: в live ip -br a — mgmt-IP должен стоять на том порту, который физически в management-VLAN. Адрес в storage-подсети = PXE ушёл не туда.

Если узел вообще не видит сеть

Признак: в BMC нет линка, DHCP-запрос не приходит, KVM показывает «No boot device» вместо попытки загрузки по сети. Разбирать по цепочке, каждый шаг — отдельным выводом, не «на глаз».

• Линк. Состояние порта в BMC и на коммутаторе: up/up, согласованная скорость, свет. На двухпортовых картах типична ошибка: management-порт физически воткнут в storage-VLAN.
• VLAN. Порт коммутатора — access в management-VLAN (или trunk с нужным native). В чужой VLAN DHCP-запрос уходит в другой broadcast-домен, и PXE молчит при полностью живом узле.
• Network Stack / PXE в BIOS. На стоковом BIOS Redfish BootOverride=Pxe не включает сетевой стек. Пока в KVM не отмечен Network Stack (и PXE для IPv4), узел даже не пытается грузиться по сети.
• BootOrder. Сетевой порт выше локальных дисков. Иначе после 60 секунд ожидания узел уходит в «No boot device» и ребутится по кругу.
• Статика по MAC. Запись на перепутанный MAC даёт ту же картину, что и отсутствие записи: запрос есть, адреса нет. Сверять MAC с наклейкой на порту, а не с именем интерфейса.

Порядок разбора: линк → VLAN → Network Stack → BootOrder → статика по MAC. Первые два пункта закрывают большинство случаев «узел вообще не видит сеть».

Как отличить PXE-проблему от проблемы BMC

Если BMC не отвечает — PXE-разбор бессмысленен: сначала питание, сеть BMC, учётные данные. Обратное тоже верно: живой BMC при пустом DHCP-логе — это сеть узла, а не BMC.

Что смотреть в KVM, если API не помогает

Redfish может показывать BootSourceOverrideTarget: Pxe, а BIOS это игнорировать — типично для стоковой прошивки. В KVM видно то, что происходит на самом деле:

1. Экран POST — определились ли диски и сетевые порты. Порт без линка в списке PXE не появится.
2. Строка попытки PXE — если её нет, вопрос в BootOrder/Network Stack, а не в DHCP.
3. Получение адреса — от кого узел взял адрес. Чужой DHCP в VLAN видно именно здесь.
4. Момент ребута — узел ребутится примерно через минуту после неудачного PXE: это таймаут сканирования носителей, а не паника ядра.
5. Загрузка после установки — доходит ли до grub с диска. Остановка на «Booting from Hard Disk» без прогресса означает, что Boot переключён в Legacy, а ОС ставилась в UEFI.

Скриншот экрана KVM часто полезнее трёх страниц логов: он показывает, на каком шаге узел встал.

Причина

1. url= без .iso

В casper матчится url=*.iso; любое другое расширение молча игнорируется → NETBOOT пуст → 60 секунд сканирования локальных дисков → паника/ребут. Squashfs напрямую (url=...squashfs) не работает.

2. Legacy vs UEFI

После stage-1 установщик делает жёсткий ребут. Если BMC остался в Legacy, дисковая ОС (UEFI-grub) не загрузится: узел «молчит», не в сети. Нужно заранее переключить Boot на Hdd + UEFI.

3. BootOrder / Network Stack

На стоковом BIOS Redfish BootOverride=Pxe может не работать. Нужно вручную через KVM включить Network Stack/PXE. Проверять на каждом новом узле.

4. Не та VLAN

Если storage-порт поднимается раньше mgmt и DHCP уходит в storage-VLAN, PXE встанет. Проверить, какой порт реально получил mgmt-IP.

Решение (штатное)

1. Исправить url= (оканчивается на .iso) или пересобрать загрузчик.
2. В dnsmasq — оба: dhcp-boot=<loader>,,<ADMIN_NODE> и pxe-service=x86-64_EFI,....
3. В BMC: BootSourceOverrideTarget=Hdd, BootSourceOverrideMode=UEFI, Enabled=Once — перед финальным ENTER установщика.
4. В BIOS (KVM): включить Network Stack/PXE; BootOrder — сетевой порт первым.
5. Перезагрузить узел; проверить, что он пингуется по mgmt-IP через 2–4 минуты.

Проверка

• curl -sI http://<ADMIN_NODE>:8080/<IMAGE>.iso → 200.
• /pxe/ → реальный файл, не LOCALBOOT.
• BMC Boot → Uefi, target Hdd.
• ping <MGMT_IP> → отвечает.
• ssh <USER>@<MGMT_IP> → вход.
• df -h / → корень на диске, не overlay.

Профилактика

• Чек-лист подготовки: BootOrder, url=, /pxe/, bootmode.
• Не запускать установку, пока PXE не проверен на одном узле.
• Хранить рабочий набор dnsmasq/загрузчика в артефактах.

Источники и дата

• X200 Getting Started Guide
• Внутренняя практика (обезличено): прогоны PXE на лабораторных стендах.
• Обновлено: 2026-11-07.