Booten von festplattenlosen Linux-Systemen

Transkript

1 Booten von festplattenlosen Linux-Systemen Stephan Rehfeld Trusted Code Heinrichstr Berlin Germany Januar 2007 Version stephan.rehfeld (-at-) trusted-code.de 1

2 Inhaltsverzeichnis 1 Danke 3 2 Revisionen 3 3 Einführung Was dieses Dokument beschreibt Was dieses Dokument nicht beschreibt Festspeicher oder Netzwerk Festspeicher Vorteile Nachteile Netzwerk Vorteile Nachteile Starten vom Festspeicher: Überlegungen Welcher Festspeicher DOC CF-Karte Welcher Second Stage Bootloader lilo GRUB GAG U-Boot XOSL Multiple Boot Manager Unbrauchbare Bootloader Welches Dateisystem ext2/ ROMFS CRAMFS JFFS SQUASHFS Welcher Bootloader funktioniert mit welchem Dateisystem Welche Verzeichnisse in die Ramdisk /tmp /var /root /home NFS Automatisches Update Starten vom Festspeicher: Realisierung 9 7 Starten über das Netzwerk: Überlegungen Welches Programm NBI PXE Protokoll des Konfigurations-Servers Welcher Second Stage Bootloader GRUB pxelinux

3 7.4 Funktionalität des Kernel Format der RamDisk Zentrale Verwaltung Starten über das Netzwerk: Realisierung 12 2

4 1 Danke Vielen Dank geht an Wolfgang Hebold, dafür das er mir die Stelle bei BESSY vermittelt hat, ohne die ich gar nicht auf dieses Thema gekommen wär.... Peter Stange, das er mich bei BESSY eingestellt hat.... Frank Höft, der mich auf die Idee gebracht hat genau diese Ausarbeiteitung zu schreiben, das er mich konsequent dazu angehalten hat L A TEXzu lernen und immer Interesse an meiner Arbeit gezeigt hat. Feeback und Diskussion zum Thema können gerne im Board unter geführt werden. 2 Revisionen 3 Einführung Einer der großen Vorteile von Linux ist, dass man es für extrem viele Zwecke verwenden kann. Linux kann für verschiendenste Arten von Servern (z.b. Mail- Server, Web-Server, File-Server, Terminal-Server), für Workstations und auch für den Embedded-Bereich verwendet werden. Embedded-Systeme sind dabei Systeme die innerhalb eines engen Aufgabenkreises arbeiten. So kann ein Embedded-System beispielweise ein Rechner sein, welcher innerhalb einer größeren Anlage Daten über eine Meßkarte sammelt, diese aufbereitet und sie an einen Server verschickt oder zur Abfrage bereit hält. Es könnte sich auch um ein System handeln auf dem ein Kleiner XServer läuft, der zu einem XClient auf einem leistungstarken Rechner verbindet und somit einen Terminal darstellt. Diese Art von Systemen kann innerhalb einer Anlagen mehrere tausen mal zum Einsatz kommen. Oft haben diese Embedded-Systeme keine Festplatten. Das könnte daran liegen das sie in so großen Stückzahlen verwendet werden das die Festplatten ein großer Kostenfaktor darstellen, das die Geräte in Umgebungen eingesetzt werden die für Festplatten äußersts schädlich sind oder der Kernel und das Betriebssystem Image zentral verwaltet werden sollen. In solchen fällen stellt sich natürlich die Frage wie man solche Systeme zum booten kriegt und wie man am besten die Verwaltung gestaltet. 3.1 Was dieses Dokument beschreibt Wie man ein System ohne Festplatte booten kann. Welche verschiedenen Wege es gibt das zu erreichen. Wo die Vor- und Nachteile der einzelnen Lösungen liegen. Welche Vorraussetzungen für die verschiedenen Lösungen erfüllt sein müssen. Wie man eine aufgebaute Struktur verwalten kann. 3.2 Was dieses Dokument nicht beschreibt Dieses Dokument beschreibt nicht detailiert wie man einen Kernel und ein Betriebssystem- Image für ein Embedded-Linux-System erstellt. 3

5 4 Festspeicher oder Netzwerk Wenn feststeht das Sie ein Embedded System brauchen welches keine Festplatte hat müssen Sie als erstes überlegen ob Sie einen andere Festspeicher verwenden wollen oder ob die Systeme ohne jeglichen Festspeicher über ein Netzwerk booten soll. Als Festspeicher stehen CF-Karten oder DOC 2000 Chips zur Verfügung. Beide basieren auf Flash speichern. Diese müssen Sie verwenden wenn Ihr System über keinen Anschluss zu einem Netzwerk verfügt, die Netzwerkkarte nicht fähig ist über ein Netzwek zu booten oder der Neustart der Komponente innerhalb einer bestimmten Zeit garantiert werden muss. Übers Netzwerk sollten Systeme gebootet werden wenn viele gleichartige Software im Einsatz sind, die öfters Änderungen unterworfen sind oder wo schnell neue Komponenten bereitgestellt werden müssen. Nachfolgend eine Aufstellung von möglichen Vor- und Nachteilen der zwei Herangehensweisen. 4.1 Festspeicher Vorteile Die Systeme sind unabhängig von einem Netzwerk und können somit autonom booten und ihre Arbeit verrichten. Nach einem Neustart booten alle Komponente innerhalb einer Zeit die garantiertbar ist. Fast der komplette RAM steht für die Anwendung zur Verfügung weil nur eine kleine Ramdisk gebraucht wird Nachteile Wenn die Software auf einer großen Anzahl von Systemen verändert werden soll kann dies einen großen Aufwand bedeuten. Vor allem wenn diese nicht an einem Netzwerk angeschlossen sind und somit eine Update-Programm über das Netzwerk laufen kann. Größere Flashspeicher sind vergleichsweise teuer. Das Betriebssystem-Image wird ein wenig komplizierte da eine kleine Ramdisk gebraucht wird da man auf keinen Fall im Betrieb auf den Flashspeicher schreiben. 4.2 Netzwerk Vorteile Die Kernel- und Betriebssystem-Images können zentral verwaltet werden. Soll ein Update vollzogen werden müssen nur die Dateien auf dem Server geändert werden und die Systeme neugestartet werden. Es muss kein Geld für Festspeicher ausgegeben werden Nachteile Wenn das Netzwerk ausfällt starten die Systeme nicht mehr. Wenn nach einem Stromausfall mehrere hundert Systeme ihren Kernel und ihr Betriebssystem-Image über den selben Server beziehen kann der Neustart wenn der Strom wieder da ist extrem lange (Stunden oder sogar Tage) dauern oder im schlimmsten Fall wegen Zeitüberschreitungen abbrechen. 4

6 Ein großer Teil des RAM wird für das Betriebssystem-Image verwendet. Es muss genau beobachtet werden sie sich der DHCP-Server beim Start eines System verhält, weil solch ein System bis zu 3 DHCP Request absetzt. 5 Starten vom Festspeicher: Überlegungen Wenn man zu dem Schluss kommt das die System von einem Festspeicher booten sollen muss man weitere Überlegungen treffen und Dinge beachten. Folgend ein Diagramm anhand dem der Bootvorgang veranschaulicht wird. 1. Beim Einschalten des Systems wird das BIOS gestartet. 2. Das BIOS startet den Second Stage Bootloader auf dem Festspeicher. 3. Der Second Stage Bootloader schreibt den Kernel in den RAM. 4. Der Second Stage Boorloader startet den Kernel. 5. Der Kernel mountet das Betriebssystem Image auf dem Festspeicher. Da man auf Flash-Speicher im Betrieb nicht schreiben darf (Sektoren kann man mal beschreiben, danach sind sie kaputt ( mal klingt zwar viel ist im Betrieb aber schnell erreicht)) muss man noch eine oder zwei Ramdisks anlegen auf die man die Verzeichnisse mountet in denen im laufenden Betrieb geschrieben wird. Das ist auf jeden fall /var und u.u. /home und /root. Für diesen Weg kann man nun folgende Entscheidungen treffen. Welcher Festspeicher soll verwendet werden. Welcher Second Stage Bootloader soll verwendet werden. Welches Dateisystem soll für den Festspeicher verwendet werden. Welche Verzeichnisse sollen in eine Ramdisk gemountet werden. 5

7 5.1 Welcher Festspeicher DOC 2000 DOC 2000 (DOC steht für DiskOnChip) ist eine von M-Systems entwickele Speicherchitechnologie die auf Flash-Speichern basiert. M-Systems ist dabei einer der Markführer. DOC 2000 ist wesentlich mehr als ein reiner Flash-Speicher. Es gibt zum Beispiel Varianten die auch bei einer Temperatur von -40 C noch funktionieren. Der Chip hat noch weitere Funktionen die weit über einen Normalen Speicher-Chip hinausgehen. Darüber hinaus ist die Technik gut dokumentiert und man hat eine sehr kompetente Firma als Ansprechpartner. Ein Nachteil ist der hohe Preis für solch einen Chip. Darüber hinaus muss das System, welches man verwendet, DOC 2000 unterstützen. Desweiteren braucht man ein Gerät um den Chip zu beschreiben CF-Karte CF-Karten (CF steht für Compact Flash) werden überwiegend als Speicher für Digitalkameras und PDAs eingesetzt. Eine CF-Karte lässt sich jedoch mit einem Preiswerten Adapter an einem normalen IDE-Bus betreiben. Das BIOS erkennt diese Karte dann als Festplatte und bootet von ihr. CF-Karten sind preiswert, da es sich um Massenware handelt. 5.2 Welcher Second Stage Bootloader lilo Lilo steht für Linux Loader und war lange Zeit der standard Boot-Loader für Linux Systeme. Er ist einfach aufgebaut und einfach zu konfigurieren. Beim installieren von lilo ist jedoch vorsicht geboten. Mann kann sich ohne weiteres den MBR des Entwicklungssystems überschreiben. Wenn LiLo im MBR des Festspeichers installiert wird merkt er sich in welchen Blöcken der Kernel liegt und die er somit laden muss. Die macht bei komprimierten Dateisystemen probleme. Desweiteren kann man nicht einfach das Image mounten und den Kernel austauschen das LiLo den Kernel nicht mehr findet. Nach einem Austausch muss lilo erneut im MBR installiert werden. Lilo sollte verwendet werden wenn das Sytem einfach nur gestartet werden soll und keine weiteren Funktionalitäten gebraucht werden. Projekthomepage: GRUB GRUB steht für Grand Unified Bootloader, ist ein sehr leistungsfähiger Boot-Loader und der größte Konkurent von lilo. So kann GRUB konfiguriert werden einzelne Konfigutationen nur über Eingabe eines Passwords zu starkten. Darüber hinaus muss der Kernel oder die Ramdisk nicht auf dem System liegen sondern kann über einen TFTP Server bezogen werden. GRUB beinhaltet Treiber für verschiedene Dateisysteme, somit muss, wenn der Kernel ausgetauscht wird, GRUB nicht erneut installiert werden, wie es bei lilo der Fall ist. Projekthomepage: GAG GAG steht für Gestor de Arranque Graffico, was Spanisch ist für Grapfical Boot Manager. Wie aus dem Namen zu schließen ist, bietet dieser Boot-Loader ausschließlich in Grafisches Interface an. Er eignet also nicht für Systeme die keine VGA fähige Grafikkarte haben. Die Installation des Bootloaders findet ausschließlich im MBR der Festplatte statt. Dort wird auch die Konfiguration gespeichert. Das bedeutet 6

8 das keine eigene Partition benötigt wird. Projekthomepage: U-Boot U-Boot steht für Universal Bootloader und ging aus dem PPCBootloader hervor. Inzwischen ist er jedoch für viele andere Architekturen verfügbar. U-Boot wurde speziell für Embedded Systeme entwickelt. Projekthomepage: XOSL XOSL steht für Extended Operating System Loader. Dieser Boot-Loader wurde entwickelt um besonders benutzerfreundlich zu sein. Er ist einfach zu verwenden und zu installieren. Er bietet eine grafische Oberfläche und sogar ein Maussteuerung. Das Projekt wird seit einigen Jahren nicht mehr weitergeflegt, da die letze Version keine Wünsche mehr offen ließ. Projekthomepage: Multiple Boot Manager Der Multiple Boot Manger ist im Gegensatz zu den anderen Boot-Loader nicht Open Source sondern Freeware. Er bietet ebenfalls die Möglichkeit eine grafische Oberfläche beim Booten bereit zu stellen. Projekthomepage: e.html Unbrauchbare Bootloader syslinux, Loadlin, BootX 5.3 Welches Dateisystem ext2/3 Das ext2 Dateisystem ist seit vielen Jahren der Standard für Linux-Systeme. Es ist einfach aufgebaut und ist mit nahezu allen Linux-Systemen kompatiebel. Die unterstützung im Kernel für dieses Dateisystem ist 44kB groß. Ein Nachteil ist das ext2 nicht per-se read-only ist. Man muss beim mounten also darauf achten das auf die Partition nicht geschrieben werden kann da dies früher oder später zu beschädigten Sektoren auf dem Flash-Speicher führen würde. Das ext3 Dateisystem stellt eine Erweiterung von ext2 um Journaling funktionen dar. Auf diese kann man bei einem sich nicht ändernden Image getrost verzichten ROMFS ROMFS ist ein sehr einfaches Dateisystem welches dafür entwickelt wurde in InitRDs verwendet zu werden. Die Unterstützung für dieses Dateisystem beansprucht nur 4kB. Ein Image mit mit Hilfe des Programms genromfs erstellt. Das erstellte Dateisystem ist immer read-only, d.h. versehentliches Schreiben wird von Anfang an verhindert CRAMFS CRAMFS steht für Compressed ROM File System. Es bietet also ein komprimiertes Dateisystem für ROM Images. Eine Datei innerhalb eines solchen Images darf aber 7

9 nur maximal 16 MB groß sein. Die Gesamtgröße des Images ist auf 256 MB limitiert. Erzeugt wird das Image mit Hilfe des Programm mkcramfs JFFS2 JFFS2 steht für Journalling Flash File System, version 2. Dabei handelt es sich um ein Dateisystem was auch schreibenden Zugriff auf Flash Speicher zulässt. Da ein Flash-Speicher nur eine begranzte Anzahl von Schreibzyklen funktioniert versucht JFFS2 diese gleichmäßig auf den Flashspeicher zu verteilen SQUASHFS SQUASHFS ist wie CRAMFS ein komrimiertes read-only Dateisystem. Im gegensatz zu CRAMFS kann das Image und eine Datei im Image wesentlich größer sein (bis zu 4GB). Im gegensatz zu allen anderen vorgestellen Dateisystem wird SQUAS- HFS nicht mit den Standard-Kernel-Sourcen ausgeliefert. Der Kernel muss somit gepatcht werden bevor er SQUASHFS unterstützt. 5.4 Welcher Bootloader funktioniert mit welchem Dateisystem 5.5 Welche Verzeichnisse in die Ramdisk Falls sie sich für eine Dateisystem entscheiden welches das Schreiben generell ausschließt müssen sie einige Verzeichnisse, in die auf jedenfall geschrieben wird, in eine Ramdisk verschieben /tmp Für das /tmp Verzeichnis bietet der Kernel von hause aus das tmpfs. Dabei handelt es sich um ein Spezielles Dateisystem was nur im Speicher existiert und daher sehr schnell ist. Im Gegensatz zur traditionellen Ramdisk ist die Größe des tmpfs nicht statisch. Wenn eine Datei ins tmpfs geschrieben wird, wird das tmpfs entsprechend erweitert, wird eine Datei gelöscht wird das tmpfs verkleinert /var Unter /var/ liege die Dateien die vom Applikationen im Beitrieb verändert werden. Es hängt stark von den Anwendungen ab wie groß die Ramdisk für dieses Verzeichnis sein muss /root Das Verzeichnis /root ist das Home-Verzeichnis des Benutzers Root. Wenn sich der Benutzer Root niemals auf dem System einloggt, kann man auf dieses Verzeichnis verzichten. Wenn man ein Home- und ein Root-Verzeichnis auf dem System braucht empfielt es sich die Datei /etc/passwd so anzupassen das dieses Verzeichnis unter /home/root liegt. Somit spart man sich eine Ramdisk /home Im Verzeichnis /home werden die Dateien eines Benutzer abgelegt wie zum Beispiel deren Konfiguration für die Shell und andere Applikationen. Wie groß die Ramdisk für dieses Verzeichnis sein muss hängt natürlich wieder von der Applikation ab. 8

10 5.5.5 NFS Es ist auch möglich die Verzeichnisse /var, /root und /home über einen NFS-Server bereitzustellen. In diesem Fall mountet das System diese Verzeichnisse beim Hochfahren. Der Vorteil ist das mehr Arbeitsspeicher auf dem System zur Verfügung steht. Dafür ist das System nicht mehr autarc und vom Netzwerk bzw. vom Server abhängig. Sollte der NFS-Server nicht erreichbar sein kann dies zu schwere Fehlern führen. Es gibt jedoch durchaus Anwendungsfälle in denen das Mountern über NFS Sinn macht, zum Beispiel wenn man einen X-Terinal zur Verfügung stellen will. 5.6 Automatisches Update Stellen Sie sich nun vor sie haben eine Struktur aufgebaut wo mehrere hundert Systeme mit Flash-Speichern starten und ihre Aufgaben übernehmen. Nach einigen Monaten betrieb stellt sich etwas heraus was ein Update des Systems zwingend notwendig macht. Dies könnte zum Beispiel ein Sicherheitsloch in einer der verwendeten Applikationen sein, ein Bug im Kernel, Applikationen oder einer Bibliothek, die zum Absturz, oder noch Schlimmer, zu falschen Berechnungen führen kann. In schlimmsten Falle müssen Sie oder mehrere Angestellte in Ihrer Firma durch die Systemräume, Büros oder der betriebenen Anlage gehen und jedes System ausbauene, den Flashspeicher ausbauen, neu flashen und alles wieder einbauen. Das ist nicht nur eine sehr monotone Arbeit, es kostet auch noch richtig Geld, da jeder sicherlich was produktiveres tun könnte. Wäre es dann nicht wünschenswert, das man an einer zentralen Stelle einträgt das beim nächsten start alle Systeme einer bestimmten Art ihr Image und ihren Kernel selber neu flashen anschließend neu starten und dann auf dem aktuellen Stand sind? Dies ist über eine gemischte Lösung aus starten über ein Netzwerk und festspeicher möglich. Dabei holt sich das System zuerst die den Bootloader und die Konfiguration des Bootloaders über das Netzwerk. In der Konfiguration des Bootloaders, die auf einem zentralen Server liegt, ist dann für den start ein spezielle Linux-Image eingetragen, das beim starten des Flash-Speicher neu flasht. Anschließend kann das System auf dem Flashspeicher gestartet werden. 6 Starten vom Festspeicher: Realisierung 7 Starten über das Netzwerk: Überlegungen Wenn man zu dem Schluss kommt das die System über ein Netzwerk booten sollen muss man weitere Überlegungen treffen und Dinge beachten. Folgend ein Diagramm anhand dem der Bootvorgang veranschaulicht wird. 9

11 1. Beim Einschalten des Systems wird das BIOS gestartet. 2. Das BIOS ruft ein in einem ROM gespeichertes Programm auf. 3. Das Programm ruft Konfigurationen von einem Konfigurations-Server im Netzwerk ab. 4. Das Programm lädt einen Second Stage Bootloader von einem FTP-Server. 5. Das Programm schreibt den Second Stage Bootloader in den RAM und startet ihn. 6. Der Second Stage Bootloader erfragt seine Konfiguration von einem Konfigurations- Server ab und lädt u.u. eine Konfigurationsdatei. 7. Der Second Stage Bootloader lädt Kernel und Ramdisk von einem TFTP- Server und schreibt diese ins RAM. 8. Der Second Stage Bootloader startet den Kernel im RAM. 9. Der Kernel mountet die RamDisk. 10. Das System startet Daemons und die Shell. Auch für die Methode müssen mehrere Entscheidungen getroffen werden: Welches ist das Programm welches vom BIOS gestartet wird? Welches Protokoll soll der Konfigurations-Server sprechen? Welcher Second Stage Bootloader soll verwendet werden? Was muss der Kernel können? Welches Format soll die RamDisk haben? 10

12 7.1 Welches Programm Was bisher als Programm bezeichnet wurde ist die Software, die die Netzwerkkarte des Systems startfähig macht. Diese befindet sich meistens auf einem ROM-Chip auf der Netzwerkkarte, dem sogenannten BootROM. Viele preiswerte Netzwerkkarten haben keinen BootROM-Chip, dieser lässt sich jedoch nachrüsten. Die Software auf dem ROM-Chip kann aus verschiedenen Quellen stammen. In den meisten Fällen stellt der Hersteller der Netzwerkkarte diese Bereit. Diese sollte in aller Regel auch verwendet werden. Wenn es für die Netzwerkkarte kein ROM vom Hersteller gibt, gibt es u.u. komerzielle Firmen die Boot ROMS für Netzwerkkarten herstellen. Darüber hinaus gibt es OpenSource Projekte die ROMS für Netzwerkkarten erstellen. Darüber hinaus gibt es zwei Protokolle die beim starten verwendet werden können: NBI NBI steht für Network Bootable Image. Dabei handelt es sich um ein recht altes Format, welches sich um Systemimages legt und diese über das Netzwerk startbar macht. Mit Hilfe von mknbi würde sich auch Images herstellen lassen, welche ohne Second Stage Bootloader starten. Jedoch müsste man in diesem Fall auf den Bootloader und dessen Konfigurationsmöglichkeiten verzichten PXE PXE steht für Preboot Execution Environment. Es ist ein von Intel und Symsoft entwickelter Standard, der sich damit beschäftigt wie Systeme ohne Massenspeicher zu starten sind. PXR hat den großen Vorteil, das es dem darin gestarteten Bootloader ein einheitliches API zur Verfügung stellt. Die meisten modernen Netzwerkkarten, Etherboot 5.4 sowie VmWare unterstützen PXE. 7.2 Protokoll des Konfigurations-Servers Als Protokolle für den Konfigurations-Server stehen BOOTP, Bootstrap Protocol, und DHCP, Dynamic Host Configuration Protocol, zur Verfügung. DHCP ist eine Erweiterung von BOOTP und somit wesentlich moderner. Eigentlich ist DHCP immer der Vorzug zu geben. BOOTP sollte nur verwendet werden wenn in dem Netz wo die Systeme laufen sollen kein DHCP-Server vorhanden ist und auch keiner installiert werden soll. 7.3 Welcher Second Stage Bootloader Als Second Stage Bootloader stehen GRUB und pxelinux zur Auswahl GRUB GRUB wurde bereits in Kapitel auf Seite 6. Von GRUB lassen sich Images für NBI und PXE erstellen. GRUB muss jedoch bei NBI und PXE für die entsprechende Netzwerkkarte kompiliert werden. Welche Konfigurationsdatei verwendet werden soll wird GRUB über den Konfigurations-Server mitgeteilt pxelinux Pxelinux ist ein Bootloader der nur mit PXE fähigen Netzwerkkarten zusammenfunktioniert (oder Etherboot ab Version 5.4). Pxelinux muss nicht für eine bestimmte Netzwerkkarte kompiliert werden. Somit muss auf dem TFTP-Server nur ein 11

13 Image vorgehalten werden. Desweiteren wird pxelinux nicht über den Konfigurations- Server mitgeteilt welche Konfigurations-Datei verwendet werden soll sonder die Konfigurationsdateien liegen Hirarchisch nach IP Adresse im selben Verzeichnis wie das Image. Pxelinux ist aus Syslinux heraus entstanden. 7.4 Funktionalität des Kernel Der Kernel muss RamDisks, InitRDs sowie das Dateisystem der RamDisk unterstützen. 7.5 Format der RamDisk Es steht einem eigentlich nahezufrei welches Dateisystem man für die RamDisk verwendet. Ich empfehle ext2 zu verwendet. Ext2 bietet alle grundlegenden Funktionen unterstützt zur Not große Dateien und eine große RamDisk. Auf das in diesem Fall überflüssige Journaling wird verzichtet. (Journaling ist überflüssig, da falls wärend einer Operation der Strom ausfällt oder ähnliches passiert, das RamDisk sowieso neu vom Server geladen wird). 7.6 Zentrale Verwaltung 8 Starten über das Netzwerk: Realisierung 12