Beim Einschalten eines Rechners, egal ob physisch oder virtuell, läuft eine Reihe von Programmen ab, noch bevor das Betriebssystem startet. Was der Mainframe noch als "Initial Program Load" oder schlicht "IPL" bezeichnete, ist in der PC-Welt gemeinhin als "booten" bekannt. Technisch gesehen setzt der Prozessor den Programm-Counter auf die Speicherzelle 0 und arbeitet sich dann im Speicher vorwärts, bis er ausführbaren Programmcode findet. In einem regulären PC stößt die CPU zuerst auf das "Basic Input Output System", kurz BIOS, oder genauer gesagt: mehrere BIOS. Denn jedes Device, das in einem PC steckt, darf sein eigenes BIOS in den Speicher einblenden, sodass dieser Code noch vor dem Betriebssystem startet und die Hardware initialisiert.

In einem Desktop-PC ist vor allem das BIOS der Grafikkarte wichtig, sonst bleibt der Bildschirm dunkel. In Servern, die zur Not auch ohne Grafikkarte auskommen, muss eventuell erst ein RAID- oder SAN-Controller sein BIOS ausführen, damit das startende Betriebssystem später überhaupt eine Festplatte findet. Schon in den 1980er Jahren gab es darüber hinaus die Möglichkeit, mit einem BIOS auf der Netzwerkkarte den Systemstart über das LAN auszuführen. Damals konkurrierten jedoch die Hersteller der Netzwerkkarten mit eigenen Bootcodes. Erst 1998 stellte Intel die PXE-Spezifikation 2.0 (Preboot Execution Environment) vor, die seither einheitlich bei allen Systemen zum Einsatz kommt.

In der Zwischenzeit hat sich PXE weiterentwickelt und streng genommen haben wir es heute mit zwei verschiedenen Netzwerk-Bootprozessen zu tun: PXE für PCs mit BIOS und PXE für Systeme mit UEFI/EFI. In diesem Artikel gehen wir auf beide Verfahren detaillierter ein.

Eigentlich jeder moderne PC oder Server mit eingebauter Netzwerkkarte kann heute via PXE sein Betriebssystem über das LAN starten. Diese Funktion nutzen Administratoren in erster Linie, um neue Rechner zu installieren. Aber PXE kann mehr. Anwender können Stationen ohne Festplatten (Diskless) über PXE starten oder auch Rechner, die als Platte ein iSCSI-SAN-Laufwerk verwenden. Letzteres eignet sich natürlich hervorragend als Disaster-Recovery-Option. Nutzer lassen dabei einfach kontinuierliche Backups ihres lokalen Laufwerks auf ein iSCSI-Volume laufen. Falls die lokale Platte ausfällt, booten sie das System einfach via PXE und nutzen die iSCSI-Kopie als Root-Laufwerk.

Das PXE-Verfahren setzt auf eine Reihe von Standard-IP-Protokollen auf. Den Anfang macht DHCP (Dynamic Host Configuration Protocol). Der Client versendet zuerst per Layer-2-Broadcast, denn noch hat er keine IP-Adresse, die Nachricht "DHCPDISCOVER" und wartet auf die Antwort eines DHCP-Servers. Bereits mit dieser ersten Anfrage übermittelt der Client seinen "System Type", also ob er ein per BIOS oder UEFI startender Rechner ist. Der DHCP-Server erwidert die Anfrage mit einer "DHCPOFFER". Die enthält eine ganze Reihe von Informationen: Die IP-Adresse, die der Client nutzen darf, zusammen mit der Leasetime, also wie lange er diese Adresse behalten darf. Dazu jede Menge Netzwerkinformationen zur Netzwerkmaske, Routen und DNS-Servern.

Je nach Diensten im LAN kann der DHCP-Server auch Informationen zum Active Directory (AD), den Zeitservern oder andere Informationen liefern. Gibt es einen Bootserver für PXE im Netzwerk, sendet DHCPOFFER sowohl dessen IP-Adresse als auch Details zum Startcode. Der PXE-Bootserver darf auf einer anderen Maschine als der DHCP-Server laufen. In unserem Beispiel arbeiten beide Dienste zusammen. Der Client beantwortet die "Offer" mit einem "Request", dass er die dargebotene IP-Adresse gerne hätte und DHCP beschließt den Vorgang mit einem "Acknowledge".

Möchte der Client nun via LAN starten, nutzt er bei beiden Bootverfahren erst einmal das TFTP-Protokoll, um den Startcode vom Bootserver zu erhalten. Das "Trivial File Transfer Protocol" (TFTP) ist prinzipiell der kleine Bruder vom bekannten "File Transfer Protocol" (FTP), nur dass TFTP auf Authentisierung und jegliche Sicherheitsfunktionen wie Verschlüsselung verzichtet. Da das Protokoll eine sehr kleine Blockgröße verwendet, begrenzt es die Transfergröße für Dateien auf maximal 4 GByte. Außerdem ist es recht langsam. In der Regel genügen jedoch ein paar KByte an Transfers, um einen Kernel oder einen Bootloader zu senden. In der Regel überträgt TFTP ohnehin nur den ersten Bootloader – anschließend kann es mit einem regulären IP-Protokoll wie HTTP, HTTPS, (S)FTP oder auch NFS weitergehen.

Um den vollen Funktionsumfang von PXE und DHCP nutzen zu können, benötigen Sie einen eigenen DHCP-Server auf Basis eines Linux-Rechners oder einer Linux-VM. In der Regel haben Sie bereits einen DHCP-Server im LAN. Diese Rolle übernimmt in kleineren Netzwerken gern der Router selbst. In einem LAN darf es aber nur einen DHCP-Server geben, also müssen Sie einen eventuell bestehenden DHCP-Server abschalten und diese Aufgabe an den neuen übertragen.

Installieren Sie auf dem System Ihrer Wahl zunächst die Pakete "dnsmasq" und "syslinux". Dann erstellen Sie ein Verzeichnis für den TFTP-Server, in der Regel unter "/var/lib/tftpboot". Kopieren Sie den kompletten Inhalt der Syslinux-Installation (bei Fedora unter "/usr/share/syslinux") in dieses "tftpboot"-Verzeichnis. Diesen Schritt brauchen sie nur für PXE mit BIOS-PCs.

Installieren Sie einen Webserver wie Apache oder Nginx mit der Standardkonfiguration. Im weiteren Verlauf des Artikels gehen wir davon aus, dass der Webserver in der Basiskonfiguration Dateien aus "/var/www/html" und deren Unterverzeichnissen bereitstellt.

Der Dienst dnsmasq übernimmt in unserem Setup alle Funktionen von DNS via DHCP und TFTP. Konfigurieren lässt er sich über die beiden Dateien "/etc/ dnsmasq.conf" und "/etc/hosts". Letztere beherbergt die Namen der lokalen Systeme für den DNS-Dienst, zum Beispiel

Das Format beginnt mit der IP-Adresse, gefolgt von einem oder mehreren Namen der Maschine, und ein Eintrag dient dem FQDN (Fully Qualified Domain Name). Zudem spendieren wir dem Server noch die Datei "/etc/nameservers.conf". Dort listen wir Internet-Nameserver auf, an die der dnsmasq-Dienst externe Namensanfragen weiterleitet. In diese Datei tragen Sie die Adressen der DNS-Server Ihres Providers ein oder nutzen freie DNS-Provider wie Google. Die Datei "dnsmasq.conf" sieht dann in etwa wie folgt aus:

Das "interface" muss die Netzwerkkarte Ihres DHCP-Servers enthalten. "range" gibt einen Adress-Pool an, aus dem DHCP-Clients ihre IP-Adresse erhalten. Die Leasetime von hier 72 Stunden gibt an, wie lange DHCP-Clients ihre Adresse behalten dürfen. Bekommen Sie über ihren Provider ein IPv6-Subnetzwerk zugewiesen, kann ihr DHCP-Server Adressen aus diesem Segment an Ihre LAN-Systeme weitergeben – manchmal auch als "Router Advertisement" bezeichnet:

Falls nötig, geben Sie weitere DHCP-Optionen (gemäß RFC2132) an, die Sie an Ihre Clients übermitteln wollen, beispielsweise einen NetBios-Nameserver:

dnsmasq unterstützt auch die besser lesbare Form

Die eigentliche PXE-Konfiguration für das Modul "BIOS PXE" nimmt erst einmal nur drei Zeilen ein:

Die Datei "pxelinux.0" ist dabei der Bootloader aus dem Syslinux-Paket, der dann auf dem startenden Client ausgeführt wird. An dessen Stelle könnte auch der Bootloader Grub zum Einsatz kommen. Den verwenden wir in unserem Beispiel erst später für den UEFI-Bootvorgang.

Dem Syslinux-Bootloader gibt der PXE-Server eine Konfigurationsdatei mit. Dazu legen Sie unter "/var/lib/tftpboot" das Verzeichnis "pxelinux.cfg" an. In diesem erstellen Sie eine Textdatei namens "default" erst einmal mit folgendem Inhalt:

Die Einträge sind nicht case sensitive. Das Standardmenü offeriert erst einmal nur eine Option, den Start vom lokalen Datenträger des Systems. Es gibt eine Reihe von Optionen, um das PXE-Menü etwas bunter zu gestalten und ein PNG-Bild als Hintergrund zu laden, worauf wir an dieser Stelle aber nicht genauer eingehen. Die exakte Dokumentation zur Syntax eines Syslinux-Menüs finden Sie unter [1].

Um nun ein Fedora-34-Livesystem via PXE zu starten, gehen Sie wie folgt vor: Entpacken Sie zunächst den Inhalt des Fedora-34-Live-ISO-Images in ein Unterverzeichnis Ihres Webservers, also beispielsweise mit

Dann erstellen Sie den passenden Eintrag in "/var/lib/tftpboot/pxelinux.cfg/default":

Wenn Sie jetzt einen Client via PXE booten, bekommen Sie ein Auswahlmenü für "local", also den Start von der Platte oder "fedora34-live". Ähnlich starten Sie dann auch andere Live-Distributionen wie Debian oder Ubuntu. Zudem können Sie Kickstart-Dateien erzeugen, die die Installation eines Linux-Systems automatisieren, um dann eine vollautomatische Installation aus dem PXE-Menü heraus zu starten.

Das hier gezeigte Menü setzt allerdings voraus, dass Sie moderne PXE-Clients einsetzen, die das HTTP-Protokoll unterstützen. Es gibt ältere PXE-Implementierungen, die mit "kernel http://.." nicht klarkommen. In einem Testsetup ist das beispielsweise bei der PXE-Implementierung in Virtualbox der Fall. In diesem Fall müssen sie die referenzierten Dateien "vmlinuz" und "initrd.img" in ein Unterverzeichnis unter "/var/lib/tftpboot" kopieren und von dort via TFTP statt HTTP laden. Nehmen wir an, Sie erstellen Kopien der Dateien unter "/var/lib/tftpboot/f34", dann sähe der passende Eintrag so aus:

Der Verweis auf "squashfs.img" via HTTP darf übrigens bleiben, denn diesen wertet erst der gestartete Kernel aus und nicht der PXE-Loader.

Um Windows über den Linux-PXE-Server zu starten, brauchen Sie zuerst ein Windows-PE-ISO-Image. Eine Anleitung dafür finden Sie unter anderem unter [2]. Wichtig ist dabei, dass Sie dem PE-Abbild alle Netzwerktreiber hinzufügen, die auf Ihren Systemen zum Einsatz kommen. Legen Sie das fertige Windows-PE-Image im Verzeichnis des TFTP-Servers unter "/var/lib/tftpboot" ab. Für unser Beispiel nennen wir es einfach "winpe.iso". Fügen Sie dann Ihrem PXE-Startmenü folgenden Eintrag hinzu:

Alternativ entpacken Sie den Inhalt der Windows-PE-CD in ein Unterverzeichnis auf dem TFTP-Server, etwa "/var/lib/ tftpboot/pe", und besorgen sich den Bootloader "wimboot" aus dem iPXE-Paket [3]. Dann würde der Eintrag so aussehen:

Jetzt lässt sich die Windows-PE-Instanz direkt über das Netzwerk starten. Dort können Sie Diagnosetools oder das Windows-Setup via LAN ausführen. Dazu entpacken Sie einfach eine Windows-Installations-DVD in eine Windows- oder Samba-Dateifreigabe. Auf der PE-Instanz öffnen Sie die Windows-Kommandozeile, wo Sie folgenden Befehl eingeben:

Wechseln Sie dann auf das Laufwerk "w:" und in das Unterverzeichnis, in das Sie die DVD entpackt haben. Von dort starten Sie die Windows-Installation mit der Datei "setup.exe". Auch hier können Sie den Vorgang mithilfe einer passenden Antwortdatei automatisieren.

Nicht jeder Client, der via PXE startet, erhält zwangsweise das Menü aus der Default-Konfigurationsdatei. Bevor pxelinux diese anbietet, sucht es erst einmal nach individuellen Konfigurationsdateien für den startenden Client. Zuerst prüft der Dienst, ob eine Datei passend zur MAC-Adresse des startenden Clients existiert. Bootet beispielsweise der Client mit der MAC-Adresse "48:2a:01:02:03:ff", sucht pxelinux nach der Datei "01-48-2a-01-02-03-ff" in "/var/lib/tftpboot/pxelinux.cfg/". Falls es diese nicht gibt, sucht das Programm nach Konfigurationsdateien passend zur IP-Adresse im hexadezimalen Format. Startet ein Client mit der IP 192.168.2.201, hält pxelinux Ausschau nach Konfigurationsdateien wie "C0A802C9", "C0A802C", "C0A802" bis hin zu "C". Erst wenn diese nicht existieren, nutzt der Start-Service die Konfiguration aus "default".

Über diesen Weg können Sie individuelle Bootdateien für einzelne Clients oder Gruppen erstellen. Hilfreich ist dabei die dnsmasq-Option, einzelnen Clients via "dnsmasq.conf" feste IP-Adressen zuzuweisen, etwa

Die Adresse sollte dabei außerhalb des anfangs definierten DHCP-Pools bleiben. Wenn der gewählte Client immer diese Adresse erhalten soll, stellen Sie die Leasetime einfach auf "infinite".

Mit dem Itanium-Prozessor führte Intel in den 90ern das "Extensible Firmware Interface" als BIOS-Ersatz ein. Das hob die 16-Bit-Beschränkungen des BIOS auf und erlaubte individuelle Erweiterungen. Ab 2005 hat sich eine Allianz verschiedener Hersteller im "UEFI Forum" zusammengetan und entwickelt seither die nun nicht mehr proprietäre, sondern quelloffene Spezifikation UEFI (Unified Extensible Firmware Interface). Davon gibt es auch Open-Source-Implementierungen wie "EDK2", das von der TianoCore-Community gepflegt wird und im freien Hypervisor KVM zum Einsatz kommt.

UEFI selbst kann Datenträger mit GPT-Partitionen adressieren und schon ohne ein laufendes OS auf FAT-Datenträger zugreifen. Unter Linux findet sich die UEFI-Boot-Partition in der Regel unter "/boot/efi". Mit UEFI lässt sich der Startvorgang absichern, indem der Bootprozess nur korrekt signierte Dateien ausführt (Secure Boot), zu denen er einen gültigen Schlüssel besitzt. Das hatte in der Vergangenheit öfter zu Unmut geführt – viele Hardwarehersteller implementieren in den Maschinen nur Microsoft Keys, sodass bei aktiviertem Secure Boot eigentlich nur Windows starten kann.

Für Linux gibt es in der Zwischenzeit den von Microsoft signierten UEFI-First-Stage-Loader "shim". Der baut eine eigene Secure-Trust-Kette mit Folgeprogrammen wie grub oder dem Linux-Kernel auf. Daher muss das UEFI-SE im Rechner selbst nur "shim" vertrauen, um mit Secure Boot auch Open-Source-Linux starten zu können. Der Benutzer muss dann aber eigene Schlüssel erstellen und die weiteren Programme in der Bootreihenfolge, etwa grub und den System-Kernel, selbst signieren. Im weiteren Verlauf des Workshops gehen wir nicht weiter auf Secure Boot ein und betrachten den UEFI-Start mit abgeschaltetem Secure Boot.

Für den Systemstart eines Linux-Rechners via UEFI braucht es zunächst den primären (shim) und sekundären Launcher (grub). Die benötigten Dateien "shimx64. efi" und "grubx64.efi" gibt es im Repository der jeweiligen Linux-Distribution. Am einfachsten nehmen Sie einen bereits installierten Linux-Rechner mit einer "/boot/ efi"-Partition. Kopieren Sie die beiden Dateien von dort aus in das Verzeichnis "/var/lib/tftpboot" ihres dnsmasq-Servers. Unter Fedora liegen die Bootloader beispielsweise in "/boot/efi/EFI/fedora".

Für die UEFI-Maschinen bauen Sie ein neues Boot-Menu, nur diesmal über grub und nicht syslinux. Dazu legen Sie die Datei "/var/lib/tftpboot/grub.cfg" an. Die Syntax von "grub.cfg" ist etwas komplexer, aber unter [4] sehr ausführlich dokumentiert. In unserem Beispiel aus dem Listing-Kasten nutzen wir einen kleinen Standard-Header.

Darauf folgen die Menüeinträge, die sich via UEFI starten lassen. Gemäß dem pxelinux-Beispiel sähe der Menüeintrag für das Fedora-34-Live-System folgendermaßen aus:

Wie schon bei pxelinux sucht auch grub zuerst nach individuellen Konfigurationsdateien. Hier ist das Namensschema wie folgt: grub.cfg-01-48-2a-01-02-03-ff für eine direkte MAC-Adresse und grub. cfg-C0A802C bis grub.cfg-C abhängig von der IP-Adresse. Nur wenn keine dieser Dateien passt, bietet Grub das Menü aus "grub.cfg" an.

Damit nun der dnsmasq-Server zwischen BIOS- und UEFI-bootenden Rechnern unterscheiden kann, bedarf es zweier Einträge in "/etc/dnsmasq.conf". Der erste weist der Client-Architektur "7" (UEFI-64-Bit-PC) das Label "efi-x86_64" zu. Der zweite Eintrag legt dann die Bootdatei für diese Architektur auf:

Jetzt kann der dnsmasq-Server problemlos sowohl Bios-PXE-Clients via pxelinux als auch UEFI-PXE-Clients über shim und grub bedienen.

Steht der PXE-Server erst einmal im LAN, fällt es dem Administrator recht leicht, neue Rechner und VMs per Netzwerkinstallation aufzusetzen. Sowohl die Win­dows- als auch Linux-Installationsprogramme unterstützen diverse Optionen für unbeaufsichtigte Set-ups. Alles, was der Administrator bei einem neuen System im LAN dann noch tun muss, ist via LAN starten und den passenden PXE-Eintrag für die automatische Installation anwählen. Zudem sollten Sie die Anwendungsgebiete für Diskless Clients/ Server sowie die Disaster Recovery nicht vernachlässigen. Wer einen kleinen Cluster mit Virtualisierungsservern betreibt, die ohnehin einen gemeinsamen iSCSI- oder NFS-SAN-Speicher für die VMs verwenden, kann diese ohne Festplatten betreiben und via LAN booten.