Зависание iPXE на строке initialising devices почти всегда указывает на проблему на этапе инициализации сетевого адаптера: загрузчик не может корректно определить NIC, получить управление от UNDI-стека или дождаться ответа от оборудования. Экран просто останавливается на этом сообщении, и сетевая загрузка не продолжается ни через минуту, ни через десять.
Проблема встречается как на физических машинах с загрузкой по PXE, так и в виртуальных средах с iPXE, Chainloading и кастомными сборками undionly.kpxe или ipxe.efi. Ниже разберём, откуда берётся зависание, как его диагностировать и какие шаги помогают чаще всего.
Что происходит на этапе initialising devices
Когда iPXE стартует, он выводит строку iPXE initialising devices... и начинает перебирать доступные шины и устройства: PCI-устройства, сетевые контроллеры, драйверы, встроенные в конкретный образ. Если ни один драйвер не может захватить адаптер, либо адаптер «отвечает» слишком медленно или некорректно, процесс подвисает.
На этом этапе ещё не идёт речь о DHCP или загрузке файлов по TFTP/HTTP — зависание происходит раньше. Поэтому чинить нужно не серверную часть, а связку «образ iPXE → сетевой адаптер → прошивка (BIOS/UEFI)».
Отдельный частный случай — chainloading: сначала сетевую карту инициализирует штатный PXE-стек прошивки (UNDI), затем управление передаётся undionly.kpxe. Если UNDI-драйвер конкретной сетевой карты глючный, iPXE зависает именно при повторной инициализации устройства.
Основные причины зависания
Причин несколько, и они различаются по частоте в зависимости от железа. Перечислим типовые источники:
- 🔌 Несовместимый или глючный UNDI-драйвер сетевой карты — классическая причина при chainloading через undionly.kpxe.
- 🧩 Неподходящий образ iPXE: например, ipxe.pxe вместо undionly.kpxe или сборка без нативного драйвера под ваш чип (Realtek, Intel, Broadcom).
- ⚙️ Настройки BIOS/UEFI: включённый Secure Boot, режим UEFI вместо Legacy (или наоборот), отключённый Option ROM сетевой карты.
- 🌐 Проблемы на уровне ссылки: нестабильный линк, несогласование скорости с коммутатором, «медленный» порт, из-за которого адаптер не успевает подняться.
- 💻 Специфика виртуальных машин: тип эмулируемого адаптера (например, e1000 против virtio) не поддерживается выбранным образом iPXE.
Обратите внимание: если одна и та же конфигурация работает на одних машинах и виснет на других — почти наверняка дело в модели сетевого контроллера или версии его прошивки.
Быстрая диагностика: с чего начать
Прежде чем пересобирать образы, выполните несколько простых проверок. Они безопасны и не требуют изменения инфраструктуры.
☑️ Первичная диагностика зависания iPXE
Если на другой машине с тем же образом загрузка проходит — сравните сетевые контроллеры. Разница в чипе сразу сузит поиск до драйвера. Если зависание воспроизводится везде — вероятнее всего, повреждён или не подходит сам образ, либо неверно настроена выдача файла по DHCP (опция 67 / filename).
Полезно также проверить, доходит ли вообще загрузка до iPXE: если на экране видны строки от штатного PXE (например, DHCP... и получение адреса), а затем появляется баннер iPXE — chainloading работает, и проблема именно в инициализации устройств внутри iPXE.
Решение 1: смена образа iPXE
Самый действенный приём — подобрать образ, который корректно работает с вашим адаптером. Возможные варианты:
- 📦 undionly.kpxe — использует UNDI-стек прошивки, подходит для большинства Legacy-загрузок, но уязвим к глючным UNDI-драйверам.
- 📦 ipxe.pxe — содержит нативные драйверы iPXE и «снимает» UNDI перед инициализацией; часто помогает, когда undionly виснет.
- 📦 ipxe.efi / snponly.efi — варианты для UEFI-загрузки; snponly.efi опирается на SNP-интерфейс прошивки и полезен, когда нативный драйвер конфликтует.
Файл выдаётся через DHCP-опцию filename (option 67). Пример условной выдачи разных образов для BIOS и UEFI на ISC DHCP:
if option architecture-type = 00:07 {
filename "ipxe.efi";
} else {
filename "undionly.kpxe";
}
Точный синтаксис зависит от вашего DHCP-сервера (ISC, dnsmasq, Windows DHCP, kea) — сверяйтесь с его документацией. После смены файла перезагрузите клиентскую машину и проверьте, проходит ли этап инициализации.
⚠️ Внимание: при UEFI-загрузке с включённым Secure Boot самосборные образы iPXE без подписи могут не запускаться вовсе. Для теста временно отключите Secure Boot в настройках прошивки, но не оставляйте его выключенным в производственной среде без оценки рисков.
Решение 2: настройки BIOS/UEFI и сетевой карты
Если смена образа не помогла, проверьте прошивку машины. Названия пунктов меню различаются у разных производителей, поэтому ориентируйтесь на документацию к конкретной плате или ноутбуку, но ищите следующие опции:
- 🔧 Network Stack / PXE Boot — должен быть включён для соответствующего режима (Legacy или UEFI).
- 🔧 Secure Boot — для теста отключите; несовместимость подписей часто ломает загрузку EFI-образов.
- 🔧 Fast Boot — иногда пропускает инициализацию Option ROM сетевой карты; отключение помогает.
- 🔧 Обновление BIOS/UEFI — известны случаи, когда зависание UNDI-стека устранялось обновлением прошивки; используйте только официальные обновления производителя.
Отдельно стоит проверить настройки встроенной сетевой карты в её собственной конфигурационной утилите (если она предусмотрена производителем): скорость/дуплекс, Wake-on-LAN, Boot Protocol. Несогласование скорости с портом коммутатора иногда приводит к тому, что адаптер физически не успевает поднять линк к моменту инициализации.
Решение 3: сборка iPXE с отладкой
Когда стандартные образы не дают результата, соберите iPXE из исходников с включённой отладкой — это покажет, на каком именно устройстве или драйвере происходит остановка. Сборка выполняется на Linux-машине:
git clone https://github.com/ipxe/ipxe.git
cd ipxe/src
make bin/undionly.kpxe DEBUG=pci,netdevice,undinet
Параметр DEBUG принимает список модулей, по которым нужен подробный вывод. Актуальный перечень имён объектов смотрите в исходном дереве — он меняется между версиями. Отладочный образ выводит на экран расширенный лог, и по последним строкам обычно видно «виновника» зависания.
Дополнительно можно собрать образ с нативным драйвером под конкретный чип (например, для карт Intel — драйвер intel, для Realtek — realtek), указав его в цели сборки. Формат целей описан в официальной документации iPXE.
⚠️ Внимание: не скачивайте «готовые исправленные» образы iPXE со сторонних сайтов — загрузчик получает полный контроль над машиной до старта ОС. Собирайте образ сами из официального репозитория или используйте сборки из доверенных дистрибутивов.
Почему undionly виснет, а ipxe.pxe работает
Образ undionly.kpxe полагается на UNDI-драйвер, который уже загружен прошивкой сетевой карты. Если этот драйвер содержит ошибки (что встречается у некоторых реализаций), повторный опрос устройства из iPXE приводит к зависанию. Образ ipxe.pxe выгружает UNDI и использует собственные нативные драйверы, поэтому обходит проблему. Обратная ситуация тоже возможна: если нативного драйвера под ваш чип нет, работать будет только undionly/snponly.
Зависание в виртуальных машинах
В гипервизорах причина обычно в типе эмулируемого сетевого адаптера. Например, virtio-net требует соответствующего драйвера в образе, а e1000 эмулирует Intel-контроллер и работает со стандартными сборками. Если iPXE виснет в VM — переключите тип адаптера в настройках виртуальной машины и повторите попытку.
Также проверьте, что виртуальная сеть, к которой подключена машина, действительно выдаёт DHCP и пропускает трафик загрузки. В некоторых средах PXE-трафик намеренно фильтруется, и симптомы могут напоминать зависание инициализации.
Сводная таблица симптомов и действий
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Виснет на всех машинах сразу | Неверный/повреждённый образ, ошибка в DHCP-выдаче | Проверить option 67, подменить образ на заведомо рабочий |
| Виснет только на одной модели ПК | Глючный UNDI-драйвер конкретного NIC | Попробовать ipxe.pxe вместо undionly.kpxe, обновить BIOS |
| Виснет в UEFI, в Legacy работает | Secure Boot или неподходящий EFI-образ | Отключить Secure Boot для теста, использовать snponly.efi |
| Виснет только в виртуальной машине | Тип эмулируемого адаптера | Сменить тип NIC (например, на e1000) |
| Случайные зависания через раз | Медленный линк, согласование скорости | Проверить кабель, порт, настройки скорости/дуплекса |
Часто задаваемые вопросы
Сколько времени iPXE должен находиться на этапе initialising devices?
Обычно это секунды. Если сообщение висит дольше 30–60 секунд без какого-либо прогресса, можно считать процесс зависшим и переходить к диагностике.
Поможет ли обновление iPXE до свежей версии?
Часто да: поддержка новых сетевых чипов и исправления драйверов регулярно добавляются в апстрим. Соберите актуальную версию из официального репозитория и проверьте на проблемной машине.
Может ли быть виноват DHCP-сервер, если зависание на initialising devices?
Маловероятно: на этом этапе iPXE ещё не отправляет DHCP-запросы. DHCP стоит проверять, если зависание происходит позже — при получении адреса или загрузке следующего файла.
Что делать, если ни один образ не помогает?
Соберите отладочную сборку с параметром DEBUG, зафиксируйте последние строки вывода и поищите по ним известные проблемы в трекере и списках рассылки проекта iPXE. Как временный обходной путь можно загружать iPXE с USB-накопителя вместо сетевого chainloading.
Влияет ли VLAN на зависание при инициализации?
Напрямую — нет, но если порт коммутатора в неправильном VLAN или тегированный там, где клиент ожидает нетегированный трафик, сетевой линк и последующие этапы будут вести себя непредсказуемо. Проверку конфигурации порта стоит включить в диагностику.