@ Карта сайта News Автора!

Bog BOS: PXE: протокол, настройка ISC DHCP сервера, pxelinux, сервер установки Linux

Последние изменения:
2025.01.24: sysadmin: rsyslog (статья и пример центрального коллектора переработаны)
2024.11.22: sysadmin: systemd-journald (централизованное хранение)

Последнее изменение файла: 2024.04.02
Скопировано с www.bog.pp.ru: 2025.05.06

Bog BOS: PXE: протокол, настройка ISC DHCP сервера, pxelinux, сервер установки Linux

PXE (Preboot Execution Environment) - стандарт, предложенный Intel и Systemsoft (последняя версия 2.1 от 20 сентября 1999), для обеспечения возможности сетевой загрузки ОС. Является частью набора спецификаций Wired for Management (WfM 2.0). Используется для установки ОС по сети, восстановительных работ или для работы бездисковых компьютеров. Используются протоколы DHCP (с расширениями) и TFTP (с широковещательным расширением MTFTP). Сетевая карта должна иметь активированный PCI Option ROM (OpROM, firmware, прошивка, BootROM), содержащий начальный (first stage) загрузчик, а BIOS должна позволять загружаться по сети. Физически может находиться в составе BIOS на системной плате или выполнена программно (Etherboot (ныне gPXE), iPXE - записываются в OpROM сетевой карты или грузятся с флешки). Задача клиента PXE - загрузить NBP - Network Bootstrap Program (secondary stage), NBP загружает ОС. Примеры NBP - pxelinux, shimx64.efi (grub2), RIS (MS Remote Installation Services), wdsmgfw.efi. Задача сервера - обеспечить клиента данными об NBP. В стандарте PXE 2.1 ничего не говорится про UEFI (в RFC-4578 уже есть), IPv6, архитектуры отличные от IA-32. В стандарте UEFI описывается PXE 3, PXE для IPv6, загрузку по HTTP.

Используется для удалённой начальной установки ОС по сети (например, anaconda и kickstart) или починки сломавшейся (rescue). Раньше использовалась также для работы бездисковых рабочих станций.

Стандарт PXE

Стандарт описывает:

Стандарт предусматривает использование MTFTP (multicast TFTP) для загрузки файлов (не описываю, т.к. не использую).

Для проверки правильности NBP PXE загрузчик может запросить дополнительный файл, содержащий цифровую подпись NBP (сертификаты в формате X.509v3), и использовать API работы с цифровой подписью (BIS - Boot Integrity Services API). Адреса подпрограмм данного API должны содержаться в BIOS, их адреса и параметры задаются в SMBIOS (адрес блока описания подпрограмм: "dmidecode -t 31 -u"; нет этого блока - нет BIS). В частности, имеется подпрограмма, возвращающая список поддерживаемых алгоритмов шифрования и хеширования, а также длин ключей шифрования (обязательны DSA-1024/SHA-1 и RSA-512/MD5). Имеется также подпрограмма, сообщающая о необходимости аутентификации. Подробности не описываю, т.к. не использую и аппаратных возможностей не имею.

В тексте стандарта используется выражение "Proxy DHCP" - это не посредник DHCP (DHCP Relay), это дополнительный к незнающему о PXE серверу DHCP сервер, снабжающий PXE клиента информацией об опциях PXE в дополнение к обычному DHCP обмену. В моём случае не используется.

В тексте стандарта используется выражение "Boot Server" - это DHCP дополнительный сервер, снабжающий клиента PXE информацией о TFTP сервере и имени файла. В моём случае используетсяединый DHCP сервер, т.е. никаких отдельных Proxy и Boot.

Расширение DHCP для PXE

PXE (BIOS и UEFI) специфическим образом использует следующие опции DHCP (RFC-4578):

  1. информация в формате изготовителя оборудования, подопции:
    1. сервер указывает клиенту способ обнаружения загрузочного сервера:
      • установка бита 0 запрещает широковещательный запрос при поиске сервера загрузки (если запретить, то при наличии посредника клиент не может найти сервер загрузки)
      • установка бита 1 запрещает групповой запрос при поиске сервера загрузки
      • установка бита 2 запрещает принимать ответы от серверов, не указанных явно в списке серверов загрузки (опция 43, субопция 8)
      • установка бита 3 одновременно с предоставлением имени NBP в пакете DHCPOFFER требует от клиента загрузки и выполнения NBP безо всякой выдачи меню, поиска сервера загрузки и т.д.
    2. групповой адрес сервера загрузки
    3. список серверов загрузки:
      • тип сервера загрузки (2 байта):
        • 0 - PXE bootstrap (локальная загрузка? UNDI в памяти, базовый код PXE удалённо?)
        • 1 - MS Windows NT
        • 2 - Intel LCM
        • 3 - DOS/UNDI
        • ...
        • 13 - REDHAT_INSTALL
        • 14 - REDHAT_BOOT
        • ...
        • 32768-65534 (0x8000-0xfffe) - пользовательские типы, их мы и используем
        • 65535 (0xffff) - тестовый PXE сервер (?)
      • число IP-адресов (1 байт; для проверки в соответствии с субопцией 6; если 0, то клиент может принимать предложения любого сервера загрузки указанного типа)
      • IP-адреса (по 4 байта каждый)
      • тип ...
    4. меню, выдаваемое оператору для выбора сервера загрузки:
      • тип сервера загрузки (2 байта)
      • длина строки (1 байт)
      • строка
      • тип ...
    5. текст приглашения оператору для выбора из меню (без этой подопции меню выдаётся без вмешательства оператора, автоматического выбора не происходит):
      • число секунд до автоматического выбора первого пункта меню (1 байт, 255 или отсутствие подопции - выдать меню сразу и ждать бесконечно долго, 0 - немедленно выбирать первый пункт меню)
      • строка приглашения
    6. номер доверяемого публичного ключа и тип цифровой подписи (4 байта)
    7. клиент указывает тип сервера загрузки (2 байта) и уровень (2 байта); 0 - первый файл NBT и т.д., 0x8000 - цифровая подпись первого файла и т.д.; по умолчанию - 0 и 0
  2. список требуемых клиенту от сервера параметров должен содержать как минимум subnet(1), router(3), vendor(43), class(60)
  3. тип клиента (client class identifier), PXE клиент посылает с помощью этой опции PXE Client Class Identifier в формате "PXEClient:Arch:архитектура-клиента:UNDI:версия-интерфейса" (например, "PXEClient:Arch:00000:UNDI:002001"), сервер подтверждает готовность обслуживать PXE клиента повторением той же строки или просто "PXEClient":
  4. в качестве идентификатора клиента вместа MAC адреса указывается его UUID (обеспечивается BIOS, хранится в SMBIOS ("dmidecode --string system-uuid"), структура типа 1 ("dmidecode -t 1"); Microsoft называет его GUID); длина 16 байт и 1 байт для указания типа (254), текстовое представление в виде, например, C4F42D50-4FB2-11D9-8D84-000EA68F7252
  5. имя сервера загрузки (можно задавать также в поле sname/next-server)
  6. имя файла NBT (можно задавать также в поле bootfile)
  7. список допустимых системных архитектур клиента (2 байта)
  8. идентификатор сетевого интерфейса: тип (1 - UNDI), старший байт версии, младший байт версии;
  9. UUID клиента; тип 0 - это GUID в 16 байт, MAC адрес дополненный нулями (зачем опции 61 и 97 одновременно?)

Клиент должен запрашивать опции 128-135 (данные для NBP, не для PXE boot ROM). Формат определяется используемым NBP. Ожидает ли shim.efi (grub) увидеть здесь что-то? (pxelinux точно не ожидает),

Расширение DHCP для pxelinux

NBP pxelinux специфическим образом использует следующие опции DHCP (RFC-5071):

  1. pxelinux.magic (F1:00:74:7E подтверждают, что опции 209-11 предназначены для pxlinux)
  2. pxelinux.configfile (каталог и имя файла настроек для pxelinux вместо выбора из стандартных для pxelinux; предполагается использование того же TFTP сервера, который грузил pxelinux)
  3. pxelinux.pathprefix (путь к файлу настроек для pxelinux внутри каталога сервера TFTP
  4. pxelinux.reboottime (в секундах; по умолчанию - 300; при невозможности загрузить файл по TFTP после указанного ожидания pxelinux перезагружает сервер; 0 - не перезагружать сервер, ждать или запрашивать файл вечно)

PXE клиент не запрашивает эти параметры у сервера во время запроса параметров аренды (только 128-135), но сервер можно сконфигурировать для передачи незатребованных параметров (можно даже сконфигурировать имя на лету средствами ISC DHCP) 

site-option-space "pxelinux";
option pxelinux.magic f1:00:74:7e;
if exists dhcp-parameter-request-list {
  option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list,d0,d1,d2,d3);
}
option pxelinux.configfile concat("http://путь/pxelinux.cfg/", binary-to-ascii(16, 8, ":", hardware));
...
PXE клиент передаёт их NBP (в кеше опций DHCP, незапрошенные?)

Разработчики pxelinux обещали заменить этот механизм. Но это вряд ли...

Последовательность действий PXE IPL (BIOS) если DHCP сервер не знает про PXE

Последовательность событий при загрузке PXE IPL (BIOS), если DHCP сервер не знает про PXE:

  1. BIOS после POST определяет потенциальные загрузочные устройства и запускает PXE IPL (Initial Programm Load)
  2. перебор привёл к сетевой загрузке PXE
  3. клиент выдаёт широковещательный запрос DHCPDISCOVER с опциями, указывающими, что клиент поддерживает PXE на порт 67/UDP (UUID, тип клиента ("PXEClient", архитектура, версия UNDI), системная архитектура клиента, версия UNDI)
  4. DHCP сервер выдаёт обычный ответ DHCPOFFER без расширенных опций с указанием клиентского IP адреса или перенаправляет клиента на специализированный Proxy DHCP сервер (в этом случае в качестве IP адреса клиента возвращается 0.0.0.0, а клиент должен обращаться на порт 4011/UDP указанного (где?) прокси сервера с запросом DHCPDISCOVER, дальше см. ниже)
  5. клиент делает широковещательный запрос DHCPREQUEST/DHCPINFORM на порт 67/UDP
  6. DHCP сервер выдаёт обычный ответ DHCPACK с указанием IP адреса TFTP сервера и именем файла NBP
  7. никакого меню для взаимодействия с пользователем
  8. клиент загружает указанную NBP с указанного сервера (TFTP, до 32 КБ); ей передаются ссылки на структуры PXENV+ (устаревшая, до PXE 2.1) и !PXE (новая, 2.1 и новее)
  9. выполнение NBP; так как размер её ограничен, то обычно она используется для выдачи на экран меню для возможности дать пользователю выбор и загрузить "настоящую" ОС или загрузчик следующего уровня

Не использую и другим не советую.

Последовательность действий PXE IPL (BIOS) если DHCP сервер настроен для PXE

Последовательность событий при загрузке PXE IPL (BIOS) при использовании DHCP сервера, понимающего PXE и совмещённого с PXE (?) Proxy DHCP (у меня клиент находится в другом VLAN, используется DHCP посредник, который перехватывает широковещательные запросы и передаёт их сконфигурированному серверу направленно):

  1. BIOS после POST определяет потенциальные загрузочные устройства и запускает PXE IPL (Initial Programm Load)
  2. перебор приводит к сетевой загрузке PXE
  3. клиент выдаёт широковещательный запрос DHCPDISCOVER на порт 67/UDP (4 раза с задержками 4, 8, 16 и 32 секунды) с дополнительными опциями, указывающими, что клиент поддерживает PXE
  4. сервер DHCP отвечает DHCPOFFER (широковещательно, у меня через посредника) в зависимости от типа (клиент PXE д.б. готов получить несколько DHCPOFFER, в т.ч. без PXE информации):
  5. если клиент PXE решил использовать полученный IP адрес и прочие параметры, то он завершает стандартный DHCP обмен REQUEST/ACK с DHCP сервером для резервирования IP адреса, иначе ждёт следующего предложения; клиент PXE выдаёт широковещательный запрос DHCPREQUEST на порт 67/UDP с теми же самыми дополнительными опциями, указывающими, что клиент поддерживает PXE
  6. сервер DHCP отвечает DHCPACK аналогично DHCPOFFER; PXE опции из DHCPACK замещают полученные на предыдущем этапе DHCPOFFER!
  7. если в ответе было меню с ненулевым временем ожидания, то на экран выдаётся текст приглашения нажать F8 для вывода меню, иначе клиент PXE выбирате сервер загрузки DHCP самостоятельно
  8. если пользователь успел нажать F8 до истечения времени ожидания, то на экран выводится меню, дающее пользователю возможность выбрать загрузочный сервер, иначе клиент PXE выбирате сервер загрузки DHCP самостоятельно
  9. клиент PXE (уже имеет настройки IP и PXE) ищет сервер загрузки ( исходя из next-server?): выдаёт расширенный запрос DHCPREQUEST (в зависимости от ответа DHCPOFFER (опция 43:6) в указанном порядке: групповой (адрес задаётся в опции 43, субопции 7 4011/UDP), широковещательный на порт 67, unicast на порт 4011/UDP (в случае отдельного PXE Proxy на том же IP адресе)) с указанием тех же параметров, что в запросе DHCPDISCOVER, дополнительно указывая клиентский IP адрес (ciaddr), выбранный тип загрузочного сервера и уровень (PXE Boot Layer, BIS или не BIS) (опция 43, субопция 71: например, 0x8047 и 0x0000 (локальная загрузка)); 4 попытки с задержками 1, 2, 3 и 4 секунды; у меня временами попадает на DHCP сервер, отличный от выдававшего DHCPOFFER, но это не влияет на результат; у меня не получается направленное соединение (unicast) через DHCP посредника; ломится на 4011/UDP
  10. если сервер загрузки настроен на поддержку указанного типа и архитектуры клиента, то он направленно отвечает расширенным DHCPACK (как в DHCPOFFER) и дополнительно: ciaddr - 0.0.0.0 (?!), имя сервера (next-server, в моём случае, свой IP адрес), имя сервера загрузки (sname, своё имя), имя файла NBP для загрузки по TFTP (filename), тип и уровень сервера, настройки MTFTP, опции для pxelinux?
  11. загрузка NBP в ОП (для архитектуры x86 по адресу 0:7C00h) с помощью TFTP (рекомендуется до 32KB, при большем размере не удастся "убраться за собой" при неудачной загрузке - pxelinux.0 6.0 больше 42КБ :(, зарезервировано места в памяти - 577536 байт, ограничение TFTP - 32MB); 6 попыток с задержками 4 секунды
  12. возможна проверка контрольной суммы (стандарт BIS) с помощью дополнительного файла (credentials) с того же самого сервера (к номеру уровня добавляется 0x8000, клиент посылает ещё один запрос DHCPREQUEST на определение имени загружаемого файла (unicast запрос на тот же сервер загрузки с указанием списка возможных типов аутентификации), загружает его и проверяет подпись с помощью BIS)
  13. выполнение NBP (при удачной проверке или отсутствии оной), например, pxelinux или grub2 (shim); так как размер NBP ограничен, то обычно она используется для выдачи на экран меню для возможности дать пользователю выбор и загрузить "настоящую" ОС или загрузчик следующего уровеня

Если используется отдельный Proxy DHCP сервер на том же компьютере, то он использует порт 4011/UDP, если на другом, то - порт 67/UDP. Клиент понимает необходимость обращения к отдельному Proxy DHCP серверу по наличию в ответе опции 60 ("PXEClient") и отсутствию опции 43 или имени файла NBP.

Последовательность действий PXE EFI_LOAD_FILE_PROTOCOL (UEFI) если DHCP сервер настроен для PXE

Последовательность событий при загрузке PXE EFI_LOAD_FILE_PROTOCOL (UEFI) при использовании DHCP сервера, понимающего PXE и совмещённого с PXE (?) Proxy DHCP (клиент находится в том же VLAN, обходимся без посредника, широковещательно):

  1. менеджер загрузки UEFI добирается до устройства умеющего EFI_LOAD_FILE_PROTOCOL, например, "PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/MAC(a4bf010603c4,1)" или ".../IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)"
  2. клиент должен обеспечивать PXE API для NBP
  3. клиент выдаёт широковещательный запрос DHCPDISCOVER на порт 67/UDP (4 раза с задержками 4, 8, 16 и 32 секунды) с дополнительными опциями, указывающими, что клиент поддерживает PXE
  4. сервер DHCP отвечает DHCPOFFER (широковещательно) в зависимости от типа (клиент PXE д.б. готов получить несколько DHCPOFFER, в т.ч. без PXE информации):
  5. если клиент PXE решил использовать полученный IP адрес и прочие параметры, то он завершает стандартный DHCP обмен REQUEST/ACK с DHCP сервером для резервирования IP адреса, иначе ждёт следующего предложения; клиент PXE выдаёт широковещательный запрос DHCPREQUEST на порт 67/UDP с теми же самыми дополнительными опциями, указывающими, что клиент поддерживает PXE
  6. сервер DHCP отвечает DHCPACK аналогично DHCPOFFER; PXE опции из DHCPACK замещают полученные на предыдущем этапе DHCPOFFER!
  7. если в ответе было меню с ненулевым временем ожидания, то на экран выдаётся текст приглашения нажать F8 для вывода меню, иначе клиент PXE выбирате сервер загрузки DHCP самостоятельно
  8. если пользователь успел нажать F8 до истечения времени ожидания, то на экран выводится меню, дающее пользователю возможность выбрать загрузочный сервер, иначе клиент PXE выбирате сервер загрузки DHCP самостоятельно
  9. клиент PXE (уже имеет настройки IP и PXE) ищет сервер загрузки ( исходя из next-server?): выдаёт расширенный запрос DHCPREQUEST (в зависимости от ответа DHCPOFFER (опция 43:6) в указанном порядке: групповой (адрес задаётся в опции 43, субопции 7 4011/UDP), широковещательный на порт 67, unicast на порт 4011/UDP (в случае отдельного PXE Proxy на том же IP адресе)) с указанием тех же параметров, что в запросе DHCPDISCOVER, дополнительно указывая клиентский IP адрес (ciaddr), выбранный тип загрузочного сервера и уровень (PXE Boot Layer, BIS или не BIS) (опция 43, субопция 71: например, 0x8047 и 0x0000 (локальная загрузка)); 4 попытки с задержками 1, 2, 3 и 4 секунды; у меня временами попадает на DHCP сервер, отличный от выдававшего DHCPOFFER, но это не влияет на результат; ?у меня не получается направленное соединение (unicast) через DHCP посредника; ломится на 4011/UDP
  10. если сервер загрузки настроен на поддержку указанного типа и архитектуры клиента, то он направленно отвечает расширенным DHCPACK (как в DHCPOFFER) и дополнительно: ciaddr - 0.0.0.0 (?!), имя сервера (next-server, в моём случае, свой IP адрес), имя сервера загрузки (sname, своё имя), имя файла NBP для загрузки по TFTP (filename), тип и уровень сервера, настройки MTFTP, опции для pxelinux?
  11. загрузка NBP в ОП с помощью EFI_LOAD_FILE_PROTOCOL и TFTP (ограничение TFTP - 32MB); 6 попыток с задержками 4 секунды
  12. возможна проверка контрольной суммы (стандарт BIS) с помощью дополнительного файла (credentials) с того же самого сервера (к номеру уровня добавляется 0x8000, клиент посылает ещё один запрос DHCPREQUEST на определение имени загружаемого файла (unicast запрос на тот же сервер загрузки с указанием списка возможных типов аутентификации), загружает его и проверяет подпись с помощью BIS)
  13. выполнение NBP (при удачной проверке или отсутствии оной), например shimx64.efi; так как размер NBP ограничен, то обычно она используется для выдачи на экран меню для возможности дать пользователю выбор и загрузить "настоящую" ОС или загрузчик следующего уровеня
  14. в качестве загрузчика "следующего уровня" используется grub2.

Если используется отдельный Proxy DHCP сервер на том же компьютере, то он использует порт 4011/UDP, если на другом, то - порт 67/UDP. Клиент понимает необходимость обращения к отдельному Proxy DHCP серверу по наличию в ответе опции 60 ("PXEClient") и отсутствию опции 43 или имени файла NBP.

Клиент UEFI PXE от Intel при DHCP запросе взводит бит требования широковещательного ответа и этот широковещательный ответ не всегда доходит до него (VLAN со внутренней маршрутизацией, при этом DHCP клиент CentOS 7.4 работает без проблем). Пришлось на время установки отключать DHCP Relay и ставить локальный DHCP сервер. Исправили?

Настройка ISC DHCP сервера для загрузки PXE клиентов (BIOS и UEFI)

Для начала необходимо определить пространство имён PXE: 

allow booting;
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option PXE.discovery-control code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr code 7 = ip-address;
# к сожалению, нельзя определить последовательность записей, придётся инкапсулировать вручную
#option PXE.boot-server-list code 8 = seq {unsigned integer 16, unsigned integer 8, array of ip-address};
option PXE.boot-server-list code 8 = string;
# к сожалению, нельзя определить последовательность записей, придётся инкапсулировать вручную
#option PXE.menu code 9 = seq {unsigned integer 16, unsigned integer 8, text};
option PXE.menu code 9 = string;
option PXE.prompt code 10 = {unsigned integer 8, text};
option PXE.boot-server-type code 71 = {unsigned integer 16, unsigned integer 16};

# не используются
#option space pxelinux;
#option pxelinux.magic code 208 = string;
#option pxelinux.configfile code 209 = text;
#option pxelinux.pathprefix code 210 = text;
#option pxelinux.reboottime code 211 = unsigned integer 32;

# в DHCP 4.3 определено в option pxe-system-type
option pxe-system-type code 93 = unsigned integer 16;
#option architecture-type code 93 = unsigned integer 16;

В начале объявления (сеть, группа и т.д.) сделать условное задание параметров: 

shared-network имя {
# MS Windows BINLSVC не умеет возвращать тип сервера загрузки, 
#    поэтому клиент PXE не воспринимает его как свой
# RIS сервер с включённой защитой не отдаёт TFTP файл, если не отработал BINLSVC
# такие случаи необходимо обслуживать "по-простому"
#  if hardware = 01:xx:xx:xx:xx:xx:xx {
#     next-server адрес-RIS-сервера;
#     filename "RemoteInstall\\OSChooser\\I386\\startrom.com";
#  } elsif ...
# делаем из ISC DHCP сервера два разных BOOT сервера
   if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
      vendor-option-space PXE;
      option vendor-class-identifier "PXEClient:Arch:00000:UNDI:002001";
# предлагаем оператору выбрать BOOT сервер и ждём 10 секунд
      option PXE.prompt 10 "Select Boot Server";
# для сервера типа 0000 приглашение "Local"
# для сервера типа 804c (0x8000+'L') приглашение "LIS (Linux Install Server)"
# для сервера типа 8057 (0x8000+'W') приглашение "RIS (MS Windows Install)"
      option PXE.menu 00:00:05:4c:6f:63:61:6c:80:4c:1a:4c:49:53:20:28:4c:69:6e:75:78:20:49:6e:73:74:61:6c:6c:20:53:65:72:76:65:72:29:80:57:18:52:49:53:20:28:4d:53:20:57:69:6e:64:6f:77:73:20:49:6e:73:74:61:6c:6c:29;
# запретить multicast и чужие серверы загрузки, широковещательные запросы запрещать не надо
      option PXE.discovery-control 6;
# для сервера типа 804c (0x8000+'L') один BOOT сервер x.y.z.v (адрес нашего DHCP сервера)
# для сервера типа 8057 (0x8000+'W') один BOOT сервер x.y.z.v (адрес нашего DHCP сервера)
      option PXE.boot-server-list 80:4c:01:xx:yy:zz:vv:80:57:01:xx:yy:zz:vv;
# ветвление в зависимости от выбора типа BOOT сервера, сделанного оператором
      if substring (option vendor-encapsulated-options, 3, 1) = "W" {
        next-server адрес-RIS-сервера;
        filename "RemoteInstall\\OSChooser\\I386\\startrom.com";
        option PXE.boot-server-type 32855 0;
      } else {
        next-server адрес-TFTP-сервера-с-pxelinux-shim;
        if option architecture-type = 00:07 {
# в rfc4578#section-2.1 перепутаны 7 и 9: 0 - Intel x86PC, 7 - UEFI ByteCode, 9 - UEFI x86-64
# /boot/efi/EFI/centos/shim.efi (он же shimx64.efi, он же /boot/efi/EFI/BOOT/BOOTX64.EFI, настройки в /boot/efi/EFI/centos/BOOT.CSV (BOOTX64.CSV)) из пакета shim-x64 в CentOS 7
# /boot/efi/EFI/centos/grubx64.efi из пакета grub2-efi в CentOS 7
          filename = "uefi/shimx64.15.8.efi";
        } else {
# из system-config-netboot-cmd в CentOS 5 или syslinux-tftpboot в CentOS 6/7
#          filename "linux-install/pxelinux.0";
          filename "linux-install/lpxelinux.604.0";
        }
        option PXE.boot-server-type 32844 0;
      }
  }
}

Дешифровка "загадочной" строки из руководства pxelinux: 

09: меню
0f: размер меню
80:00: нестандартный сервер загрузки
0c:4e:65:74:77:6f:72:6b:20:62:6f:6f:74: # "Network boot"
0a: текст приглашения оператору
07: размер приглашения
00: секунд ожидания (немедленно выбрать первый пункт)
50:72:6f:6d:70:74:  Prompt
06: способ обнаружения загрузочного сервера
01: размер
02: не принимать ответы от серверов не в списке
08: список серверов загрузки
03: размер списка
80:00: нестандартный сервер загрузки
00: число серверов (принимать любой адрес)
47: тип сервера загрузки и уровень
04: размер
80:00: нестандартный сервер загрузки
00:00: уровень 0
ff конец списка

pxelinux (BIOS PXE)

При использовании системных плат с BIOS (не UEFI) под Linux в качестве NBP обычно используется pxelinux (часть проекта syslinux), который загружает образы ядра и initrd и передаёт управление ядру. Вместо ядра Linux может быть загружена любая совместимая с используемым форматом программа (например, memdisk, которая в свою очередь позволяет загрузить DOS).

Развитие sylinux останвилось в 2014 году (2014-10-06 : Syslinux 6.03), версия 6.04 не завершена.

Описываю только необходимый минимум возможностей ОС syslinux для выбора из нескольких вариантов ядра с параметрами и initrd.

Сервер TFTP должен поддерживать tsize. MTFTP не поддерживается. Рекомендуется отключить blksize (-r blksize), т.к. многие клиенты PXE неправильно его используют.

Имя файла (включая относительную часть) не может иметь длину более 127 символов.

При неудаче загрузки компьютер сбрасывается через 5 минут.

Начиная с версии 5.10 pxelinux.0 (lpxelinux.0?) поддерживает HTTP и FTP (опциями DHCP задаётся URL конфигурационного файла). Утилита pxelinux-option позволяет встроить URL прямо в код pxelinux.0 (нет в rpm).

Структура каталога linux-install (как настроено в предыдущей главе) в корне TFTP сервера (можно изменить опцией DHCP pxelinux.pathprefix - 210), является начальным рабочим каталогом относительно которого рассматриваются относительные имена:

Конфигурационный файл является текстовым (UNIX или DOS), пустые строки и строки, начинающиеся с "#" игнорируются, первое слово строки - имя команды (регистронезависим), длина строки не более 512 байт, делится на разделы командами label:

Управляющие клавиши:

Отличия версий syslinux в части работы pxelinux:

Развёртывание инфраструктуры для загрузки установщика Linux с помощью pxelinux (RHEL/CentOS)

Последовательность подготовки обратна последовательности загрузки:

При описанных выше настройках PXE загрузчик 10 секунд ждёт нажатия клавиши F8, затем ждёт 10 секунд выбора сервера загрузки (Linux), затем lpxelinux.0 ищет файл с настройками по IP адресу клиента:

Развёртывание инфраструктуры для загрузки установщика Linux с помощью UEFI GRUB2 (RHEL/CentOS/RockyLinux)

Последовательность подготовки инфраструктуры для загрузки установщика Linux с помощью UEFI и GRUB 2 на x86_64 обратна последовательности загрузки:

При описанных выше настройках PXE загрузчик 10 секунд ждёт нажатия клавиши F8, затем ждёт 10 секунд выбора сервера загрузки (Linux), затем PXE клиент загружает shim, shim загружает GRUB, GRUB ищет уникальный файл с настройками по IP адресу клиента или общий grub.cfg:

Ссылки
@ Карта сайта News Автора!

Bog BOS: PXE: протокол, настройка ISC DHCP сервера, pxelinux, сервер установки Linux

Последние изменения:
2025.01.24: sysadmin: rsyslog (статья и пример центрального коллектора переработаны)
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
Copyright © 1996-2025 Sergey E. Bogomolov; www.bog.pp.ru