Dies ist eine alte Version des Dokuments!

Inhaltsverzeichnis

iPXE / PXE

iPXE / PXE

Ab Satellitenserver WS18/19 wird alternativ zum alten PXE auch iPXE für das Bootmenü unterstützt. Intern wird bereits seit längerem auf iPXE gesetzt, nun aber auch für das eigentliche Bootmenü. Dies ist der neue empfohlene Standard für bwLehrpool.

Der alte Ansatz hat u.a. den Nachteil, dass lediglich ein einzelnes, globales Menü für alle Rechner und Räume über die Weboberfläche angelegt werden kann. Über händisches Anlegen von PXE-Files konnte das Verhalten zwar bereits angepasst werden (PXE-Menü Spezialfälle), dies ist jedoch eher unflexibel und fehleranfällig.

Bootmenü verwalten

Mit iPXE verändert sich auch die Art und Weise wie Sie Bootmenüs über die Weboberfläche anlegen und verwalten können. Ein Menü setzt sich aus einem oder mehreren Booteinträgen oder einem anderen Bootmenü zusammen. Seien Sie vorsichtig, wenn Sie einen der Standardeinträge verändern. Für Experimente bietet es sich an, den „Kopieren“-Button in der Liste der Menüeinträge zu nutzen, damit der originale Eintrag erhalten bleibt.

Eine Einführung zu Bootmenüs mit iPXE finden Sie unter iPXE Bootmenü.

Vorteile von iPXE

Für bwLehrpool ergeben sich durch iPXE eine ganze Reihe von Vorteilen:

Es können unterschiedliche Booteinträge über die Weboberfläche angelegt und zu Bootmenüs zusammengefasst werden
Bootmenüs lassen sich an bestimmte Räume ausliefern (z.B. dort wo statt bwLehrpool standardmäßig von HDD gebootet werden soll)
Deutlich mehr Konfigurationsmöglichkeiten über die Weboberfläche
Unterstützung für reinen UEFI Boot (falls der Rechner kein Legacy-PXE unterstützt)

Vor allem der letzte Punkt, PXE Boot von UEFI, wird zunehmend kritischer. Die neue bwPC Generation (ESPRIMO Q958 (FUJITSU)) unterstützt kein Legacy-PXE mehr. Um diese Rechner mit bwLehrpool zu verwenden, müssen Sie daher zwingend auf iPXE wechseln.

Unter Umständen gibt es Hardware, die mit iPXE nicht klarkommt. Wir haben im Voraus bereits möglichst viele Modelle auf Kompatibilität getestet. Falls Sie dennoch Probleme mit bestimmten Modellen feststellen, geben Sie uns bitte Bescheid.

Von uns mit iPXE erfolgreich getestete Modelle:

D34010WYK (Intel Corporation)
NUC5i3RYB (Intel Corporation)
NUC5i5RYB (Intel Corporation)
ESPRIMO P420 (FUJITSU)
ESPRIMO P910 (FUJITSU)
ESPRIMO P920 (FUJITSU)
ESPRIMO Q956 (FUJITSU)
ESPRIMO Q957 (FUJITSU)
ESPRIMO Q958 (FUJITSU)
ESPRIMO P958 (FUJITSU)
CELSIUS_W550power (FUJITSU)
HP Compaq dc5750 Microtower (Hewlett-Packard)
HP Compaq 6200 Pro SFF PC (Hewlett-Packard)
HP Compaq Pro 6300 SFF (Hewlett-Packard)
HP Compaq 8000 Elite CMT PC (Hewlett-Packard)
HP Compaq 8200 Elite CMT PC (Hewlett-Packard)
HP Compaq 8200 Elite SFF PC (Hewlett-Packard)
HP Z240 Tower Workstation (HP)
HP Z400 Workstation (Hewlett-Packard)
HP Z440 Workstation (Hewlett-Packard)
OptiPlex 755 (Dell Inc.)
OptiPlex 3010 (Dell Inc.)
OptiPlex 5050 (Dell Inc.)
OptiPlex 9020M (Dell Inc.)
OptiPlex 9020 (Dell Inc.)
10ABA040GE (LENOVO)
10AEA0EWGE (LENOVO)
20BWS1RR00 (LENOVO)
P9X79 WS (ASUSTeK COMPUTER INC.)
ECO 44 G7 (TAROX AG)

Geben Sie uns gerne Bescheid, wenn Sie weitere Modelle mit oder ohne Erfolg getestet haben, damit wir die Liste vervollständigen können.

Nachteile von iPXE

Prinzipiell gibt es nur Vorteile bei der Verwendung von iPXE. Es kann jedoch einzelne Rechnermodelle bzw. BIOS-Implementierungen geben, die mit iPXE nicht klarkommen. In diesem Fall bleibt Ihnen nur die Möglichkeit beim alten PXE Ansatz zu bleiben oder die Rechner auszutauschen. Ein Mischbetrieb von PXE und iPXE ist nicht möglich.

Wechsel zwischen PXE und iPXE

Wie oben bereits erwähnt, werden Sie beim aktualisieren Ihres Satellitenservers per Updateskript gefragt, ob Sie auf iPXE umsteigen möchten oder zunächst bei PXE bleiben möchten. Am besten vergleichen Sie die bei Ihnen genutzten PC-Systemmodelle (siehe Client-Statistiken) mit der oben angegebenen Liste. Wenn alle Rechner unterstützt werden, spricht nichts gegen eine Nutzung von iPXE. Ansonsten empfehlen wir iPXE zunächst auf einem Testsatellitenserver zu aktivieren und zu prüfen, ob Ihre Poolrechner damit zurechtkommen.

Wenn Sie erstmalig iPXE aktivieren, wird versucht Ihr altes Menü sowie weitere händisch angelegte PXE-Regeln, um beispielsweise das Menü für einzelne Räume zu überschreiben, zu importieren.

Sollten Sie später (nach der Aktualisierung des Satellitenservers) nochmal zwischen PXE und iPXE wechseln müssen, sind ein paar händische Anpassungen nötig. Öffnen Sie dazu eine Terminalsitzung zu Ihrem Server (ESX-Konsole oder SSH) und führen Sie folgende Schritte aus:

Bitte sichern Sie vorher etwaige PXE-Regeln, falls irgendetwas schiefgehen sollte.

Wechsel von PXE zu iPXE

cd /srv/openslx/www/slx-admin/modules
ln -sfn ../modules-available/serversetup-bwlp-ipxe serversetup

cd /srv/openslx/www/slx-admin
/srv/openslx/www/slx-admin/install-all

systemctl restart lighttpd.service 

Unter iPXE / Boot Menu -> Server-Adresse -> "Jetzt neu kompilieren"

Wechsel von iPXE zu PXE

cd /srv/openslx/www/slx-admin/modules
ln -sfn ../modules-available/serversetup-bwlp-pxelinux serversetup

cd /srv/openslx/www/slx-admin
/srv/openslx/www/slx-admin/install-all

systemctl restart lighttpd.service 

Unter iPXE / Boot Menu -> "Bootmenü erzeugen"

Der letzte Schritt, das Kompilieren bzw. Erzeugen des Bootmenüs kann relativ lange (mehrere Minuten) dauern. Währenddessen können Clients nicht booten.

UEFI

Bisher unterstützen die meisten Rechner noch einen Legacy-PXE-Boot. Es gibt allerdings bereits erste Systeme, die sich ausschließlich über EFI starten lassen. Wenn solche Modelle mit bwLehrpool zum Einsatz kommen sollen, muss zwingend auf iPXE gewechselt werden. Außerdem sind Anpassungen am DHCP-Server notwendig.

BIOS und UEFI unterscheiden sich grundlegend voneinander. Auch die über den DHCP-Server ausgelieferte PXE-Binary muss daher auf die jeweilige Architektur passen. Der Satellitenserver enthält Binaries für beide Architekturen, jedoch muss das jeweils richtige Bootfile an die Clients ausgeliefert werden.

Für normalen BIOS-PXE Boot muss der DHCP als Bootfile wie bisher ipxelinux.0 ausliefern. Für Clients die über EFI booten lautet das Bootfile ipxe.efi.

In der Regel lässt sich die Architektur über die DHCP Option 60 (Vendor class identifier)¹⁾ bzw. 93 (Client System Architecture)²⁾ erkennen und das Verhalten entsprechend steuern. Vergleichen Sie dazu auch die beiden nebenstehenden Screenshots.

Je nach verwendetem DHCP-Server unterscheidet sich die Konfiguration, weswegen wir hier nur Beispiele bzw. weiterführende Informationen angeben können.

DHCP-Beispielkonfiguration

Sie können die Konfiguration zunächst erst mal ohne Unterscheidung der Client-Architektur fest für einen einzelnen Test-Rechner setzen. Somit können Sie gefahrlos prüfen, ob UEFI-Boot mit bwLehrpool generell funktioniert.

Einzelner Rechner (Bsp.)

host efi-test-client {
    fixed-address 10.9.9.99;
    hardware ethernet 8a:51:45:2b:9a:12;
    next-server 10.9.9.5;
    log (info, "bwLehrpool efi64 client");
    filename "ipxe.efi";
}

Damit nicht jeder Client einzeln eingetragen werden muss, sollten Sie jedoch über den „vendor-class-identifier“ unterscheiden, ob ein Client per BIOS oder UEFI bootet und das entsprechende Bootfile ausliefern. Somit lassen sich leicht ganze Subnetze konfigurieren.

Unterscheidung mittels "vendor-class-identifier" (Bsp.)

subnet 10.9.9.0 netmask 255.255.255.0 {
    range 10.9.9.100 10.9.9.200;
    option routers 10.9.9.254;
    next-server 10.9.9.5;
    filename "ipxelinux.0";
    option domain-name "xyz.meine-domain.de";

    if substring (option vendor-class-identifier, 19, 1) = "0" {
        log (info, "pxe client");
        filename "ipxelinux.0";
    }
    else if substring (option vendor-class-identifier, 19, 1) = "7" {
        log (info, "efi64 client");
        filename "ipxe.efi";
    }
    else {
        log (info, concat ( "Unhandled vendor class Arch: ", substring (option
        vendor-class-identifier , 19,1 )));
    }
}

Unseres Wissens unterstützt Windows Server 2008R2 die Unterscheidung anhand des „vendor-class-identifier“ nicht. Sie haben in diesem Fall daher drei Möglichkeiten:

Wechsel auf einen anderen DHCP (z.B. Windows Server 2012)
Festes Eintragen für einzelne Rechner bzw. IP-Ranges wenn alle Rechner in einer Range gleicher Architektur sind
Nutzen eines ProxyDHCP wie z.B. dnsmasq

Weitere Konfigurationsbeispiele:

isc dhcpd (ganz unten): http://ipxe.org/cfg/platform
Mit Windows Server: https://2pintsoftware.com/whitepaper-using-dhcp-uefi-bios-pxe-booting/
https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

BIOS-Client - DHCP Discover

UEFI-Client - DHCP Discover

DHCP - MAC/UUID

DHCP-Server vergeben IP-Adressen für ein bestimmtes Zeitfenster (Lease). Wenn derselbe Rechner mehrmals bootet bzw. mehrfach Anfragen an einen DHCP-Server stellt, sollte dieser (im Rahmen der Lease oder einer statisch hinterlegten Regel) immer die gleiche IP erhalten. Ist dies nicht der Fall, kann es irgendwann passieren, dass keine freien IPs mehr zur Verfügung stehen und ein Client keine IP erhält. Außerdem gibt es voraussichtlich Probleme mit der Raumzuordnung von Clients innerhalb von bwLehrpool.

Im Fall von bwLehrpool werden beim Boot systembedingt zwei DHCP-Anfragen gestellt. Die Erste vom PXE-ROM, die Zweite vom MiniLinux. Manche PXE-Implementierungen senden die Option 61 (Abschnitt 9.14. Client-identifier) obwohl diese eigentlich nicht mehr verwendet werden sollte (Compatibility Issues). Wird diese Option vom Client bzw. PXE-ROM gesetzt, unterscheidet sich die Anfrage von der zweiten Anfrage des MiniLinux, welches die Option standardmäßig nicht setzt.

Normalerweise erkennt der DHCP-Server Rechner einfach anhand der MAC-Adresse - dann sollte es keine Probleme geben. Manche DHCP-Server prüfen jedoch den oben erwähnten Client Identifier (Option 61). Der DHCP-Server erkennt durch die dann zwei unterschiedlichen Anfragen, fälschlicherweise zwei unterschiedliche Clients und vergibt daher zwei IP-Adressen an den selben Client.

Um dieses Verhalten zu ändern, kann per Kernel Command Line (KCL) die Option 'dhcpuuid' gesetzt werden. Ist die Option gesetzt, setzt das MiniLinux in seinen DHCP-Anfragen die Option 61 auf die System-UUID. Bearbeiten Sie dazu den entsprechenden Bootmenü-Eintrag für bwLehrpool und fügen dhcpuuid hinzu. Somit sollten beide Anfragen wieder identisch und das Problem behoben sein.

Menüeintrag Beispiel (bwlp-default + dhcpuuid):

imgfree ||
set slxextra initrd=logo ||
initrd /boot/default/initramfs-stage31 || goto fail
initrd –name logo /tftp/bwlp.cpio || clear slxextra
boot -a -r /boot/default/kernel initrd=initramfs-stage31 ${slxextra} slxbase=boot/default quiet splash loglevel=5 rd.systemd.show_status=auto intel_iommu=igfx_off dhcpuuid ${ipappend1} ${ipappend2} || goto fail

Troubleshooting

Es kommt zu Problemen nachdem ein Client von Legacy-PXE auf UEFI umgestellt wurde
Wir empfehlen, falls möglich, weiterhin über BIOS bzw. Legacy-PXE zu booten. Je nach Hardware und Einstellung kann unterschiedliches Fehlverhalten eintreten. Prüfen Sie dazu die nachfolgenden Punkte.
Rechner hängt nach Abruf der IP-Adresse und piept
Versuchen Sie im Bios die Option CSM³⁾ zu deaktivieren
Rechner startet in einen Benchmark ähnlichen Testmodus
Wahrscheinlich wird ein falsches Bootfile ausgeliefert und der Client startet ein Diagnostic Tool des Systemherstellers anstatt bwLehrpool. Prüfen Sie, ob der Client das korrekte Bootfile vom DHCP-Server bekommt.
Fehlermeldung „NBP to big to fit in memory“
Anscheinend ist der Rechner auf Legacy-PXE eingestellt, bekommt jedoch vom DHCP-Server ein falsches Bootfile (z.B. ein EFI-File) ausgeliefert
Es kommt direkt der Fehler „ERROR 1962 – No Operating System Found“
Versuchen Sie im Bios CSM zu aktivieren und den Bootmodus auf Legacy-Only umzustellen (für BIOS-Boot) bzw. CSM zu deaktivieren und als Bootmodus UEFI-Only auszuwählen (für EFI-Boot)
Lokale Installationen booten plötzlich nicht mehr
Wenn Sie CSM deaktivieren, wird lokaler Boot älterer Betriebssysteme u.U. nicht mehr unterstützt.
IP-Adressen werden doppelt vergeben
Lesen Sie dazu den Abschnitt MAC/UUID
Clients werden einem falschen Raum in bwLehrpool zugeordnet
Lesen Sie dazu den Abschnitt MAC/UUID
Ein Client ist auf UEFI konfiguriert und erhält das korrekte Bootfile (ipxe.efi), dennoch schlägt der Boot fehl
Versuchen Sie alternativ anstatt ipxe.efi das File snponly.efi an den betroffenen Client auszuliefern. Ersteres enthält (für alle unterstützten NICs) eigene Treiber, letzteres nutzt das EFI-Treiber-Interface der Netzwerkkarte. Leider ist hier das Problem, dass einige Netzwerkkarten mit dem einen und einige mit dem anderen Ansatz besser funktionieren.

¹⁾

https://www.ietf.org/rfc/rfc2132.txt

²⁾

https://www.rfc-editor.org/rfc/rfc4578.txt

³⁾

https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#CSM_booting

Zuletzt angesehen: • ipxe-pxe