Von der DHCP-Antwort zur fertigen Installation

Eine Maschine dazu zu bringen, ein Netboot-Angebot anzunehmen, ist der Teil, über den alle schreiben. Wir haben auch darüber geschrieben, nachdem uns die Zieladresse einer Proxy-DHCP-Antwort eine Woche gekostet hatte.

Der Teil danach wird kaum behandelt, und dort wohnen die tatsächlichen Fehler. Eine Maschine, die bootet und dann für immer auf einer Frage sitzen bleibt, ist schlimmer als eine, die nie gebootet hat, denn sie sieht nach Fortschritt aus. Das hier ist die zweite Hälfte: was zwischen dem eintreffenden Angebot und einer erscheinenden Anmeldeaufforderung wahr sein muss, und welche dieser Dinge still scheitern.

Die fünf Dinge, die ausgeliefert werden

Sobald der Client ein Angebot und eine Bootdatei hat, besteht eine unbeaufsichtigte Installation aus fünf Artefakten. Keines davon ist optional, und das letzte ist das, was die Leute weglassen.

Interessant ist die letzte Spalte. Die Punkte 1 bis 3 scheitern laut, auf dem Bildschirm, auf eine Art, die jemandem auffällt. Die Punkte 4 und 5 scheitern als eine Installation, die zu laufen scheint und nie fertig wird.

Bootskripte und das Problem mit dem Platzhalter

Das Bootskript muss absolute URLs nennen, und es kann sie beim Schreiben des Profils nicht kennen: Die Adresse dessen, was die Dateien ausliefert, hängt vom Segment ab, in dem die Maschine hochgekommen ist.

Das Profil enthält deshalb einen Platzhalter, der beim Ausliefern ersetzt wird. Unserer ist @@PROVIBR_BASE@@, und seine Form ist eine bewusste Entscheidung und keine Stilvorliebe.

Die naheliegende Form wäre ${BASE}. Die ist genau falsch, denn iPXE expandiert ${...} selbst. Eine Ersetzung, die nicht stattfindet, wird zu einer leeren Zeichenkette statt zu einem Fehler, und Sie starren am Ende auf

chain http:///vmlinuz

und fragen sich, was mit Ihrem Webserver nicht stimmt. Ein Trennzeichen, das der Bootloader nicht kennt, macht aus einer stillen fehlgeschlagenen Ersetzung eine sichtbare.

Die drei Kernel-Kommandozeilen, auf die es ankommt, wenn man die Markenteile abzieht:

# Ubuntu (subiquity)
kernel <kernel> initrd=<initrd> ip=dhcp autoinstall ds=nocloud;s=<dir>/ --- || goto failed

# Debian (preseed)
kernel <kernel> initrd=<initrd> auto=true priority=critical ip=dhcp url=<file> DEBIAN_FRONTEND=text --- quiet || goto failed

# RHEL family (Anaconda)
kernel <kernel> initrd=<initrd> ip=dhcp inst.repo=<tree> inst.ks=<file> inst.text || goto failed

Drei Installer, drei völlig verschiedene Vokabulare für dieselbe Idee, und das Argument, das die Antwortdatei trägt, wird in jedem anders geschrieben. ds= nimmt ein Verzeichnis; url= und inst.ks= nehmen eine Datei. Das zu verwechseln beschert Ihnen einen Installer, der bootet und dann die erste Frage stellt.

Die vier Autoinstall-Schlüssel, die über den Abschluss entscheiden

Ubuntus Autoinstall verdient einen eigenen Absatz, denn auf einem abgeschotteten Segment trennen vier Schlüssel eine Installation, die durchläuft, von einer, die es nicht tut, und keiner davon hat mit Platten oder Benutzern zu tun:

• interactive-sections: []: ohne das hält subiquity trotzdem an, um etwas zu fragen.
• refresh-installer.update: false: ohne das sucht es erst nach einem neueren Installer.
• apt.fallback: offline-install: ohne das wartet es auf das Archiv, bevor es aufgibt.
• drivers.install: false: dieselbe Klasse von Problem, dasselbe Ergebnis.

Der Fehler ist in jedem Fall derselbe: ein Bildschirm, der beschäftigt aussieht. Es gibt keine Fehlermeldung, denn aus Sicht des Installers ist nichts schiefgegangen.

Es gibt eine passende Einstellung für das Medium. Ubuntus Netboot-Initrd packt ein Installationsmedium in ein tmpfs aus und installiert daraus; sagen Sie ihm nicht, wo dieses Medium ist, geht es ins Internet, um eines zu suchen. Auf einem Segment ohne Uplink ist das der Unterschied zwischen funktionieren und vier Minuten nichts, gefolgt von einer Busybox-Eingabeaufforderung.

Die Rückmeldung, die niemand schreibt

Punkt 5 auf der Liste ist eine einzige Zeile in einem Post-Install-Skript, die eine URL abruft, und es ist das am häufigsten fehlende Stück in einem selbst gebauten Aufbau.

Ohne sie gibt es kein Ereignis, das fertig bedeutet. Der Installer startet neu, die Maschine kommt hoch, und das System, das die Installation gestartet hat, weiß nichts davon, wartet also bis zu der Frist, die es hat, und meldet dann eine Zeitüberschreitung auf einer Maschine, die einwandfrei installiert wurde.

Zwei Details machen das weniger ärgerlich, als es klingt. Erstens: Liefern Sie den Aufruf in der Vorlage aus, statt ihn zu dokumentieren, damit jemand, der sein eigenes Post-Install-Skript schreibt, nicht wissen muss, dass es ihn gibt. Zweitens: Sehen Sie neben einem Aufruf für den Erfolg auch einen für den Fehlschlag vor. Eine Installation, die um 04:00 Uhr scheitert und das sagt, ist eine andere Supporterfahrung als eine, die verstummt.

Und führen Sie zwei Uhren, nicht eine. Der Befehl, der eine Installation startet, sollte fertig sein, sobald die Listener stehen und die Sitzung angenommen ist, nicht wenn die Installation fertig ist; unserer hat dafür eine Frist von 90 Sekunden, gegen ein Installationsbudget von einer Stunde, das auf beiden Seiten durchgesetzt wird. Eine einzige Frist für beides bedeutet entweder einen Auftrag, der eine Stunde lang untätig in der Oberfläche steht, oder eine Installation, die abgebrochen wird, weil sie so lange dauert, wie Installationen eben dauern.

Welche Anbieter eine Prüfsumme veröffentlichen, gemessen

Wenn die Maschine einen Kernel und ein Initrd über HTTP von einem Spiegel holt, sollte irgendetwas prüfen, was zurückkam. Der Weg dahin ist, im Profil eine sha256 festzuschreiben und sie nach dem Download zu prüfen, und zwar an der Stelle, die den Abruf macht.

Das geht nur, wenn der Anbieter eine veröffentlicht. Wir nahmen an, die Antwort laute „größtenteils nein“, schrieben das auf, und es stellte sich in drei von vier Fällen als falsch heraus. Was tatsächlich veröffentlicht wird, gemessen am 02.09.2026:

Der Preis dieser falschen Annahme war kein Ausfall; er war auf leise Art schlimmer. Artefakte, die man hätte festschreiben können, standen als nicht überprüfbar markiert, und Profile meldeten sich selbst als nicht installierbar, während der Anbieter die Antwort offen sichtbar veröffentlichte. Vier von fünf Artefakten über die ersten beiden Profile hinweg.

Das Verhalten für den Fall, dass es wirklich keine Prüfsumme gibt, gehört bewusst entworfen. Unseres lässt die Festlegung leer, markiert das Artefakt als ausstehend, und das Profil meldet sich als nicht installierbar, bis ein Administrator einen Hash einfügt. Das ist absichtlich lauter, als es trotzdem herunterzuladen. Ein ungeprüfter Kernel, über HTTP von einem Spiegel geholt, ist die lohnendste einzelne Stelle, um ein Bereitstellungssystem anzugreifen, und „wir konnten das nicht prüfen, also haben wir es trotzdem gemacht“ ist keine Richtlinie.

Was „gepflegt“ heißen darf

Wir liefern zehn Basisprofile aus: Ubuntu Server 24.04 und 26.04, Debian 12 und 13, Rocky Linux 9 und 10, AlmaLinux 9 und 10, CentOS Stream 10, Fedora Server 44.

Der Unterstützungsstatus jedes einzelnen wird berechnet, nicht getippt. Ein Profil darf sich nur dann gepflegt nennen, wenn es einen überprüften Lauf auf beiden Firmwarepfaden hat, BIOS und UEFI. Einer von beiden ergibt „Vorschau“. Keiner von beiden ergibt „ungepflegt“.

Daraus eine Regel statt eines Feldes zu machen ist die kleine Menge Code wert. Eine von Hand getippte Kennzeichnung ist genau so viel wert wie die Sorgfalt dessen, der sie getippt hat, und im Vertrauen auf diese Kennzeichnung setzt ein Kunde eine Maschine auf.

Das heißt auch, klar zu sagen, wo uns das heute lässt. Ubuntu Server 26.04 und Debian 13 haben sich auf einem abgeschotteten Segment vollständig unbeaufsichtigt installiert, auf einer BIOS-Maschine. Der UEFI-Pfad wurde in derselben Runde repariert, und ihn zu reparieren ist nicht dasselbe, wie ihn laufen zu lassen. Kein mitgeliefertes Profil ist zum Zeitpunkt des Schreibens daher maintained, und die Profile der RHEL-Familie sind überhaupt noch nicht auf einer echten Maschine gelaufen: Sie wurden aus der Anbieterdokumentation geschrieben und gegen echte Quelldateien gemessen, was eine schwächere Behauptung ist, als sie von außen aussieht.

Davon getrennt ist Netboot als Weg, eine neue Maschine anzulegen, in unserer Plattform standardmäßig aus, und zwar bis genau eine Sache erfüllt ist: eine echte Maschine, die sich auf diesem Weg selbst installiert, auf echter Firmware. Der Weg, den es gibt und der benutzt wird, ist die Neuinstallation über eine bestehende Maschine. Ein Funktionsschalter, der an ist, weil der Code geschrieben wurde, und nicht, weil beobachtet wurde, dass die Sache funktioniert, erzeugt eine Bestellschaltfläche, die beim ersten echten Kunden auf halbem Weg strandet.

Kleinigkeiten, die je einen Nachmittag kosten

• Prüfen Sie die Pfade ausgelieferter Dateien. Kein führender Schrägstrich, kein .., keine Backslashes, eine Zeichenklasse. Was die Dateien ausliefert, steht im Netz von jemandem, mit einem Dateisystem dahinter.
• Schwärzen Sie die Prüfzeile. Halten Sie fest, welche Datei ausgeliefert wurde und ob sie ein Geheimnis trug, nie den Inhalt. Wer den Inhalt braucht, kann das Profil neu erzeugen.
• Lassen Sie die Antwortdatei keine zweite Wahrheit über das Medium sein. Das Kernelargument und die Antwortdatei nennen beide, woher die Pakete kommen; beide aus einer Einstellung abzuleiten ist der einzige Weg, auf dem sie gleich bleiben.
• Nehmen Sie an, dass niemand auf die Konsole schaut. Jede Entscheidung oben ist eine Entscheidung darüber, was passiert, wenn die Installation bei Minute sechs von acht steht und kein Mensch im Raum ist.

Das ist der zweite Teil des Stücks darüber, warum UEFI-Netboot scheitert, wo BIOS funktioniert, und es entstand beim Einbau der Netzwerkinstallation in Provibr. Die Einzelheiten stehen in der Netboot-Dokumentation.