2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

HTTP Boot замена; PXE

Содержание

HTTP Boot замена PXE

Ранее в блоге был пост про PXE загрузку. Установка Windows по сети. За подробностями можно перейти почитать. Если вкратце. Настроив DHCP сервер можно указать клиенту сетевое расположение установочного образа системы (NBP).

Прогресс не стоит на месте и на место PXE приходит HTTP Boot. Про сравнение двух подходов и пойдет речь.

Первое, что нужно знать про HTTP Boot — он работает только на системах UEFI версии 2.5 и выше. Поэтому если у вас по-прежнему используется BIOS возможно следует обновиться. Тем более что крупнейший производитель чипов Intel собирается прекратить поддержку BIOS после 2020. Напоминание, что переключение с BIOS на UEFI загрузку требует изменения в установленной ОС.

Дальше вспомним про работу PXE.

Загрузка в PXE

Процесс загрузки PXE использует несколько протоколов.

  1. DHCP
    1. Клиент передает опцию PXEClient
    2. Сервер передает опцию сервера загрузки и опцию имени файла загрузки
  2. TFTP
    Клиент скачивает образ Network Bootstrap Program (NBP)
  3. Запуск исполняемого образа
    Передача управления ему. Дальнейшая загрузка использует протоколы, реализованные в самом образе. Так для Windows это SMB протокол.

NBP файл

Следует напомнить, что система UEFI требует определенный файл NBP. Он не совместим с файлом для BIOS.

Например, для загрузки Windows Deployment Sever (WDS) в опции DHCP следует указать следующий файл:

  • Для BIOS системы: wdsnbp.com
  • Для UEFI системы: wdsmgfw.efi

HTTP до внедрения HTTP Boot

Загрузка по HTTP была доступна и раньше с использованием сторонних PXE загрузчиков.

Пример iPXE

Например, можно заменить Windows Deployment Server (WDS), DHCP и веб сервер одной программой. И использовать только Microsoft Deployment Toolkit (MDT).
В таком дизайне используется следующие компоненты:

  1. Tiny PXE Server
    DHCP и HTTP сервер.
  2. iPXE загрузчик
    С поддержкой WIM файлов.
  3. Файлы MDT BootBCD, Bootboot.sdi, SourcesBoot.wim

Процесс в этом случае такой:

  1. Клиент выбирает загрузку UEFI NIC
  2. Запускается UEFI PXE загрузка
    1. Клиент получает свой IP адрес от Tiny PXE Server
    2. Клиент получает IP адрес сервера загрузки от Tiny PXE Server
    3. Клиент получает имя файла NBP от Tiny PXE Server
    4. Клиент загружает NBP файл
    5. Клиент запускает NBP файл
  3. Выводится меню iPXE с выбором вариантов загрузки:
    • Загрузка WIM через HTTP
    • Загрузка WIM через TFTP
  4. Выбирается загрузка через HTTP
  5. Загружаются файлы BCD, boot.sdi, boot.wim
  6. Запускается MDT Task Sequence и ему передается управление

Сравним с HTTP Boot.

HTTP Boot

Что поменялось в сравнении с загрузкой PXE? Поддержка HTTP протокола с самого старта. Самый первый NBP образ в PXE загружается по TFTP протоколу. В HTTP Boot это изменилось. HTTP используется для загрузки после выбора UEFI NIC. Это позволяет загружать многомегабайтные файлы быстрее и проще масштабировать.

Опция эксклюзивная. Т.е. в настройках UEFI можно выбрать либо HTTP Boot, либо PXE. Однако в сети встречаются упоминания, когда DHCP сервер отправляет клиенту опцию vendor-class-identifier «HTTPClient». И тогда клиент понимает, что для загрузки NBP образа надо использовать HTTP Boot.

Какие возможности дает HTTP Boot? Быстрее передача данных. Шифрование передачи данных.

Как и раньше для загрузки по сети требуется DHCP сервер и опционально DNS. В HTTP Boot к ним добавился HTTP сервер (веб сервер). Клиенты подключаются по HTTP к веб серверу и скачивают NBP образ загрузки. В сети встречаются упоминания, что поддерживается загрузка ISO образа.

Загрузка в HTTP Boot

Процесс загрузки HTTP Boot похож на PXE.

  1. DHCP
    1. Клиент передает опцию HTTPClient
    2. Сервер передает опцию HTTPClient и URI загрузки. URL содержит протокол (HTTP/HTTPS), имя сервера и имя файла.
  2. HTTP
    Клиент скачивает образ NBP
  3. Запуск исполняемого образа
    Передача управления ему.

Заключение.

Вероятно, со временем системы полностью перейдут на UEFI. А для загрузки по сети будет использоваться HTTP Boot. Использование стандартных компонентов должно способствовать этому процессу.

Booting или как работает EFI?

Доброго времени суток, читатели!
Сегодня мы начнем погружаться в загрузочные системы или booting systems. В англоязычных статьях слово booting описывает весь процесс загрузки компьютера. Однако для начала мы поговорим об общих понятиях и начнем с UEFI (Unified Extensible Firmware Interface) или просто EFI — UEFI более новое название этой системы.

Также предупрежу, что данная статья составлена по отчету, который был в формате «Вопрос — ответ». Вопросы могут показаться не связанными, но я надеюсь на ваше терпение! Также для торопливых напоминаю о комбинации Cntr+F.

UEFI или BIOS Legacy?

UEFI — это своего рода стандарт для всех современных загрузочных систем. Поэтому он сейчас присутствует во всех новых ноутбуках или материнских платах. И, по-моему, некоторые производители прекратили давать пользователю возможность использовать Legacy BIOS, и при острой необходимости, скорее всего, придется перепрошивать загрузочную систему.

Говоря о плюсах UEFI по сравнению с BIOS:

  • У UEFI нет ограничения на размер в 2,2 ТБ в отличии от BIOS. Это возможно благодаря новому подходу к системе разделов диска. В UEFI используется GPT вместо MBR.
  • Скорость загрузки UEFI быстрее, чем BIOS.

О всех возможностях UEFI вы можете узнать на официальном сайте в спецификациях. Однако, 1000 страниц счастья на английском языке мало кому по силам, поэтому могу посоветовать почитать статьи @CodeRush на хабре.

Что такое PXE Booting?

PXE расшифровывается как Preboot eXecution Environment. Основная цель данной фичи — возможность загрузки и установки системы через сеть. Администраторы в современных компаниях используют данную функцию для дистанционной установки системы сразу на десятки или сотни машин.

PXE Booting дает возможность загрузить систему как в Legacy BIOS, так и EFI режимах. (Legacy BIOS — загрузочная система для старых систем, например Windows XP).

Как работает PXE?

  • Клиент подключается к DHCP-серверу с помощью широковещательного запроса (67 / UDP), также он называется пакетом DHCPDISCOVER для предоставления IP-адреса и маски. DHCP не всегда выдает свободный адрес, зачастую стоит range на выдачу, но с PXE это не очень верно работает. — комментарий специалиста. Далее DHCP сервер помогает клиентскому PXE найти следующий IP-адрес сервера для скачивания NBP* файла по протоколу TFTP.
  • Далее клиент устанавливает NBP пакет, скаченный в RAM (random-access memory или просто — оперативку).
    Тут можно хоть немного некорректно, но сравнить с cloud.init когда ВМ разворачивается в виртуальном окружении. Например, для винды этот файл будет BCD — комментарий специалиста. До процесса установки ресурсы самого жесткого диска не используются.

Загрузка по PXE дает немалую автоматизацию, так, например, с помощью Cobbler и правильно настроенного пакета, что передается (NBP), мы можем получить уже настроенную установленную ось. — комментарий специалиста.

*NBP содержит в себе первичные драйвера для работы с компонентами компьютера и скрипты для успешной загрузки и установки образа уже полноценной системы. Если вы найдёте расшифровку аббревиатуры NBP, пишите в комментариях. Буду признателен… )

Что такое GPT?

GPT (таблица разделов GUID) — стандарт для компоновки таблицы разделов на жестком диске. Это часть интерфейса Extensible Firmware Interface (EFI) или на новый лад — Unified Extensible Firmware Interface (UEFI) .
Фактически, EFI использует формат таблицы разделов GPT, также как BIOS использует MBR (Master Boot Record).

В GPT реализована современная система логической блок-адресации LBA (Logic Block Address) вместо CHS (Cylinder, Head, Sector) в MBR. LBA0 и LBA1 содержат защищенные от редактирования заголовки MBR и GPT. Да-да в GPT есть кусочек MBR. LBA (2-33) включают информацию о всем диске с таблицами разделов и GUID (Global Unic ID или глобальный уникальный идентификатор). Кроме того, GPT содержит информацию о таблице разделов и в начале, и в конце диска.

Что такое LBA или логический блок в GPT?

LBA — логический блок размером 512 байт, который используется для структурирования и распределения информации на диске. На картинке ниже вы можете видеть за что отвечает тот или иной LBA.
LBA 0 — «Защищенный» MBR — это стандартный MBR, однако он находится в начале диска и имеет префикс (0xEE). Он обеспечивает защиту от редактирования или удаления структуры диска для старых систем, которые работают только с MBR, например Windows XP (32 бит). На практике он почти не используется. Вся информация о цепочке загрузок хранится на отдельном EFI разделе.
LBA 1 — Сводная информация о самом GPT диске.
LBA 2-33 — Информация о разделах диска.
Весьма ёмкое объяснение дано на wiki.

Для чего нужны разделы дисков (partitions)?

Разделы диска необходимы для разграничения используемого пространства под программные или системные нужды. В частности создание backup-ов или dual-boot систем. Существуют первичные, логические и расширяемые разделы дисков.

Первичные — основные разделы дисков с системой. Логические работают также как и первичные, однако, Windows может запускаться только с первичного раздела. Для MBR есть ограничение в 4 первичных диска, в то время как для GPT такого ограничения нет. Расширяемые — тип разделов, которые не существуют без первичного и не имеют собственной файловой системы.

Protective MBR на практике

На Linux изучать свой диск гораздо проще, поэтому используем bash для чтения первых 512 байт:

Я сразу помечу важные значения цветом:

На самом деле, на новеньком диске не будет так много информации. Всё перед красной пометкой будет заполнено 00 . В моём случае игры с разделами и проверки влияния «защищённого» MBR на GPT привели к захламлению.

Red:
00 — Boot Indicator. Флаг загрузки. Если равен 00, то раздел не является загрузочным.
00 — Starting Head.
01 — Starting Sector.
00 — Starting Cylinder.
Напомню, что MBR работает с заголовками, секторами и цилиндрами. Поэтому эти три параметра нужны, чтобы указать правильный адрес на LBA. Как видите 00 01 00 = LBA 1
EE — Флаг, показывающий, что описываемый раздел является одним и не должен быть удален.
FE — Ending Head.
FF — Ending Sector.
FF — Ending Cylinder.
Соответственно, конец диска.

Green:
01 00 00 00 — Номер первого LBA
AF 44 F2 1B — Количество LBA
Blue:
55 AA — Номер последнего LBA.

LBA 2 и LBA 3 под микроскопом

LBA 2 и LBA 3 — это следующие два блока по 512 байт.

Мы увидем следующее:

Red:
45 46 49 20 50 41 52 54 — (EFI PART) Используется для определения всех EFI совместимых заголовков
00 00 01 00 — EFI спецификация, которая обозначает версию. В нашем случае Version 1 ➔ ..01..

Green:
5C 00 00 00 — Размер заголовка в байтах. 5C 00 00 00 ➔ 92 bytes
7A 0D D7 79 — CRC32 Checksum (Контрольная сумма)
00 00 00 00 — Зарезервировано

Небольшое отступление. Big и Little означают правило чтения. Big ending — чтение БАЙТОВ слева направо (как мы привыкли). Little ending — справа налево. Отмечу, что именно байты, а не вся строка. В диске могут быть записи и так, и этак. Зависит от производителя. В нашем случае были почти все в Little ending.

Blue: 01 00 00 00 00 00 00 00 — Primary LBA (Первоначальный LBA)

Pink: AF 44 F2 1B 00 00 00 00 — Backup LBA. Номер LBA c бэкапом первоначального. Так что AF 44 F2 1B 00 00 00 00 ➔ 468862127 в Big ending.

Brown:
22 00 00 00 00 00 00 00 — Адрес первого используемого LBA — 22 00 00 00 00 00 00 00 ➔ 34 (big ending).
8E 44 F2 1B 00 00 00 00 — Адрес последнего используемого LBA. — 8E 44 F2 1B 00 00 00 00 ➔ 468862094 (big ending).

Coral: 16 46 11 5A 0C 0D A0 4A AF 58 E6 05 C7 3A 9D 8D — GUID самого диска

DarkOliveGreen: 02 00 00 00 00 00 00 00 — Адрес первого LBA в разделе указанного GUID ➔ 2

DeepSkyBlue:
80 00 00 00 — Количество заголовков разделов. ➔ 128 (big ending) Следует отметить, что это значение по-умолчанию. В некоторых случаях увеличиваемое, но не уменьшаемое.
80 00 00 00 — Размер заголовков в bytes. По-умолчанию ➔ 128 bytes (big ending)

GoldenRod: 46 F9 0F B7 — Чек сумма заголовка раздела CRC32

Black: 00 00 .. — Зарезервировано

28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B — UID типа раздела. В нашем случае EFI System partition. Этот индефикатор одинаков для всех EFI разделов.
0D 99 8E 53 06 C0 A2 4E 83 73 40 A0 88 6B 44 3A — Уникальный GUID EFI раздела.

Читать еще:  Что лучше ДДР2 или ДДР3

SlateBlue:
00 08 00 00 00 00 00 00 — Адрес первого LBA раздела ➔ 2048 (На самом деле число очень большое и логичнее предположить, что это должен быть LBA 4. Но в документации иначе)
FF 07 10 00 00 00 00 00 — Адрес последнего LBA раздела ➔ 1050623

SeaGreen: 00 00 00 00 00 00 00 00 — Attribute Bits. Описывает как используется раздел.

  • 45 00 46 00 49 00 20 …- Название раздела. Длина в 36 символов в формате Unicode.

AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4 — UID типа раздела
1C 0A 23 30 18 44 FD 43 8D 10 F3 8C 73 32 4D 10 — Уникальный GUID раздела

Blue:
00 08 10 00 00 00 00 00 — Адрес первого LBA раздела ➔ 1050624
FF 47 1F 00 00 00 00 00 — Адрес последнего LBA раздела ➔ 2050047

Pink: 00 00 00 00 00 00 00 00 — Attribute Bits. Описывает как используется раздел.

AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4 — UID типа раздела
8C 3E B9 DA 5A 6F DA 47 85 7D 21 3E 19 DC E8 36 —Уникальный GUID раздела

Pink: 00 00 00 00 00 00 00 00 — Attribute Bits. Описывает как используется раздел.

Blue:
00 48 1F 00 00 00 00 00 — Адрес первого LBA раздела ➔ 2050048
FF 3F F2 1B 00 00 00 00 — Адрес последнего LBA раздела ➔ 468860927

С какого байта фактически начинается таблица разделов в GPT?

C 1024 байта (включая) или с 0x400 в hex формате. Пруф:

Заключение

Сегодня мы разобрали основные моменты загрузочных систем (Booting System). Повторим главные пункты:

  • UEFI и BIOS (Legacy)
  • PXE загрузка
  • GPT и MBR

Весь описанный материал можно считать поверхностным, особенно тот, что относится к UEFI. Однако, в следующей статье мы продолжим говорить о цепочке загрузки компьютера с участие EFI boot manager и NVRAM.

Так что дальше будет интересно, оставайся с нами =)

Настройка клиента

В дополнение к настройке, упомянутой здесь, вы также должны установить свои имя хоста, часовой пояс [broken link: invalid section] , локаль [broken link: invalid section] и раскладку клавиатуры, а затем следуйте любым другим соответствующим разделам руководства по установке.

Загрузчик

Эта статья или раздел нуждается в переводе

Несмотря на то, что GRUB плохо документирован, он загружается через PXE.

Создайте префикс grub для целевой установки для обеих архитектур, используя grub-mknetdir .

К счастью для нас, grub-mknetdir создает префиксы для всех компилированных/установленных целей, а сопровождающие grub были достаточно хороши, чтобы предоставить нам обоих в одном пакете, поэтому grub-mknetdir нужно запускать только один раз.

Теперь мы создаем тривиальную конфигурацию GRUB:

GRUB dark-magic будет set root=(tftp,10.0.0.1) автоматически, так что ядро и initramfs будут переданы через TFTP без какой-либо дополнительной настройки, хотя вы можете явно установить его, если у вас есть другие non-tftp menuentries.

Pxelinux

Pxelinux предоставляется пакетом syslinux , для получения допольнительной информации смотрите здесь [broken link: invalid section] .

Дополнительные точки монтирования

Корень NBD

В конце загрузки вы захотите переключить монтирование корневой файловой системы на rw и включить compress=lzo , что значительно улучшит производительность диска по сравнению с NFS.

Состояние каталогов программ

The factual accuracy of this article or section is disputed.

Вы можете смонтировать /var/log , например, как tmpfs, чтобы журналы с нескольких хостов не смешивались непредсказуемо и делали то же самое с /var/spool/cups , поэтому 20 экземпляров cups, использующих один и тот же spool, не сражаются друг с другом и делают 1 498 заданий на печать и едят целую бумагу (или, что еще хуже: тонер-картридж) в одночасье.

Было бы лучше настроить программное обеспечение, которое имеет какое-то состояние/базу данных для использования уникальных каталогов для хранения состояния/баз данных для каждого хоста. Например, если вы хотите запустить puppet, вы можете просто использовать спецификатор %H в файле юнита puppet:

Puppet-агент создает vardir и ssldir, если они не существуют.

Если ни один из этих подходов не подходит, последним разумным вариантом будет создание генератора systemd, который создает узел монтирования, специфичный для текущего хоста (к сожалению, спецификаторы не разрешены в юнитах монтирования).

Network Boot To The Rescue

Having a physical infrastructure spread across continents presents you with non-trivial challenges when it comes to maintenance. It’s not always possible to boot your server from a USB stick or even that ancient spinning optical media technology, and you also want to be sure that you can reinstall or repair servers with as little physical interaction as possible. Here, I’ll cover how Showmax approaches remote maintenance and how it works end-to-end.

The Problem

In contrast to current trends, we tend not to use cloud-based services everywhere. This is especially important when it comes to content delivery. Our content delivery network serves users with a better cache hit ratio at a fraction of the price of third-party content delivery services (cloud services are a synonym for other people’s computers anyway).

We have dozens of physical servers spread across Africa, and, as with every physical server, these machines need to be put into maintenance mode sometimes – be it a recovery or reinstallation. In the past, we entered maintenance mode via booting from USB flash drives. But these drives proved to be hard to maintain and often required physical human interaction.

Based on the experience with flash drives, we chose to implement a network boot infrastructure. In this article, I’ll explain how we configure our infrastructure for network boot via UEFI and IPv6, with a demonstration of this configuration on a server booting from a network.

Network Boot Basics

When your computer powers on, the processor passes execution to a boot program that used to be known as the Basic Input/Output System (BIOS) — a system later replaced by a Unified Extensible Firmware Interface (UEFI). This program (in both BIOS and UEFI worlds) is responsible for hardware initialization, connected equipment detection, boot device selection, and the loading of the operating system. The operating system then performs its boot procedure.

When your server is in a good shape, it usually boots from a local disk drive first. If maintenance is needed, the boot device order is temporarily altered and the boot program proceeds with the loading of the operating system from another device. Depending on your boot program, this device can be another hard drive, a USB stick, a HTTP URL, or a file stored on a Trivial File Transfer Protocol (TFTP) server.

TFTP is a simpler version of the file transfer protocol (FTP). TFTP uses UDP as its transport protocol, does not provide authentication features, and is generally only used on local area networks (LAN).

HTTP URL and TFTP-stored files are both variants of the so-called network boot. While for HTTP boot you only need to operate HTTP for the initial boot phase, it is only supported since UEFI 2.5. In practice, we also need to support older UEFI versions, so our network boot supports both the HTTP and TFTP-based options.

In the UEFI world, IPv4 and IPv6 are the supported network protocols for both HTTP and TFTP-based network boot. In the BIOS world, only TFTP-based network boot via IPv4 (which is also commonly known as a Preboot Execution Environment, PXE) is available.

HTTPS boot exists, but has gained limited support so far. Due to the lack of support for HTTPS boot in the UEFI versions used, we do not use this feature at all.

Typical Network Boot Set-up

Our management network provides a DHCP service, which is a network boot pre-requisite. Right now, we operate both DHCPv4 for IPv4 and DHCPv6 for IPv6, but we would like to switch to IPv6-only management networks eventually.

For HTTP boot, the following data need to be served by a DHCP server to a network-booted node (source):

Tag NameTag # (DHCPv4)Tag # (DHCPv6)Data Field
Boot File‘file’ field in DHCP header, or option 6759Boot File URI String (eg. “http://[2001:db8::1]/boot.efi” or “http://192.0.2.1/boot.iso”)
Class Identifier6016“HTTPClient”

For TFTP boot, the relevant data are as follows:

Tag NameTag # (DHCPv4)Tag # (DHCPv6)Data Field
Boot File‘file’ field in DHCP header, or option 6759Boot File URI String (eg. “tftp://[2001:db8::1]/boot.efi” for IPv6 or “boot.efi” for IPv4)
TFTP Server Name66(not present)“192.0.2.1”

To distinguish between legacy PXE, UEFI TFTP, and UEFI HTTP network boot modes, we analyze the Processor Architecture Type DHCP option:

Tag NameTag # (DHCPv4)Tag # (DHCPv6)
Processor Architecture Type93 (Client System)61 (Client Architecture)
Architecture Type (hexadecimal)Architecture Name
00:06x86 UEFI TFTP
00:07x86-64 UEFI TFTP
00:0fx86 UEFI HTTP
00:10x86-64 UEFI HTTP
(undefined/other)Legacy x86 PXE

In addition to the DHCP service, we also provide the following services to make the boot files available:

  • IPv6 Router Advertisement daemon to configure IPv6 routing
  • HTTP server
  • TFTP server
  • NFS server (if you use NFS to boot your OS)

We use Debian and its tools provided in the isc-dhcp-server , radvd , nginx , tftpd-hpa and nfs-kernel-server packages. To enable IPv6 in tftpd-hpa , we had to set TFTP_ADDRESS=»:69″ in /etc/default/tftpd-hpa .

In our network boot environment, TFTP, HTTP and NFS share the same data root directory, /srv/tftp .

Finally, we also branch the DHCP decision tree based on the user-class DHCP option (tag #15 in both DHCPv4 and DHCPv6). If it is set, and equal to the iPXE string, we send the DHCP client a filename of a chain-loaded network boot script.

DHCP configuration

Our DHCPv4 configuration file ( /etc/dhcp/dhcpd.conf ) typically follows this pattern:

For DHCPv6, the config file ( /etc/dhcp/dhcpd6.conf ) is a bit different as there is no next-server and full URLs are always stored in the bootfile-url DHCP option:

There is a bug in ISC DHCP 4.3 which causes DHCPv6 to crash under certain circumstances. This bug was corrected in ISC DHCP 4.4.1, so if you hit it, you may want to upgrade.

iPXE Steps In

There are some options you may want to consider when network booting. When using UEFI, you can boot the Linux kernel directly (this is not possible with BIOS boot). You can boot Grub, a favorite boot loader, from the network. You can also use PXELINUX. And finally, you can deploy iPXE, which is an open source network boot firmware.

The DHCP configuration files already hint at this, but let’s be clear here: we do not boot the Linux kernel directly from TFTP/HTTP. We use a chain-loading approach instead: The boot program loads iPXE , iPXE loads a config file, allows us to choose what to boot, and then boots it. This allows for better flexibility and parametrization of the boot process. Neither Grub nor SYSLINUX provide comparable flexibility and compatibility.

We compile our own iPXE binaries from sources because the binaries available on the website of the iPXE project do not come with IPv6 enabled.

If the UNDI stack of your network card is broken, configure ipxe.pxe instead of undionly.kpxe in the DHCP config files.

When the iPXE binaries are in place, radvd , tftpd-hpa , nginx , isc-dhcp-server <,6>and nfs-kernel-server are configured and running, we need to prepare the iPXE configuration file. This file is stored in the HTTP root under the name of script.ipxe (as defined in the DHCP config files above).

This script.ipxe config file supports booting in both legacy and UEFI environments, and more. It also:

  • Runs EFI Shell from efishell/efishell.efi
  • Can boot GRML, Gparted and SystemRescueCD
  • Boots our own Debian live build based image by default
  • Is able to start iPXE config menu

netX is a synonym for most recently opened network device. This is the device iPXE uses to retrieve the configuration file.

Note that there is a five second time-out, which kicks in if the operator does not pick an option. In such a case, the default ( showmax ) option boots.

A Side Note About Option ROMs

In these early days of Intel x86, computers had little memory and it was impossible to provide drivers for each network card as part of the BIOS firmware package.

The Option ROM approach allows network card manufacturers to bundle a network boot code within the network card itself. When the computer boot program intends to boot from network, it loads and executes this code, which initializes the network card and provides the UNDI+PXE stacks to boot.

The lines above are still valid today: If a UEFI-based boot program boots from a network using legacy PXE and the Compatibility Support Module (CSM), it loads and executes the network boot code on a network card.

In the case of UEFI boot, the network card Option ROM must contain UEFI-compatible code. Option ROM setting of the card must also be switched to UEFI in the boot program setup utility.

The Option ROM may contain both legacy PXE and UEFI codes at the same time, but that’s not too common. You may need to evaluate your equipment and update the Option ROM contents if needed (these Option ROMs are flash memory modules nowadays, not read-only memory chips).

Thankfully, if you wish to boot from an onboard network card, all of the necessary drivers are usually already present in your UEFI firmware block, and there is no need for Option ROM flashing. You still need to adjust the Option ROM type of the network card to UEFI though.

Option ROM configuration. Note the PCI Devices Option ROM Setting and Onboard LAN Option ROM Type.

Server Configuration

On the server side, there’s not much to configure. Except for the Option ROM setting, you also need to ensure that the Network Stack and the necessary IP protocol versions are all enabled. Note that for legacy PXE boot, only Option ROM setting applies.

Network Stack setting with both IPv4 and IPv6 enabled.

When the server boots, press the Boot menu key and…behold!

Boot menu with two entries (one entry per each IP protocol) per network card.

Some boot programs also offer a direct Boot from network option, which does not present a boot menu, but attempts to boot from a network directly. (In the case of our Supermicro servers, it is the F12 key. Unfortunately, this option initializes the Legacy PXE boot, which is not suitable for us. When using this option, your mileage may vary.)

You can also request UEFI network boot via IPMI. This simple sequence of commands configures a one-time UEFI network boot and then power cycles the machine. Do not forget to supply a username and password for the -U and -P parameters.

If you issue the IPMI commands using ipmitool , UEFI prefers network boot over other boot options. It is, however, up to the UEFI implementation as to which network card and IP protocol is selected for boot. We have, for example, observed that on Supermicro boards only a boot from the first item in the UEFI Network Drive BBS Priorities list in the UEFI setup utility is tried.

Booting

Now that the management network and server are configured, and boot files and configs are in place, we can finally boot the server.

When you select the desired network card in the UEFI boot menu, the UEFI loader kicks in first.

UEFI Network Boot Loader retrieves DHCP info and the first file to boot.

Next, iPXE performs its initialization and retrieves the boot script (IP and MAC addresses were redacted from the picture).

iPXE initializes network cards and loads the boot script.

As soon as the script loads, an iPXE boot menu pops up:

Boot menu as defined in script.ipxe.

And finally, the selected menu item boots:

iPXE loads the kernel and initramdisk and boots the kernel.

Linux kernel is booting.

And that’s it! We have just booted our server from the network. Now, we can perform maintenance tasks, reinstallations, load and performance testing, and whatever else comes up.

At the moment, we do not boot our regular system from the network, but we are considering it as a way of evolving our infrastructure.

Conclusion

When we started preparing the network boot infrastructure, it was not clear if it’s even possible to have a boot menu with different options, per-machine boot configuration files, and UEFI support.

After weeks in production, we can safely say that the existing tools are in such good shape that they allow us to perform fully unattended reboots with remotely configured boot options. The tools also allow us to fully utilize UEFI (a clear winner in the x86 firmware world) and IPv6 (which is the current Internet Protocol and is the future of data center networking).

Say “Goodbye” to flash drives!

to get updates and comment. Published on 02 April 2019 in engineering, ops, cdn, network, uefi Radek Zajic’s Picture

Radek Zajic

Share this post

Interested?

Please check the original version of this article at

Efi pxe network что это

You are to boot terminals by HTTP in these two cases:

  1. Plenty of terminals in one network boot from one server. It causes difficulties for TFTP boot when number of terminals is above 300. HTTP works stable with any amount of terminals.
  2. Terminals boot by VPN via slow channel with packet loss. TFTP is very demanding protocol. HTTP works more stable on such channels.

Even in one network with less than 100 terminals it makes sense to boot by HTTP. HTTP is faster and more stable. TFTP is too trivial protocol, it was designed just to fit BootROM/BIOS. TFTP is highly demanding to network reliability. If packets get lost, large files will be loaded by TFTP very hard. HTTP solves this problem.

Terminal boot by network starts from TFTP anyway. Network card BootROM, burned into network card or motherboard BIOS, is able to boot only by TFTP. Two files are downloaded by TFTP: wtware.http ( bootx64.efi for UEFI) and wtware.http.cfg . All other files will be loaded by HTTP.

DHCP configuration for HTTP boot

In 066 DHCP parameter specify TFTP server IP address as always.

In 067 DHCP parameter specify 5.4.24/wtware.http instead of wtware.pxe . Change 5.4.24 to your current WTware version, that terminal boots with.

For UEFI computers in 067 DHCP parameter specify 5.4.24/http.efi instead of 5.4.24/bootx64.efi . Instead of 5.4.24 specify WTware version, that terminal boot with.

WTware DHCP server autodetermines correct value for Legacy BIOS and UEFI computers. Microsoft DHCP you are to specially configure, so that it could differ Legacy BIOS and UEFI computers, this rather complicated configuration we described in special manual about Microsoft DHCP configuration. If you have just several terminals, it’s easier to create reservations for each MAC.

For Microsoft DHCP make sure that setting ‘Conflict detection attempts’ is set to default value 0:

Start: Legacy BIOS, not UEFI

When terminal starts, BootROM code, burned into network card or BIOS, takes control. This code requests DHCP. Then it connects to server with IP address, specified in 066 DHCP parameter. It downloads by TFTP from this server file 5.4.24/wtware.http and transfers control to this file.

File 5.4.24/wtware.http contains loader iPXE, more complicated, than in your terminal BootROM or BIOS. It loades by TFTP it’s configuration file 5.4.24/wtware.http.cfg . Then it downloads by HTTP WTware files. URLs of these files are specified in wtware.http.cfg .

Start: UEFI

When terminal starts UEFI code, burned into motherboard BIOS, takes control. This code requests DHCP. Then it connects to server with IP address, specified in 066 DHCP parameter. It downloads by TFTP from this server file 5.4.24/http.efi and transfers control to this file.

UEFI is rather new technology. UEFI BIOS can download and run WTware start file 5.4.24/http.efi . This file size is about 4 megabytes including Linux kernel and network cards drivers. There’s no need in additional loader for UEFI BIOS. WTware starts, downloads from TFTP 5.4.24/wtware.http.cfg configuration file and continues to download necessary files by HTTP, using HTTP-server address, port and paths, specified in wtware.http.cfg .

Paths on HTTP server

Default paths should be used when in HTTP-server root there’s wtware link, that refers to WTware file structure: to «C:Program Files (x86)WTwareTFTPDROOT» on Windows or to contents of wtware directory from WTware .zip archive. For example, to boot WTware 5.4.24 version these paths should work:

To create link to Windows-directory from Windows command line (that runs as administrator) execute: Clearer way: install FAR, press Alt-F6.

In WTware packages directory there are many files without extensions. Microsoft IIS may reject sending files with no extensions. You can use «.» (a dot) as extension and create a MIME mapping.

Тонкие клиенты / Thinstation Linux

Следующим шагом научим запускать тонкие клиенты. Образ Thinstation Linux можно скачать готовый в виде сборки, можно взять конструктор для сборки и собрать самостоятельно. Можно качнуть с GitHub. Будь готов, что в последнем случае для подготовки образа потребуется около 3 Гбайт свободного места и времени в районе часа. Подготовка образа из Git хорошо описана в статье на сайте quaded.com. Я взял сборку с сайта nixts.org. В образе, который мы используем, много «ненужных» файлов, потому что там сразу и загрузчик, и дефолтные конфиги. Берем ядро и образ файловой системы (initrd и vmlinuz), которые складываем, например, в /var/lib/tftpboot/images/thinstation/ . Файлы конфигураций ( thinstation.conf.network , thinstation.hosts , thinstation.conf-user ) располагаем в корневом каталоге TFTP-сервера! Thinstation позволяет при загрузке учитывать MAC-адреса, IP-адреса, определять имя и группировать клиентов, в зависимости от параметров регулировать загрузку, например уводить на разные RDP- или VNC-серверы, сессии. Это позволяет, например, наклепать кучу виртуалок с десктопными операционными системами и посадить каждого клиента на отдельную виртуалку. Для каждого клиента можно также отдельно задавать настройки доступа к локальным устройствам: принтерам, флешкам, дискам, приводам и так далее. В общем, каждый ограничен только своей фантазией, благо вариантов использования с описанием настроек в сети навалом.

Booting или как работает EFI?

Доброго времени суток, читатели!
Сегодня мы начнем погружаться в загрузочные системы или booting systems. В англоязычных статьях слово booting описывает весь процесс загрузки компьютера. Однако для начала мы поговорим об общих понятиях и начнем с UEFI (Unified Extensible Firmware Interface) или просто EFI — UEFI более новое название этой системы.

Также предупрежу, что данная статья составлена по отчету, который был в формате «Вопрос — ответ». Вопросы могут показаться не связанными, но я надеюсь на ваше терпение! Также для торопливых напоминаю о комбинации Cntr+F.

UEFI или BIOS Legacy?

UEFI — это своего рода стандарт для всех современных загрузочных систем. Поэтому он сейчас присутствует во всех новых ноутбуках или материнских платах. И, по-моему, некоторые производители прекратили давать пользователю возможность использовать Legacy BIOS, и при острой необходимости, скорее всего, придется перепрошивать загрузочную систему.

Говоря о плюсах UEFI по сравнению с BIOS:

  • У UEFI нет ограничения на размер в 2,2 ТБ в отличии от BIOS. Это возможно благодаря новому подходу к системе разделов диска. В UEFI используется GPT вместо MBR.
  • Скорость загрузки UEFI быстрее, чем BIOS.

О всех возможностях UEFI вы можете узнать на официальном сайте в спецификациях. Однако, 1000 страниц счастья на английском языке мало кому по силам, поэтому могу посоветовать почитать статьи @CodeRush на хабре.

Что такое PXE Booting?

PXE расшифровывается как Preboot eXecution Environment. Основная цель данной фичи — возможность загрузки и установки системы через сеть. Администраторы в современных компаниях используют данную функцию для дистанционной установки системы сразу на десятки или сотни машин.

PXE Booting дает возможность загрузить систему как в Legacy BIOS, так и EFI режимах. (Legacy BIOS — загрузочная система для старых систем, например Windows XP).

Как работает PXE?

  • Клиент подключается к DHCP-серверу с помощью широковещательного запроса (67 / UDP), также он называется пакетом DHCPDISCOVER для предоставления IP-адреса и маски. DHCP не всегда выдает свободный адрес, зачастую стоит range на выдачу, но с PXE это не очень верно работает. — комментарий специалиста. Далее DHCP сервер помогает клиентскому PXE найти следующий IP-адрес сервера для скачивания NBP* файла по протоколу TFTP.
  • Далее клиент устанавливает NBP пакет, скаченный в RAM (random-access memory или просто — оперативку).
    Тут можно хоть немного некорректно, но сравнить с cloud.init когда ВМ разворачивается в виртуальном окружении. Например, для винды этот файл будет BCD — комментарий специалиста. До процесса установки ресурсы самого жесткого диска не используются.

Загрузка по PXE дает немалую автоматизацию, так, например, с помощью Cobbler и правильно настроенного пакета, что передается (NBP), мы можем получить уже настроенную установленную ось. — комментарий специалиста.

*NBP содержит в себе первичные драйвера для работы с компонентами компьютера и скрипты для успешной загрузки и установки образа уже полноценной системы. Если вы найдёте расшифровку аббревиатуры NBP, пишите в комментариях. Буду признателен… )

Что такое GPT?

GPT (таблица разделов GUID) — стандарт для компоновки таблицы разделов на жестком диске. Это часть интерфейса Extensible Firmware Interface (EFI) или на новый лад — Unified Extensible Firmware Interface (UEFI) .
Фактически, EFI использует формат таблицы разделов GPT, также как BIOS использует MBR (Master Boot Record).

В GPT реализована современная система логической блок-адресации LBA (Logic Block Address) вместо CHS (Cylinder, Head, Sector) в MBR. LBA0 и LBA1 содержат защищенные от редактирования заголовки MBR и GPT. Да-да в GPT есть кусочек MBR. LBA (2-33) включают информацию о всем диске с таблицами разделов и GUID (Global Unic ID или глобальный уникальный идентификатор). Кроме того, GPT содержит информацию о таблице разделов и в начале, и в конце диска.

Что такое LBA или логический блок в GPT?

LBA — логический блок размером 512 байт, который используется для структурирования и распределения информации на диске. На картинке ниже вы можете видеть за что отвечает тот или иной LBA.
LBA 0 — «Защищенный» MBR — это стандартный MBR, однако он находится в начале диска и имеет префикс (0xEE). Он обеспечивает защиту от редактирования или удаления структуры диска для старых систем, которые работают только с MBR, например Windows XP (32 бит). На практике он почти не используется. Вся информация о цепочке загрузок хранится на отдельном EFI разделе.
LBA 1 — Сводная информация о самом GPT диске.
LBA 2-33 — Информация о разделах диска.
Весьма ёмкое объяснение дано на wiki.

Для чего нужны разделы дисков (partitions)?

Разделы диска необходимы для разграничения используемого пространства под программные или системные нужды. В частности создание backup-ов или dual-boot систем. Существуют первичные, логические и расширяемые разделы дисков.

Первичные — основные разделы дисков с системой. Логические работают также как и первичные, однако, Windows может запускаться только с первичного раздела. Для MBR есть ограничение в 4 первичных диска, в то время как для GPT такого ограничения нет. Расширяемые — тип разделов, которые не существуют без первичного и не имеют собственной файловой системы.

Protective MBR на практике

На Linux изучать свой диск гораздо проще, поэтому используем bash для чтения первых 512 байт:

Я сразу помечу важные значения цветом:

На самом деле, на новеньком диске не будет так много информации. Всё перед красной пометкой будет заполнено 00 . В моём случае игры с разделами и проверки влияния «защищённого» MBR на GPT привели к захламлению.

Red:
00 — Boot Indicator. Флаг загрузки. Если равен 00, то раздел не является загрузочным.
00 — Starting Head.
01 — Starting Sector.
00 — Starting Cylinder.
Напомню, что MBR работает с заголовками, секторами и цилиндрами. Поэтому эти три параметра нужны, чтобы указать правильный адрес на LBA. Как видите 00 01 00 = LBA 1
EE — Флаг, показывающий, что описываемый раздел является одним и не должен быть удален.
FE — Ending Head.
FF — Ending Sector.
FF — Ending Cylinder.
Соответственно, конец диска.

Green:
01 00 00 00 — Номер первого LBA
AF 44 F2 1B — Количество LBA
Blue:
55 AA — Номер последнего LBA.

LBA 2 и LBA 3 под микроскопом

LBA 2 и LBA 3 — это следующие два блока по 512 байт.

Мы увидем следующее:

Red:
45 46 49 20 50 41 52 54 — (EFI PART) Используется для определения всех EFI совместимых заголовков
00 00 01 00 — EFI спецификация, которая обозначает версию. В нашем случае Version 1 ➔ ..01..

Green:
5C 00 00 00 — Размер заголовка в байтах. 5C 00 00 00 ➔ 92 bytes
7A 0D D7 79 — CRC32 Checksum (Контрольная сумма)
00 00 00 00 — Зарезервировано

Небольшое отступление. Big и Little означают правило чтения. Big ending — чтение БАЙТОВ слева направо (как мы привыкли). Little ending — справа налево. Отмечу, что именно байты, а не вся строка. В диске могут быть записи и так, и этак. Зависит от производителя. В нашем случае были почти все в Little ending.

Blue: 01 00 00 00 00 00 00 00 — Primary LBA (Первоначальный LBA)

Pink: AF 44 F2 1B 00 00 00 00 — Backup LBA. Номер LBA c бэкапом первоначального. Так что AF 44 F2 1B 00 00 00 00 ➔ 468862127 в Big ending.

Brown:
22 00 00 00 00 00 00 00 — Адрес первого используемого LBA — 22 00 00 00 00 00 00 00 ➔ 34 (big ending).
8E 44 F2 1B 00 00 00 00 — Адрес последнего используемого LBA. — 8E 44 F2 1B 00 00 00 00 ➔ 468862094 (big ending).

Coral: 16 46 11 5A 0C 0D A0 4A AF 58 E6 05 C7 3A 9D 8D — GUID самого диска

DarkOliveGreen: 02 00 00 00 00 00 00 00 — Адрес первого LBA в разделе указанного GUID ➔ 2

DeepSkyBlue:
80 00 00 00 — Количество заголовков разделов. ➔ 128 (big ending) Следует отметить, что это значение по-умолчанию. В некоторых случаях увеличиваемое, но не уменьшаемое.
80 00 00 00 — Размер заголовков в bytes. По-умолчанию ➔ 128 bytes (big ending)

GoldenRod: 46 F9 0F B7 — Чек сумма заголовка раздела CRC32

Black: 00 00 .. — Зарезервировано

28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B — UID типа раздела. В нашем случае EFI System partition. Этот индефикатор одинаков для всех EFI разделов.
0D 99 8E 53 06 C0 A2 4E 83 73 40 A0 88 6B 44 3A — Уникальный GUID EFI раздела.

SlateBlue:
00 08 00 00 00 00 00 00 — Адрес первого LBA раздела ➔ 2048 (На самом деле число очень большое и логичнее предположить, что это должен быть LBA 4. Но в документации иначе)
FF 07 10 00 00 00 00 00 — Адрес последнего LBA раздела ➔ 1050623

SeaGreen: 00 00 00 00 00 00 00 00 — Attribute Bits. Описывает как используется раздел.

  • 45 00 46 00 49 00 20 …- Название раздела. Длина в 36 символов в формате Unicode.

AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4 — UID типа раздела
1C 0A 23 30 18 44 FD 43 8D 10 F3 8C 73 32 4D 10 — Уникальный GUID раздела

Blue:
00 08 10 00 00 00 00 00 — Адрес первого LBA раздела ➔ 1050624
FF 47 1F 00 00 00 00 00 — Адрес последнего LBA раздела ➔ 2050047

Pink: 00 00 00 00 00 00 00 00 — Attribute Bits. Описывает как используется раздел.

AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4 — UID типа раздела
8C 3E B9 DA 5A 6F DA 47 85 7D 21 3E 19 DC E8 36 —Уникальный GUID раздела

Pink: 00 00 00 00 00 00 00 00 — Attribute Bits. Описывает как используется раздел.

Blue:
00 48 1F 00 00 00 00 00 — Адрес первого LBA раздела ➔ 2050048
FF 3F F2 1B 00 00 00 00 — Адрес последнего LBA раздела ➔ 468860927

С какого байта фактически начинается таблица разделов в GPT?

C 1024 байта (включая) или с 0x400 в hex формате. Пруф:

Заключение

Сегодня мы разобрали основные моменты загрузочных систем (Booting System). Повторим главные пункты:

  • UEFI и BIOS (Legacy)
  • PXE загрузка
  • GPT и MBR

Весь описанный материал можно считать поверхностным, особенно тот, что относится к UEFI. Однако, в следующей статье мы продолжим говорить о цепочке загрузки компьютера с участие EFI boot manager и NVRAM.

Так что дальше будет интересно, оставайся с нами =)

HTTP Boot замена PXE

Ранее в блоге был пост про PXE загрузку. Установка Windows по сети. За подробностями можно перейти почитать. Если вкратце. Настроив DHCP сервер можно указать клиенту сетевое расположение установочного образа системы (NBP).

Прогресс не стоит на месте и на место PXE приходит HTTP Boot. Про сравнение двух подходов и пойдет речь.

Первое, что нужно знать про HTTP Boot — он работает только на системах UEFI версии 2.5 и выше. Поэтому если у вас по-прежнему используется BIOS возможно следует обновиться. Тем более что крупнейший производитель чипов Intel собирается прекратить поддержку BIOS после 2020. Напоминание, что переключение с BIOS на UEFI загрузку требует изменения в установленной ОС.

Дальше вспомним про работу PXE.

Загрузка в PXE

Процесс загрузки PXE использует несколько протоколов.

  1. DHCP
    1. Клиент передает опцию PXEClient
    2. Сервер передает опцию сервера загрузки и опцию имени файла загрузки
  2. TFTP
    Клиент скачивает образ Network Bootstrap Program (NBP)
  3. Запуск исполняемого образа
    Передача управления ему. Дальнейшая загрузка использует протоколы, реализованные в самом образе. Так для Windows это SMB протокол.

NBP файл

Следует напомнить, что система UEFI требует определенный файл NBP. Он не совместим с файлом для BIOS.

Например, для загрузки Windows Deployment Sever (WDS) в опции DHCP следует указать следующий файл:

  • Для BIOS системы: wdsnbp.com
  • Для UEFI системы: wdsmgfw.efi

HTTP до внедрения HTTP Boot

Загрузка по HTTP была доступна и раньше с использованием сторонних PXE загрузчиков.

Пример iPXE

Например, можно заменить Windows Deployment Server (WDS), DHCP и веб сервер одной программой. И использовать только Microsoft Deployment Toolkit (MDT).
В таком дизайне используется следующие компоненты:

  1. Tiny PXE Server
    DHCP и HTTP сервер.
  2. iPXE загрузчик
    С поддержкой WIM файлов.
  3. Файлы MDT BootBCD, Bootboot.sdi, SourcesBoot.wim

Процесс в этом случае такой:

  1. Клиент выбирает загрузку UEFI NIC
  2. Запускается UEFI PXE загрузка
    1. Клиент получает свой IP адрес от Tiny PXE Server
    2. Клиент получает IP адрес сервера загрузки от Tiny PXE Server
    3. Клиент получает имя файла NBP от Tiny PXE Server
    4. Клиент загружает NBP файл
    5. Клиент запускает NBP файл
  3. Выводится меню iPXE с выбором вариантов загрузки:
    • Загрузка WIM через HTTP
    • Загрузка WIM через TFTP
  4. Выбирается загрузка через HTTP
  5. Загружаются файлы BCD, boot.sdi, boot.wim
  6. Запускается MDT Task Sequence и ему передается управление

Сравним с HTTP Boot.

HTTP Boot

Что поменялось в сравнении с загрузкой PXE? Поддержка HTTP протокола с самого старта. Самый первый NBP образ в PXE загружается по TFTP протоколу. В HTTP Boot это изменилось. HTTP используется для загрузки после выбора UEFI NIC. Это позволяет загружать многомегабайтные файлы быстрее и проще масштабировать.

Опция эксклюзивная. Т.е. в настройках UEFI можно выбрать либо HTTP Boot, либо PXE. Однако в сети встречаются упоминания, когда DHCP сервер отправляет клиенту опцию vendor-class-identifier «HTTPClient». И тогда клиент понимает, что для загрузки NBP образа надо использовать HTTP Boot.

Какие возможности дает HTTP Boot? Быстрее передача данных. Шифрование передачи данных.

Как и раньше для загрузки по сети требуется DHCP сервер и опционально DNS. В HTTP Boot к ним добавился HTTP сервер (веб сервер). Клиенты подключаются по HTTP к веб серверу и скачивают NBP образ загрузки. В сети встречаются упоминания, что поддерживается загрузка ISO образа.

Загрузка в HTTP Boot

Процесс загрузки HTTP Boot похож на PXE.

  1. DHCP
    1. Клиент передает опцию HTTPClient
    2. Сервер передает опцию HTTPClient и URI загрузки. URL содержит протокол (HTTP/HTTPS), имя сервера и имя файла.
  2. HTTP
    Клиент скачивает образ NBP
  3. Запуск исполняемого образа
    Передача управления ему.

Заключение.

Вероятно, со временем системы полностью перейдут на UEFI. А для загрузки по сети будет использоваться HTTP Boot. Использование стандартных компонентов должно способствовать этому процессу.

Загрузка по сети: UEFI PXE

В предыдущих статьях, по теме загрузки по сети, все используемые загрузчики, и загрузка с использованием технологии PXE происходила в Legacy-режиме, то есть в режиме старого BIOS. Я решил дополнить данную тему, рассмотрев загрузку по сети в современном стандарте UEFI.

Содержание

В Чем Отличия

Кардинальных отличий в реализации загрузки с использованием технологии PXE для UEFI BIOS нет. Я даже скажу больше, все необходимые настройки полностью идентичны. Но, обо всем по порядку.

Технология PXE базируется на трех составляющих:

1. TFTP-сервер. Предназначен для загрузки файлов по сети. На данном сервере хранятся все загрузочные файлы, с последующим предоставлением их по требованию, без какой-либо авторизации.

2. DHCP-сервер. Предназначен для автоматической выдачи сетевых настроек в сети без необходимости их прописывания вручную на сетевых машинах обладающих соответствующим DHCP-клиентом. То есть, вы подключаете машину с включенным DHCP-клиентом в сеть в которой присутствует DHCP-сервер, и можно использоваться сетью. Хочу так же заметить, что кроме стандартных настроек сети (IP-адресс, маску подсети, Шлюз, и IP-адрес DNS-сервера), DHCP-сервер участвующий в PXE составляющей, должен передавать информацию о TFTP-сервере, и об имени главного исполняемого загрузочного файла.

3. Загрузочный клиент. Программный код вшитый в прошивку сетевой карты или UEFI BIOS материнской платы. Его задача получить необходимые настройки сети, выполнить соединение с TFTP-сервером, и загрузить с него загрузочный файл и выполнить его

Сервера TFTP и DHCP при этом могут быть запущенны на совершенно разных машинах, единственное требование, чтобы они располагались в одной сети.

Все вышесказанное характерно как для Legacy BIOS, так и для UEFI BIOS. Единственное отличие для UEFI PXE, это указание исполняемого файла в настройках DHCP-сервера предназначенного именно для UEFI BIOS.

Учитывая все вышесказанное, настоятельно рекомендую прочитать про установку и настройку DHCP и TFTP сервера, а так же про установку и настройку загрузчика Windows Boot Manager на TFTP-сервер. Данные статьи полностью актуальны на данный момент времени, и информация из них будет использоваться далее по тексту.

Необходимые Программы

Для осуществления загрузки в UEFI PXE потребуется следующие программы и файлы:

1. Программа Tftp32(64). Компактный инструмент сочетающий в себе TFTP, DHCP, DNS, и Syslog службы.

2. Программа BOOTICE. Невероятно мощный инструмент для создания и работы с загрузочными дисками.

3. Установочный *.ISO образ операционной системы Windows. Скачать его можно на официальном сайте Microsoft, абсолютно бесплатно, и без какой-либо регистрации. Скачивание происходит через программу MediaCreationTool.

4. Один из загрузочных WinPE, мультизагрузочной сборки 2k10.

Настройка TFTP-сервера

Как было сказано ранее, установка и конфигурация программы Tftp32(64) уже была подробно рассмотрена в данной статье, поэтому я ограничусь лишь небольшим демонстрационным скринкастом.

В данном скринкасте отображена настройка TFTP-сервера, с корневой директорией D:TFTP, и настройка DHCP-сервера, но без указания имени исполняемого загрузочного файла.

Имя загрузочного файла будет добавлено в следующем разделе.

Директория D:TFTP на данный момент пуста.

Данная директория является корневой для TFTP-сервера, и будет содержать все необходимые загрузочные файлы.

Установка UEFI-загрузчика

В качестве загрузчика будет выступать Windows Boot Manager (BOOTMGR). Установка данного загрузчика на TFTP-сервер так же рассматривалась ранее. Принцип полностью схож, различаются лишь копируемые файлы.

Первым делом, копируем из установочного *.ISO образа операционной системы Windows, папку efimicrosoftboot в корневую директорию TFTP-сервера D:TFTP.

Следующим, копируем файл efibootbootx64.efi, так же в корневую директорию TFTP-сервера.

И последним, копируем файл bootboot.sdi в директорию boot (D:TFTPboot) корневой директории TFTP-сервера.

Установочным ISO-образом ОС Windows на этом покончено. Переходим к мультизагрзочному диску 2k10.

Создадим в корневой папке TFTP-сервера директорию sources (D:TFTPsources).

Скопируем в созданную директорию файл 2k10WinPEW1064PE.wim, из загрузочного ISO-образа мультизагрузочной сборки 2k10.

Переименуем скопированный файл в boot.wim.

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

Запускаем BOOTICE. Открываем в нем конфигурационный файл скопированного загрузчика D:TFTPbootbcd. И выполняем действия приведенные в скринкасте.

Конфигурация касалась двух параметров, первый отвечал за отображения старомодной полоски загрузки, вместо крутящихся шариков, а второй отключал встроенную проверку загружаемых архивов *.wim.

Осталось только вписать имя исполняемого загрузочного файла в конфигурацию DHCP-сервера. Данным файлом в нашем случае является D:TFTPbootx64.efi.

Загрузчик, и тестовое содержимое на этом установлены.

Загрузка Тестового BOOT.WIM

Тестировать загрузку по сети будем в виртуальной машине VMware Workstation Player.

Тестовая виртуальная машина обязательно должна смотреть в вашу реальную сеть.

Запускаем программу Tftp32(64), если она была закрыта. Далее стартуем виртуальную машину и выбираем загрузку по сети в UEFI-режиме.

Начнет выполняться UEFI PXE клиент.

После получения всех необходимых сетевых настроек, запустится скачивание загрузчика и всех необходимых ему файлов с нашего TFTP-сервера.

После скачивания всех необходимых файлов в оперативную память виртуальной машины, последует их запуск. В моем случае, будет запущена WinPE взятая с мультизагрузочного диска 2k10.

Загрузка в UEFI PXE режиме прошла успешно.

В статье было рассмотрено: Как осуществить загрузку в UEFI PXE режиме? Как настроить программу TFTP32(64) для загрузки в UEFI-режиме? Как установить UEFI-загрзчик на TFTP-сервер?

Как можно заметить, отличий в реализации загрузки по сети между UEFI и Legacy режимом нет. Вся разница лишь в прописываемом исполняемом загрузочном файле, и файлах загрузчика. Что касаемо других загрузчиков, то с ними дела обстоят ровно так же. Все что необходимо, это лишь использовать их UEFI версии.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector