Freie Software steht jedermann im Quelltext zur Verfügung, doch im Alltag greifen die meisten Anwender lieber auf fertige Distributionen zurück. Es gibt aber gute Gründe, sein Linux selbst zu bauen.
Das Projekt Linux From Scratch oder kurz LFS gibt es schon seit über zwanzig Jahren [1]. Es liefert als Ergebnis nicht etwa Software, sondern eine detaillierte Anleitung, wie man ein lauffähiges Linux-System aus den Quelltexten selbst erstellt. Doch warum sollte man so etwas tun? Auf diese Frage gibt es im Prinzip drei Antworten: Man ist Masochist mit zu viel Zeit, ein Projekt stellt ganz spezielle Anforderungen, oder man will lernen, wie Linux grundlegend funktioniert. Diese Antworten gelten auch für das hier vorgestellte Projekt detLFS [2] von Thomas Dettbarn.
Im Unterschied zur reinen Lehre von LFS macht detLFS aber Interessierten das Leben viel leichter, denn das Projekt stellt statt einer Anleitung einen Satz Skripte bereit. Die erzeugen fast ohne Interaktion ein lauffähiges, minimales Linux-System für den Raspberry Pi. Als Voraussetzung benötigen Sie ein Desktop-Linux mit den üblichen Build-Tools wie Compiler und Make sowie ImageMagick/Netpbm für ein eigenes Kernel-Logo. Diese Tools finden sich auf einem üblichen Entwicklerrechner aber sowieso; im Zweifel installieren Sie sie über die Paketverwaltung nach. Typischerweise gibt es dafür Pseudopakete, die build-essentials oder ähnlich heißen.
Allerdings ist es mehr als langweilig und im Grunde sogar sinnlos, einfach das Projektarchiv herunterzuladen und die Skripte zu starten, denn mit dem erzeugten Minimalsystem gewinnt niemand einen Blumentopf. Viel wichtiger ist das Verständnis für den Prozess und das Wissen, wie Sie ihn an Ihre eigenen Bedürfnisse anpassen.
Wie Linux tickt
Ob auf einem Raspberry Pi oder auf einem Supercomputer: Linux tickt im Prinzip immer gleich. Zuerst startet die Hardware den Kernel vom Datenträger. Dieser Teil hängt stark von der Plattform ab. Ohne eine Firmware, im Desktop-Bereich auch als BIOS bekannt, geht hier nichts.
Nach dem Start initialisiert der Kernel seine Subsysteme und Treiber. Anschließend übergibt er die Kontrolle an den Init-Prozess, indem er das Programm /sbin/init mit der ID 1 startet. Auf modernen Linux-Systemen übernimmt der Systemd-Prozess kurz danach diese ID. Das Init-Programm startet dann nach und nach alle Anwendungsprogramme und Prozesse, die ein System ausmachen. Der Kernel selbst bleibt als stummer Diener im Hintergrund und springt immer ein, wenn ein Programm Zugriff auf Ressourcen braucht, etwa bei einem Programmstart oder für das Lesen einer Datei (Abbildung 1).
Abbildung 1: Die gestarteten User-Prozesse interagieren mit dem Kernel.
Ein Minimalsystem besteht also aus drei Komponenten: der Firmware, einem Kernel und zumindest einem Init-Programm. Für einen RasPi, dessen einzige Aufgabe darin besteht, etwas zu steuern und zu schalten, genügt das unter Umständen schon. Ganz so minimal geht es bei detLFS nicht zu: Hier gibt es neben dem Init-Programm zumindest noch abgespeckte Versionen der unter Linux üblichen Standardprogramme wie Ls, Cp und so weiter.
Um mit wenig Aufwand ein eigenes Minimalsystem zu erstellen, besorgt ein Skript zunächst alle notwendigen Programmquellen. Anschließend erzeugt ein zweites einen Cross-Compiler samt Begleitprogrammen. Den benötigen Sie, weil Sie auf einem x86-System einen lauffähigen Kernel und Anwendungsprogramme für die ARM-Architektur des RasPi erzeugen wollen. Den schematischen Ablauf zeigt Abbildung 2. Alle Skripte sollten innerhalb einer Sitzung ablaufen; andernfalls müssen Sie die Export-Befehle entsprechend wiederholen, die nur innerhalb einer Sitzung gelten.
Abbildung 2: Der schematische Ablauf des Erstellens eines mit detLFS generierten Systems.
Besser geht immer
Von den Originalskripten bietet der Autor dieses Artikels auf Github [3] einen Fork an. Hauptgrund dafür sind diverse Fehlerkorrekturen sowie Optimierungen, die das Herunterladen sowie den Bau des Systems deutlich beschleunigen. Darüber hinaus unterstützt der Fork alle Hardware-Varianten des RasPi, nicht nur die Versionen 2 und 3. Die Software erhalten Sie mit den Befehlen aus Listing 1.
Listing 1
Installation der Skripte
$ git clone https://github.com/bablokb/pi-detLFS $ rm -fr /data/projekte/detLFS $ cp -a pi-detLFS/detLFS /data/projekte $ cd /data/projekte/detLFS
Die letzten beiden Befehle kopieren das Verzeichnis mit den eigentlichen Skripten in ein geeignetes Projektverzeichnis und wechseln dorthin. Liegt es auf einem mit XFS oder Btrfs formatierten Dateisystem, laufen später alle Skripte nicht nur schneller, sie benötigen auch weniger Platz. Das liegt daran, dass diese Dateisysteme beim Kopieren von Dateien nur die Referenzen kopieren, nicht die Datenblöcke.
Nach diesen Vorbereitungen starten Sie die Befehle aus den ersten beiden Zeilen von Listing 2. Die optionale erste Zeile legt den Kernel-Zweig fest, den das Skript aus dem Repository holt. Dort gibt es diverse Entwicklungslinien in getrennten Zweigen (Branches). Ohne den Export-Befehl verwendet das Skript den aktuellen Default-Zweig. Statt den Branch manuell zu setzen, lässt sich alternativ auch die Kernel-Konfigurationsdatei .config eines laufenden Raspberry Pi in das detLFS-Verzeichnis kopieren (Listing 2, Zeile 4 und 5).
Listing 2
Download und Konfiguration
$ export BRANCH=rpi-4.19.y $ ./0_getit.sh |& tee 0_getit.log [...] $ sudo modprobe configs $ zcat /proc/config.gz > .config
Das Skript 0_getit.sh lädt ungefähr 1,1 GByte an komprimierten Quellen herunter, die ausgepackt etwa das Doppelte ergeben. Für jeden Download legt das Skript im Verzeichnis Downloads/ eine Datei nach dem Muster .detlfs.xxx an, etwa .detlfs.kernel (Abbildung 3). Wollen Sie etwas erneut herunterladen, etwa weil Sie eine andere Kernel-Version ausprobieren möchten, löschen Sie zuvor die entsprechende Datei. Kontrollieren Sie auf jeden Fall nach dem Ausführen die Protokolldatei 0_getit.log – das gilt analog auch für alle weiteren Schritte.
Abbildung 3: Das Verzeichnis Downloads/ nutzen die detLFS-Skripte als Zwischenspeicher für alle benötigten Dateien.
Im Verzeichnis Downloads/ landen nur die heruntergeladenen Quellpakete. Mit Ausnahme des Kernels handelt es sich dabei um Archive. Das Skript kopiert beziehungsweise entpackt die Quellen sofort in das Verzeichnis Sources/. Daraus bedienen sich dann die folgenden Skripte.
Werkzeugkasten
Der zweite Schritt im Ablauf erzeugt die Werkzeuge, die die darauffolgenden Skripte benötigen:
