und die 
Utilities
Netzboot
(letzte Änderung 17.07.11)
Durch die Anschaffung von einem Klassensatz gebrauchter IBM-PCs bin ich eher zufällig auch in den Besitz von Netzwerkkarten des Typs Intel Pro/100 S gekommen. Diese Karten ließen sich mit einer aktuelleren PXE-Erweiterung flashen und ermöglichten es den Rechnern dann, direkt vom Server zu booten. (Vorgeschichte überspringen)
Da die Erfahrung in den letzten Jahren gezeigt hat, dass man komplexere Dinge, die man nicht täglich macht, schnell wieder vergisst, habe ich hier alles dokumentiert - vielleicht hilft diese Seite dem einen oder anderen.
Schon der erste Versuch funktionierte auf Anhieb, leider nur auf einem Teil meiner Arbeitsstationen. Die anderen Rechner blieben aus unerfindlichen Gründen beim Booten hängen bzw. luden das gewählte Boot-Image erst gar nicht. Zudem weigerte sich der Boot-Loader mba.pxe, Images zu laden, deren Größe die voreingestellte Diskettengröße von 1,44 MB überschritten.
Auch mit der Kombination BPBatch (als Boot-Loader) und TFTPD32 sah ich mich zwischendurch schon mal auf der Zielgeraden und konnte Bart's Network Boot Disk einwandfrei durchs Netz booten. Andere Boot-Disketten, vor allem eine der von mir oft benutzten Multicast-Disketten, mit denen ich die Arbeitsstationen in unserem Rechnerraum spiegele, liefen allerdings nicht. Die Images wurden zwar geladen und der Boot-Vorgang begann, dann aber zerschossen die Programme, die aus dem Image heraus geladen wurden, immer wieder die Ramdisk, in der sie gespeichert waren.
Zudem habe ich bei längerem Googeln den Eindruck gewonnen, dass sich jemand viel Mühe gemacht hat, alle Spuren von BPBatch im Internet zu verwischen, seitdem ein darauf basierendes kommerzielles Produkt existiert ...
Zum Erfolg führte schließlich die Kombination von pxelinux.0 aus dem Packet Syslinux von H. Peter Anvin als Boot-Loader und dem Freeware-Programm TFTPD32 als TFTP-Server.
Und so funktioniert es:
Beim Hochfahren einer Arbeitsstation setzt die Netzwerkkarte ihre MAC-Adresse per Broadcast ins Netz und fordert eine IP an. TFTPD32 vergibt eine IP-Adresse aus einem voreingestellten Pool und schickt die Datei pxelinux.0 an den anfordernden Rechner.
Dort angekommen übernimmt pxelinux.0 die Aufgabe, die beim Booten einer DOS-Diskette die Datei IO.SYS erledigt: pxelinux.0 sucht zunächst nach einer Cfg-Datei (vergleichbar CONFIG.SYS). Diese Datei wird auf dem Server im Ordner 'pxelinux.cfg' gesucht, der im gleichen Ordner angelegt sein muss, aus dem heraus pxelinux.0 geladen worden ist. (Wichtig: pxelinux.cfg ist wirklich ein Ordner und keine Datei!)
Da vom Server unterschiedliche Systeme gleichzeitig gebootet werden können, erfolgt die Suche in bis zu vier Stufen:
- Zunächst wird im Ordner pxelinux.cfg eine Datei gesucht, deren Name sich aus der UUID zusammensetzt (Hex in Kleinbuchstaben, z.B. b8945908-d6a6-41a9-611d-74a6ab80b83d). Falls das BIOS des Clientrechners eine gültige UUID erzeugt, lässt sich so leicht für jede Arbeitsstation eine eigene Cfg-Datei erzeugen.
- Wird eine solche Cfg-Datei nicht gefunden, wird im Ordner pxelinux.cfg nach einer Datei gesucht, deren Name sich aus '01-' und der MAC-Adresse der Netzwerkkarte zusammensetzt (01-11-22-33-44-55-66).
- Wird auch die Cfg-Datei nicht gefunden, versucht der Bootloader eine Datei zu laden, die als Namen die vom DHCP-Server zugeteilte IP-Adresse der Arbeitsstation trägt (8stellig in Hex, 192.168.0.101 wird als C0A80065 gesucht). Wenn eine solche Datei auch nicht gefunden wird, kürzt pxelinux.0 den Namen hinten um eine Stelle und versucht es noch einmal. Das Spielchen wiederholt sich, bis alle Hex-Ziffern weg sind.
- Wenn der Bootloader bis hierhin immer noch nicht erfolgreich war, versucht er die Datei 'default' zu laden (ebenfalls aus dem Verzeichnis pxelinux.cfg unterhalb des Ordners, aus dem pxelinux.0 selbst geladen wurde).
- Wenn selbst die Datei 'default' nicht gefunden wurde, wird als voreingestellter Kernelname 'linux' benutzt (ohne jede Option). Wird dieser Kernel auch nicht gefunden, wird das Booten durch's Netz abgebrochen und das nächste im BIOS eingestellte Boot-Device übernimmt die Kontrolle.
Aufbau der Konfigurations-Datei für pxelinux.0
Ich beschreibe hier nur einige Beispiele, die ich in der Form selbst benutzt habe. Ausführlichere Informationen gibt es hier.
Beispiel_1 (Laden einer Bootdiskette für einen NetVista-PC zur Teilnahme am Multicast)
default nvm
label nvm
kernel memdisk
append initrd=nvmcast.img
lädt ohne weiteres Eingreifen das DOS-Diskettenimage 'nvmcast.img' und bootet auch gleich von dieser virtuellen 'Diskette'.
Beispiel_2
default lboot
label lboot
localboot 0
lädt kein weiteres Image durchs Netz sondern übergibt die Kontrolle an das lokale Diskettenlaufwerk oder die Festplatte (je nach BIOS-Einstellung). Mit einer solchen Cfg-Datei wird das Booten durchs Netz praktisch abgeschaltet.
pxelinux.0 bietet aber nicht nur solch einfache Optionen sondern kann (mit ein wenig Aufwand) so konfiguriert werden, dass auf der Arbeitsstation ein komfortables Boot-Menü mit mehreren Optionen erscheint. Selbst Farben sind möglich und ein Hintergrundbild lässt sich einbinden (habe ich bisher nicht getestet).
Beispiel_3
prompt 1
display pxelinux.cfg\boot.msg
default nvm
timeout 150
label nvm
kernel memdisk
append initrd=nvmcast.img
label bart
kernel memdisk
append initrd=bartsbig.img
label local
localboot 0
zeigt - sofern vorhanden - die Datei 'boot.msg' im Ordner pxelinux.cfg an und bietet einen Prompt, der die Eingabemöglichkeiten 'nvm', 'bart' oder 'local' akzeptiert (Groß/Kleinschreibung muss dabei beachtet werden). Nach 15 Sekunden bzw. Drücken der Eingabetaste ohne Eingabe eines Labels werden die Optionen unter dem Label 'nvm' (default) ausgeführt. Gibt man innerhalb der 15 Sekunden 'bart' oder 'local' ein, werden die Optionen hinter diesen Labels ausgeführt.
Es hat mich anfangs ein wenig irritiert, dass die Cfg-Datei selbst keine Ausgabe auf dem Client-Bildschirm erzeugt. Man muss daher schon aufpassen, dass bei Änderungen und Erweiterungen der Cfg-Datei die Msg-Datei 'synchron' bleibt.
Die Benutzung des Windows-TFTP ermöglicht es, durch einfaches Kopieren von entsprechenden Cfg-Dateien in den Ordner pxelinux.cfg das Startverhalten der Arbeitsstationen zu beeinflussen, ohne jedesmal im BIOS die Boot-Reihenfolge zu verändern. Die zugehörigen Boot-Images können einfach im TFTP-Ordner verbleiben.
- Verschiedene Beispiele für lauffähige Konfigurationen
Eine der Dateien muss unter dem Namen 'default' oder 'C0A8' (wenn sich die Arbeitsstationen und der TFTPD-Server in einem 192.168.xx.xx-Netz befinden) in den Ordner pxelinux.cfg kopiert werden. Die zugehörige Datei boot.msg sollte ggf. nicht vergessen werden, sonst sieht man auf den Arbeitsstationen kein Menü.
Cfg-Beispiele (1 KByte)
Die Erzeugung von Boot-Images
ist scheinbar eine Wissenschaft für sich. Nach mehreren erfolglosen Versuchen mit Imgedit bin ich mit Virtual-Floppy-Drive und Diskimag endlich zum Ziel gelangt. Mit Virtual-Floppy-Drive kann man unter Windows-2000-XP-(7?) eine virtuelle Floppy-Disk (z.B. als Laufwerk B:) einbinden, diese startfähig machen und alle benötigten Programme, Treiber etc. kopieren. Nachdem man die virtuelle Floppy dismountet (erst dann wird die u.U. geänderte Struktur auf die Festplatte geschrieben) hat, kann man die zugehörige Image-Datei in den TFTPD-Boot-Ordner kopieren.
Eine bereits fertige Datei lässt sich auch nachträglich wieder mounten und anschließend verändern.
Ich habe Bart's Network Boot Disk auf eine zuvor gemountete 2,88-MB Image-Datei installiert und diese erfolgreich durchs Netz gebootet.
Es besteht auch die Möglichkeit, eine normale bootfähige Diskette mit Diskcopy auf die virtuelle Floppy zu übertragen und das Image nach dem Dismounten zu booten.
Meine Einstellungen von TFTP32D
TFTPD32 muss nicht installiert werden. Es reicht, das Programm zu starten und die nötigen Einstellungen vorzunehmen.
Eine kleine Falle ist die Einstellung 'Boot File' in der Abteilung 'DHCP server'. Hier darf man nur den Dateinamen des Bootloaders (z.B. pxelinux.0) eintragen und nicht etwa den kompletten Pfad.
Falls im gleichen Netz noch ein anderer DHCP-Server läuft, kann es zu Problemen kommen. Ggf. muss der andere DHCP-Server kurzfristig deaktiviert werden. Bei Arktur geht das mit:
/etc/init.d/dhcpd stop
Im Ordner D:\Netboot müssen sich die Dateien memdisk und pxelinux.0 aus dem Paket Syslinux und alle Images von Bootdisketten befinden. Zusätzlich muss hier noch der Ordner D:\Netboot\pxelinux.cfg angelegt werden, der die Konfigurationsdatei, z.B. D:\Netboot\pxelinux.cfg\default enthalten muss.
PXE-Boot mit modernen Mainboards
ist auch leicht möglich, wenn man die richtigen Einstellungen im BIOS findet. Bei einem Rechner mit MSI-Mainboard mit Netzwerk on Board (Phoenix-Award-Bios) musste erst die Option MAC LAN ROM unter Integrated Periphals auf enabled gestellt werden, bevor unter Boot Sequence im Menü Advanced BIOS Features die Option B2 D0 Yukon PXE auftauchte.
Ab da lief alles wie oben beschrieben.
