efi pxe 0 for ipv4 boot failed: kompleksowy poradnik naprawy błędów sieciowego rozruchu

W świecie serwerów, stacji roboczych i urządzeń sieciowych błędy podczas uruchamiania z sieci (PXE) są jednym z najczęstszych problemów przy automatyzacji rozruchu maszyn. Komunikat „efi pxe 0 for ipv4 boot failed” to jeden z kluczowych sygnałów, które mogą wskazywać na różne usterki – od konfiguracji DHCP po pliki rozruchowe EFI. W niniejszym artykule przybliżymy, co oznacza ten błąd, jak PXE działa w kontekście EFI i IPv4, jakie są najczęstsze przyczyny problemów oraz jak skutecznie je diagnozować i naprawiać na różnych środowiskach – od prostych konfiguracji domowych po skomplikowane środowiska korporacyjne z Windows Deployment Services i Linuxowymi serwerami TFTP.

Co oznacza efi pxe 0 for ipv4 boot failed

„efi pxe 0 for ipv4 boot failed” to komunikat, który pojawia się najczęściej podczas próby uruchomienia maszyny z sieci (PXE) w środowisku z wykorzystaniem EFI (Extensible Firmware Interface) i protokołu IPv4. Krótko mówiąc, komputer próbuje pobrać obraz rozruchowy z serwera DHCP/TFTP i uruchomić system, ale na pewnym etapie procesu napotyka na problem, który kończy się niepowodzeniem rozruchu sieciowego. W praktyce może to oznaczać problemy z:

– konfiguracją DHCP (jak adres serwera TFTP i nazwa pliku rozruchowego),
– dostępnością lub spójnością plików rozruchowych EFI na serwerze TFTP,
– zgodnością Secure Boot z używanymi plikami,
– siecią (VLAN, firewall, odrzucanie ruchu TFTP),
– wersjami firmware i sposobem obsługi PXE w środowisku UEFI.

Ważne jest zrozumienie, że w środowisku EFI PXE nie zawsze korzysta się z tego samego pliku rozruchowego co w starych BIOS-owych konfiguracjach. EFI PXE wymaga plików rozruchowych specyficznych dla architektury UEFI (x64, a często także ARM64 w niektórych środowiskach), dlatego drobna zmiana w pliku rozruchowym potrafi zakońzyć się błędem „efi pxe 0 for ipv4 boot failed”.

Jak działa PXE w kontekście EFI i IPv4

Aby zrozumieć problem, warto przypomnieć sobie podstawy PXE. Gdy maszyna w BIOS/UEFI uruchamia się w trybie PXE, najpierw wysyła żądanie DHCP w swojej podsieci, aby uzyskać adres IP, maskę podsieci i – co najważniejsze – adres serwera TFTP oraz nazwę pliku rozruchowego. Następnie klient pobiera z serwera TFTP plik rozruchowy (bootloader) i zaczyna wykonywać go. W konfiguracjach z EFI/UEFI plik rozruchowy musi być zgodny z architekturą i środowiskiem rozruchowym – zwykle jest to plik o nazwie bootx64.efi, ipxe.efi lub inny plik EFI przygotowany przez administratora. Jeśli ten plik nie istnieje, nie jest dostępny lub nie jest poprawnie skonfigurowany, pojawi się komunikat o błędzie bootowania z sieci, w tym „efi pxe 0 for ipv4 boot failed”.

Różnice między BIOS a UEFI w kontekście PXE

PXE działa nieco inaczej w środowisku BIOS (stare, legacy) i UEFI (nowszy standard). Kluczowe różnice:

• Ścieżki plików rozruchowych: w BIOS często korzysta się z pliku pxelinux.0 lub undionly.kpxe, podczas gdy w UEFI wymagane są pliki EFI (np. bootx64.efi, ipxe.efi).
• Tryb pracy sieci: UEFI może obsługiwać dwa równoległe stosy sieciowe – standardowy (Legacy) i UEFI Network Stack. W praktyce oznacza to, że w jednym środowisku można mieć jedną maszynę uruchamianą w trybie UEFI, a inną w legacy, co wymusza różne ścieżki rozruchowe na serwerze.
• Bezpieczeństwo: Secure Boot w UEFI często wymaga podpisanych plików rozruchowych. W przypadkach, gdy pliki nie są podpisane lub niezgodne z polityką bezpieczeństwa, rozruch sieciowy może zostać zablokowany.
• Kompatybilność obrazów: W środowiskach WDS/SCCM często należy zapewnić zarówno EFI Boot Image (dla UEFI) jak i BIOS Boot Image (dla Legacy), aby obsłużyć wszystkie maszyny w sieci.

Najczęstsze przyczyny błędu „efi pxe 0 for ipv4 boot failed”

W praktyce najczęściej stoją za tym następujące problemy:

• Nieprawidłowa konfiguracja DHCP: brak adresu serwera TFTP, nieprawidłowy boot file name lub błąd w opcjach 66/67 (dla TFTP) w sieci IPv4.
• Serwer TFTP niedostępny lub blokowany: usługę TFTP nie uruchomiono, porty blokowane przez zaporę sieciową lub błędne katalogi root.
• Nieodpowiedni plik rozruchowy EFI: na serwerze nie ma pliku EFI zgodnego z architekturą klienta (np. bootx64.efi, ipxe.efi), lub plik jest uszkodzony.
• Secure Boot blokuje rozruch: jeśli plik rozruchowy nie jest podpisany lub polityka Secure Boot wymaga dodatkowego podpisu, rozruch sieciowy zostaje odrzucony.
• Błąd sieciowy: VLAN misconfig, problemy z przekazywaniem DHCP między podsieciami, NAT, firewall, problemy z relay agent.
• Brak kompatybilnych obrazów EFI w WDS lub w alternatywnych środowiskach serwerowych.
• Problemy z kompatybilnością sprzętową NIC z PXE: niektóre karty nie obsługują wysokiego trybu PXE lub potrzebują zaktualizowanego firmware.

Diagnostyka i krok po kroku

Poniższy zestaw kroków pomoże zlokalizować i naprawić problem „efi pxe 0 for ipv4 boot failed” w standardowych środowiskach sieciowych.

1. Sprawdź ustawienia firmware maszyny:
   • Upewnij się, że Network Boot (PXE) jest włączony w kolejności bootowania.
   • Wybierz odpowiedni tryb: UEFI lub Legacy (w zależności od środowiska). Jeśli maszyny mają być uruchamiane wyłącznie w UEFI, wyłącz Legacy PXE.
   • Sprawdź, czy w konfiguracji znajduje się wpis dotyczący IPv4 (często domyślny).
2. Zweryfikuj konfigurację DHCP:
   • Adres serwera TFTP musi być prawidłowy i dostępny w tej samej sieci co klient PXE.
   • Opcje DHCP 66 (TFTP Server name) i 67 (Boot file name) muszą wskazywać na istniejący plik rozruchowy zgodny z architekturą klienta.
   • Jeśli używasz rozwiązań z VLAN-owaniem, upewnij się, że DHCP jest przekazywany do właściwej podsieci (DHCP relay/IP helper).
3. Sprawdź serwer TFTP:
   • Upewnij się, że usługę TFTP uruchomiono i nie ma błędów w logach.
   • Sprawdź, czy katalog TFTP-root zawiera właściwy plik rozruchowy EFI (np. bootx64.efi, ipxe.efi) oraz czy uprawnienia umożliwiają odczyt plików przez serwer TFTP.
   • Zweryfikuj, czy serwer TFTP obsługuje transfery w trybie binary (bin) i nie wymaga dodatkowych opcji.
4. Zweryfikuj plik rozruchowy EFI:
   • Upewnij się, że plik rozruchowy EFI istnieje w wyznaczonym miejscu i jest kompatybilny z architekturą klienta (x64 dla większości stacji, rzadziej ARM64).
   • W przypadku środowisk WDS/PSC sprawdź, czy masz odpowiednieEFI Boot Images (dla UEFI) i czy zostały dodane do serwera WDS.
   • Jeżeli używasz iPXE, rozważ użycie ipxe.efi lub bootx64.efi, a także przetestowanie z różnymi plikami rozruchowymi (np. z natywnym iPXE lub z wbudowanym pxelinux w trybie EFI).
5. Sprawdź zgodność z Secure Boot:
   • Jeżeli Secure Boot jest włączony, upewnij się, że pliki rozruchowe EFI są podpisane lub że wyłączono Secure Boot dla środowiska PXE, jeśli to możliwe.
   • W niektórych środowiskach WDS/Hyper-V/VMware dostępna jest możliwość uruchomienia PXE w trybie z wyłączonym Secure Boot lub z dopisanym sygnowaniem obrazów.
6. Testuj sieć i łączność:
   • Sprawdź, czy klient może dotrzeć do serwerów DHCP i TFTP – użyj narzędzi sieciowych lub logów sieciowych na routerze, by potwierdzić ruch DHCP/DNS/TFTP.
   • Zweryfikuj, czy nie ma blokady na połączenia TFTP (UDP port 69) w zaporach sieciowych, w tym na interfejsach między segmetami sieci.
   • Sprawdź, czy nie ma niezgodności VLAN-owych, które utrudniają ruch PXE między klientem a serwerem PXE.
7. Jeżeli environment to umożliwia, przetestuj alternatywną ścieżkę PXE:
   • Spróbuj uruchomić klienta w trybie 802.1Q/PMtu; zweryfikuj ustawienia MTU na urządzeniach sieciowych.
   • W przypadku problemów z BIOS/UEFI, rozważ test z inną kartą sieciową lub zaktualizuj firmware NIC.

Rozwiązania w zależności od środowiska

W praktyce, najczęstsze scenariusze rozchodzą się w kilku kluczowych środowiskach: Windows z WDS, Linux z dnsmasq/tftpd-hpa, oraz ogólne podejście z iPXE. Poniżej znajdziesz schemat działania w zależności od środowiska oraz praktyczne porady, jak uniknąć i naprawić problem „efi pxe 0 for ipv4 boot failed”.

Środowisko Windows: WDS i PXE dla EFI

W środowisku Windows Deployment Services (WDS) obsługa PXE w trybie EFI jest standardem i najczęściej wymaga dodania odpowiednich boot images dla architektury UEFI oraz poprawnej konfiguracji DHCP. Kroki zwykle obejmują:

• Upewnij się, że WDS ma dodane obrazy rozruchowe dla obu trybów: EFI i Legacy. Dla EFI konieczny jest obraz rozruchowy zgodny z architekturą x64 (na przykład „Boot.wim” w zestawie Windows PE, dostępny w Windows ADK).
• Skonfiguruj serwer DHCP tak, by dla klienta PXE wskazywał odpowiedni plik rozruchowy EFI (na przykład bootx64.efi) oraz serwer TFTP. W praktyce często stosuje się bootx64.efi jako domyślny plik rozruchowy dla EFI w WDS.
• Sprawdź ustawienia Secure Boot. WDS może wymagać wyłączenia Secure Boot dla sesji PXE lub użycia podpisanych obrazów i plików rozruchowych. W wielu środowiskach Secure Boot włączony razem z PXE działa bez problemu, jeśli wszystkie pliki są poprawnie podpisane.
• Zweryfikuj, czy plik bootx64.efi oraz ewentualne pliki uprzednio zintegrowane z WDS są dostępne na serwerze TFTP i czy klient ma do nich dostęp w sieci.

Środowisko Linux: dnsmasq, tftpd-hpa i plikowy serwer TFTP

W środowiskach Linux popularne są proste i elastyczne konfiguracje z dnsmasq (lub dnsmasq + tftpd-hpa) jako serwerem DHCP i TFTP. Kluczowe zasady:

• Dnsmasq może służyć jednocześnie jako DHCP i serwer TFTP. Ważne jest, by skonfigurować opcję dhcp-boot na plik rozruchowy EFI (np. bootx64.efi) i zdefiniować lokalizację plików w tftp-root.
• Ustaw właściwy root directory dla TFTP (np. /var/lib/tftpboot) i upewnij się, że uprawnienia pozwalają na odczyt plików przez serwis TFTP.
• Podczas testów używaj plików EFI kompatybilnych z architekturą klienta. Dla przykładu, w konfiguracji sieciowej możesz mieć dwa pliki rozruchowe – jeden dla EFI x64 (bootx64.efi) i jeden dla Legacy (pxelinux.0). W środowisku EFI nie używaj pxelinux.0 bez odpowiedniego chainloadera na EFI.
• Jeżeli planujesz korzystanie z iPXE, możesz umieścić plik ipxe.efi w TFTP i w DHCP wskazywać na ten plik, aby klient mógł pobrać pełny iPXE, a następnie kontynuować rozruch z serwera TFTP lub HTTP.

iPXE i zaawansowane scenariusze PXE

iPXE to elastyczny loader sieciowy, który potrafi łączyć się z serwerami TFTP, HTTP, i HTTPS, oraz umożliwia łączenie wielu łańcuchów rozruchowych. W kontekście błędu efi pxe 0 for ipv4 boot failed iPXE może być użyteczny do:

• Omijania ograniczeń klasycznych PXE poprzez bezpośrednie ładowanie obrazu z serwera HTTP/HTTPS,
• Ładowania zdalnych bootloaderów i obrazów w sposób dynamiczny,
• Testowania, czy problem dotyczy samego TFTP (jeśli iPXE działa, to problem nie leży po stronie sieci lub plików EFI).

W praktyce można użyć iPXE w dwóch formach: jako samodzielny bootloader (uruchamiany z sieci lub za pomocą kart sieciowych wspierających iPXE) lub jako Uniwersalny loader, który chainloaduje do pliku EFI w inny sposób. Dzięki temu łatwiej zdiagnozować problem i ewentualnie ominąć błędy specyficzne dla tradycyjnego PXE.

Jak przygotować plik rozruchowy dla EFI i co wybrać

W kontekście błędu „efi pxe 0 for ipv4 boot failed” często trzeba doprecyzować, jaki plik rozruchowy EFI należy umieścić po stronie serwera TFTP. Oto praktyczne wskazówki:

• Zwykle dla środowisk UEFI 64-bit na maszynach klienta używaj pliku bootx64.efi jako pliku rozruchowego w DHCP/TFTP. Ten plik jest powszechnie dostępny w różnych środowiskach, takich jak Windows PE (WDS), GRUB2 i iPXE.
• Jeżeli w sieci używasz iPXE, możesz wybrać plik ipxe.efi (lub undionly.kpxe w trybie UEFI), a następnie kontynuować rozruch z serwera HTTP/HTTPS/TFTP zgodnie z konfiguracją.
• W przypadku środowisk WDS/Windows ADK, pamiętaj, że EFI boot może wymagać dodatkowych plików, takich jak bootmgfw.efi, w zależności od wersji i konfiguracji WDS. Dowiedz się, które pliki są obsługiwane w twoim wydaniu WDS i jakie obrazy boot są dostępne dla EFI.
• Upewnij się, że pliki nie są uszkodzone. Porównaj rozmiary plików, zweryfikuj sumy kontrolne i potwierdź, że pliki mają odpowiednie atrybuty wykonywalne.
• W testach warto uruchomić maszynę z innym serwerem TFTP lub z innym plikiem rozruchowym EFI, aby wykluczyć problem samego pliku.

Bezpieczeństwo: Secure Boot i PXE

Secure Boot to mechanizm, który ma na celu zapobieganie uruchamianiu nieautoryzowanego kodu. W kontekście PXE i EFI może to stać się źródłem problemów, jeśli pliki rozruchowe nie są podpisane zgodnie z polityką bezpieczeństwa. Kilka praktycznych wskazówek:

• Jeżeli to możliwe, tymczasowo wyłącz Secure Boot w firmware maszyny podczas konfiguracji PXE i testów rozruchu sieciowego. Po zatwierdzeniu konfiguracji można ponownie włączyć zabezpieczenia.
• Jeżeli planujesz uruchamiać środowisko PXE w produkcji z Secure Boot, używaj podpisanych plików rozruchowych EFI i upewnij się, że pliki są dostarczane przez zaufane źródła lub podpisane przez administratora.
• W przypadku środowisk WDS z Windows, sprawdź, czy masz włączone opcje podpisania obrazu i czy masz odpowiedniki podpisanych boot images dla EFI.

Przykładowe scenariusze naprawy błędów na poziomie konfiguracji sieciowej

Poniżej znajdziesz zestaw praktycznych scenariuszy, które często kończą problemy z błędem „efi pxe 0 for ipv4 boot failed”.

1. Brak boot file name w DHCP: Dodaj w DHCP opcję 67 z poprawnym plikiem rozruchowym (np. bootx64.efi) i upewnij się, że serwer TFTP ma ten plik w odpowiednim katalogu.
2. Serwer TFTP niedostępny: Uruchom ponownie serwer TFTP, sprawdź logi i upewnij się, że firewall nie blokuje portu 69 (TFTP) ani ruchu UDP między klientem a serwerem.
3. Nieodpowiedni plik rozruchowy EFI: Zweryfikuj, czy plik o nazwie w konfiguracji DHCP odpowiada istniejącemu plikowi na serwerze TFTP (np. bootx64.efi vs ipxe.efi).
4. Secure Boot blokuje uruchomienie: Wyłącz Secure Boot lub użyj podpisanych plików rozruchowych EFI zgodnych z polityką bezpieczeństwa.
5. Problemy z siecią/VLAN: Upewnij się, że ruch PXE jest dostępny w odpowiedniej podsieci i że relay agent (IP helper) przekazuje DHCP/BOOTP do serwera PXE.
6. Brak odpowiednich obrazów EFI w WDS: Dodaj lub ponownie zaimportuj odpowiednie obrazy EFI (Boot Image i ewentualne Image for Unknown Computer).

Najważniejsze decyzje zależą od środowiska i zasobów:

• Jeśli masz środowisko Windows z WDS, najskuteczniej jest utrzymywać komplet obrazów EFI i BIOS, a także zintegrować DHCP z WDS, aby DHCP automatycznie podawał odpowiednie pliki w zależności od architektury klienta.
• W środowiskach Linux, prosty i elastyczny DNS/DHCP/TFTP (dnsmasq) często wystarcza do szybkiej diagnozy i naprawy; można także zastosować dedykowane narzędzia testowe, takie jak tftp-hpa, aby potwierdzić, że plik jest dostępny.
• Jeżeli masz sieci z dużą liczbą VLAN-ów i multiple relayów DHCP, rozważ wyraźne przekierowanie DHCP w poszczególnych seg­mentach i testy po stronie klienta, aby upewnić się, że nie występują skąpania ruchu między segmentami.

Najczęściej zadawane pytania i praktyczne porady

Na koniec kilka praktycznych wskazówek, które często pomagają w codziennej administracji:

• Używaj narzędzi do monitorowania sieci – logi DHCP/TFTP w serwerze i na przełącznikach mogą pomóc w identyfikacji, czy klient otrzymuje prawidłowe adresy i pliki.
• Weryfikuj, czy klient i serwer znajdują się w tej samej podsieci lub mają prawidłowy routing między sobą. Błędy w routingu często skutkują brakiem kontaktu z serwerem TFTP, co kończy się błędem „efi pxe 0 for ipv4 boot failed”.
• Spróbuj uruchomić klienta z alternatywnym plikiem rozruchowym EFI (np. ipxe.efi), aby sprawdzić, czy problem leży w konkretnym pliku, czy w całej ścieżce PXE.
• Wyłącz na czas testów wszelkie niestandardowe filtry bezpieczeństwa, które mogłyby blokować ruch DHCP/TFTP; niektóre firewalle blokują ruch na UDP 69 lub inne porty potrzebne do PXE.
• Dokumentuj konfigurację – zapisz, które pliki były wykorzystywane, jaki plik 67 był użyty, jakie były odpowiedzi DHCP. Taka dokumentacja znacznie ułatwia przyszłe diagnozy w przypadku podobnych problemów.

Błąd efi pxe 0 for ipv4 boot failed towarzyszy wielu scenariuszom – od prostych błędów konfiguracyjnych DHCP po problemy z plikami rozruchowymi EFI i bezpiecznym uruchomieniem. Kluczem do skutecznej naprawy jest systematyczna diagnoza: upewnienie się, że sieć przekazuje poprawnie DHCP i TFTP, że plik rozruchowy EFI istnieje i jest kompatybilny z architekturą klienta, oraz że środowisko bezpieczeństwa (Secure Boot) nie blokuje procesu. Dzięki temu można zminimalizować czas przestoju i zapewnić stabilny, automatyczny rozruch maszyn z sieci w każdym środowisku – od małych laboratoriów po duże środowiska produkcyjne.