PXE netboot у homelab закриває просту проблему: встановлення Linux, rescue-систем і live-утиліт без набору флешок. Якщо в мережі є DHCP, TFTP і HTTP, одна машина може віддавати завантажувач, меню та образи для інших вузлів. Нижче – робоча схема, базове налаштування, перевірка і місця, де це зазвичай сиплеться.
Для домашньої інфраструктури це найкраще працює там, де регулярно перевстановлюються тестові хости, міні-ПК, віртуалізаційні ноди або однотипні клієнтські машини. На двох серверах різниця невелика. На п’яти-шести PXE netboot вже економить час, а головне – прибирає хаос з образами, які роз’їжджаються по флешках.
Практичний сенс тут не в самому PXE, а в тому, що інсталяційні і rescue-образи стають частиною інфраструктури. Їх легше оновлювати, перевіряти і тримати в одному місці. Але є нюанс: найбільше проблем створює не TFTP, а суміш старого BIOS, UEFI, проксі-DHCP і кривих мережевих прошивок.
Що потрібно для PXE netboot у homelab
Для PXE netboot потрібні чотири частини: DHCP для видачі мережевих параметрів, TFTP для початкового завантажувача, HTTP для великих файлів і самі boot-образи. Іноді все це працює на одному хості. Іноді DHCP лишається на маршрутизаторі, а сервер netboot віддає тільки boot-файли.
Мінімальна схема виглядає так:
- DHCP повідомляє клієнту, де шукати boot server
- TFTP віддає початковий завантажувач
- меню або iPXE script спрямовує клієнта на HTTP
- HTTP віддає kernel, initramfs, інсталятор або live-образ
На практиці краще якомога раніше забирати великі файли з TFTP на HTTP. TFTP повільний, погано масштабується і часто ламається на великих initrd. Для одного rescue-образу це ще терпимо. Для кількох дистрибутивів і паралельних стартів – вже ні.
Офіційний сайт PXE-специфікації як такої відсутній у звичному сенсі, але для завантаження через iPXE варто дивитися ipxe.org. Якщо в ролі TFTP/DHCP використовується dnsmasq, офіційна документація доступна на thekelleys.org.uk.
Як налаштувати сервер PXE netboot
PXE netboot найпростіше підняти на Linux-хості з dnsmasq, TFTP-каталогом і звичайним веб-сервером. Це підходить для окремої VLAN, тестової мережі або невеликого сегмента, де сервер контролює DHCP. У продакшн-сегменті з уже наявним DHCP потрібна обережність, інакше клієнти почнуть отримувати неправильні lease.
Нижче базовий варіант для Debian або Ubuntu. Він не намагається покрити всі режими BIOS і UEFI, але дає зрозумілий старт.
- Встановити dnsmasq і веб-сервер.
- Створити TFTP-каталог для boot-файлів.
- Покласти туди завантажувачі для BIOS або UEFI.
- Окремо викласти kernel, initrd і ISO-похідні файли через HTTP.
- Увімкнути PXE boot у firmware клієнта.
sudo apt update sudo apt install dnsmasq nginx syslinux-common pxelinux
Далі створюється каталог для TFTP:
sudo mkdir -p /srv/tftp/pxelinux.cfg sudo cp /usr/lib/PXELINUX/pxelinux.0 /srv/tftp/ sudo cp /usr/lib/syslinux/modules/bios/ldlinux.c32 /srv/tftp/ sudo cp /usr/lib/syslinux/modules/bios/menu.c32 /srv/tftp/
Базовий фрагмент конфігурації dnsmasq може виглядати так:
port=0 interface=eth0 bind-interfaces dhcp-range=192.168.10.100,192.168.10.200,12h enable-tftp tftp-root=/srv/tftp dhcp-boot=pxelinux.0
Найпростіше меню для BIOS:
DEFAULT menu.c32 PROMPT 0 TIMEOUT 50 ONTIMEOUT local MENU TITLE PXE netboot LABEL local MENU LABEL Boot from local disk LOCALBOOT 0 LABEL debian-installer MENU LABEL Debian Installer KERNEL http://192.168.10.10/boot/debian/linux INITRD http://192.168.10.10/boot/debian/initrd.gz APPEND ip=dhcp
Після цього dnsmasq і nginx перезапускаються:
sudo systemctl restart dnsmasq sudo systemctl restart nginx
Якщо потрібен UEFI, схема змінюється. Замість старого pxelinux для багатьох машин краще використовувати iPXE або UEFI-сумісний завантажувач. Саме тут більшість домашніх конфігів упирається в першу стіну: BIOS-варіант піднімається за вечір, а UEFI вимагає перевірки архітектури клієнта, правильного boot file і, іноді, окремих правил DHCP.
Чому HTTP краще за TFTP для образів
Для PXE netboot TFTP потрібен лише на старті. Великі initrd, live-системи та rescue-утиліти краще віддавати через HTTP. Так менше таймаутів, менше дивних зависань і простіша діагностика. Якщо образ не качається, HTTP дає нормальні логи. TFTP зазвичай дає лише відчуття, що все ніби запустилося, але щось знову стало.
На маленькому homelab це відчувається одразу. Один інсталятор Linux через TFTP ще працює. Два паралельні запускі вже показують затримки. Якщо в меню додаються live-утиліти, memtest-подібні образи, rescue-середовища і кілька дистрибутивів, TFTP перетворюється на вузьке місце. Тому нормальна схема така: мінімальний bootloader через TFTP, усе інше через HTTP.
Ще одна практична деталь: коли образи лежать на HTTP, їх простіше проксувати, кешувати і розкладати по каталогах без танців навколо TFTP-обмежень. Це дрібниця до першої великої добірки ISO, а далі вже економія часу на кожній зміні меню.
Як додати Linux-інсталятор і rescue-образи
У PXE netboot немає сенсу тягнути цілі ISO, якщо дистрибутив already має окремі kernel і initrd для мережевого запуску. Для інсталяторів це зазвичай штатний шлях. Для rescue-систем і live-образів доводиться дивитися, чи підтримують вони завантаження через kernel/initrd або через iPXE script.
Типова організація каталогів на HTTP-сервері:
/var/www/html/boot/
├── debian/
│ ├── linux
│ └── initrd.gz
├── ubuntu/
│ ├── linux
│ └── initrd
└── rescue/
├── vmlinuz
└── initramfs
Меню краще будувати не як звалище з десяти пунктів, а за ролями:
- інсталятори Linux
- rescue та recovery
- діагностика мережі або дисків
- завантаження з локального диска
На цьому етапі є нетривіальна межа застосовності. Якщо в меню з’являється багато різнорідних образів, простий PXELINUX-підхід швидко розростається в набір винятків. Для двох-трьох інсталяторів це нормально. Для великого зоопарку практичніше перейти на iPXE scripts або на спеціалізований netboot-інструмент з веб-інтерфейсом, інакше підтримка меню стає дорожчою, ніж вигода від нього.
Як перевірити PXE netboot після налаштування
Після стартового налаштування PXE netboot треба перевіряти по ланцюжку: DHCP, TFTP, потім HTTP. Якщо тестувати все одразу, проблема маскується. Клієнт просто зависає на етапі boot, а реальна причина лишається десь між lease і initrd.
- Переконатися, що клієнт отримує IP-адресу від потрібного DHCP-сервера.
- Подивитися журнали dnsmasq під час старту клієнта.
- Перевірити доступність boot-файлів локально і з іншого хоста.
- Перевірити HTTP-URL для kernel та initrd звичайним запитом.
- Окремо протестувати BIOS і UEFI-клієнти, якщо в мережі є обидва типи.
journalctl -u dnsmasq -f ls -lah /srv/tftp curl -I http://192.168.10.10/boot/debian/linux curl -I http://192.168.10.10/boot/debian/initrd.gz
Якщо DHCP уже працює на маршрутизаторі або firewall, не варто одразу піднімати другий DHCP у тій самій мережі. Для перевірки безпечніше винести PXE netboot в окремий сегмент або тимчасову VLAN. Подвійний DHCP у домашній мережі ламає все набагато швидше, ніж будь-яка помилка в TFTP.
Де PXE netboot зазвичай ламається
Найчастіше PXE netboot падає не на сервері, а на стику прошивки клієнта і мережі. UEFI-клієнт може чекати один boot file, BIOS – інший. Частина NIC нормально бере DHCP, але не вміє завантажити великий initrd через TFTP. Іноді проблема взагалі в spanning tree на комутаторі, коли порт піднімається повільніше, ніж стартує PXE ROM.
UEFI і BIOS в одній мережі
Змішана мережа – типовий біль. Старі машини хочуть pxelinux.0, нові – UEFI-сумісний EFI-завантажувач або iPXE. Один універсальний файл тут не рятує. Якщо інфраструктура строката, потрібні окремі правила DHCP за архітектурою клієнта.
TFTP timeout і обриви завантаження
Якщо bootloader стартує, але далі клієнт зависає, підозра падає на TFTP або на занадто великий initrd. Лікується просто: мінімізувати роль TFTP і переносити все важке на HTTP. Це не теоретична порада, а найкоротший шлях до стабільності.
DHCP уже існує на маршрутизаторі
У такій схемі не можна бездумно вмикати dnsmasq як повний DHCP-сервер. Потрібен або окремий сегмент, або proxyDHCP-сценарій. Інакше частина клієнтів отримає lease від маршрутизатора, частина – від netboot-хоста, і діагностика перетвориться на лотерею.
Secure Boot
Secure Boot часто блокує прості саморобні схеми. Якщо в мережі багато сучасних міні-ПК, це треба перевіряти одразу. Формально підтримка може бути, але реальна сумісність залежить від завантажувача і конкретної реалізації firmware. У homelab це одна з тих деталей, які краще виявити на одному тестовому вузлі, а не під час масового розгортання.
Коли PXE netboot вже не найкращий варіант
PXE netboot добре працює для інсталяторів, rescue і регулярних перевстановлень. Але це не універсальна заміна всім сценаріям розгортання. Якщо потрібна повна автоматизація з профілями машин, post-install логікою і керуванням образом на рівні парку вузлів, одного PXE вже мало.
У невеликому homelab межа настає тоді, коли boot-меню перетворюється на систему керування життєвим циклом машин. Тут варто розділити задачі: PXE лишити для старту, а автоматизацію перенести в preseed, autoinstall, kickstart або інші механізми unattended deployment. Тоді netboot лишається простим і надійним шаром, а бізнес-логіка інсталяції живе окремо.
Ще один симптом – коли одна й та сама проблема повторюється тільки на конкретних моделях NUC, тонких клієнтах або старих серверах. Якщо на сумісність іде більше часу, ніж на саме розгортання, іноді швидше тримати окремий boot USB для проблемного класу машин, а PXE netboot використовувати там, де він справді стабільний.
Що дає PXE netboot у нормальному homelab
PXE netboot має сенс не як лабораторний трюк, а як базовий сервіс інфраструктури. Один сервер з меню, інсталяторами і rescue-набором закриває перевстановлення, діагностику і аварійний старт без фізичного носія. Для кількох машин цього достатньо надовго.
Слабке місце тут не Linux-сервер, а сумісність клієнтів. Тому правильний порядок такий: спершу підняти просту схему BIOS або UEFI, потім перевести образи на HTTP, далі розділити правила для різних архітектур. Якщо на цьому етапі все стабільно, мережеве встановлення Linux перестає бути експериментом і стає звичайною частиною homelab.
Офіційні ресурси для подальшої перевірки деталей: iPXE, dnsmasq, SYSLINUX / PXELINUX.