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:
$ ./1_buildtools.sh |& tee 1_buildtools.log
Dies betrifft in erster Linie den Cross-Compiler. Der läuft auf einem Desktop-System (x86), erzeugt aber Code für die ARM-Variante. Zum Glück baut auch der normale Desktop-Compiler diesen Cross-Compiler – der zeitaufwendigste Schritt im gesamten Ablauf. Im Netz gibt es zwar fertige Cross-Compiler, auch von der Raspberry Pi Foundation, doch berichten Anwender in Foren immer wieder von Schwierigkeiten mit diesen Tools. Deshalb baut das detLFS-Projekt die Programme lieber selbst.
Der Rechner des Autors, ein AMD Ryzen 5 2400G, glänzt nicht unbedingt mit Höchstleistungen, sondern richtet sich mit seiner integrierten GPU im Grunde auf Büroarbeit aus. Der Vierkerner weist sich per Hyperthreading gegenüber dem Betriebssystem als 8-Kern-CPU aus. Kommen alle Cores zum Zug (Aufruf von make mit der Option -j 8), benötigt der oben beschriebene Skriptaufruf etwa 18 Minuten. Rechnet nur ein Kern, dauert es 62 Minuten. Hyperthreading bringt allerdings bei dieser CPU wegen des recht kleinen CPU-Caches nicht so viel: Mit vier Kernen dauert der Compilerlauf 22 Minuten, also nur unwesentlich länger als mit voller Kernzahl.
Einmal erstellt, erfüllen die Tools ihre Aufgabe, egal wie viele verschiedene Kernel- und Systemversionen Sie ausprobieren wollen – die Laufzeit fällt also nur einmal an.
Linux entsteht
Nach diesen Vorarbeiten erstellt das nächste Skript den Kernel und das Basissystem (Listing 3). Die Kernel-Version haben Sie beim Download festgelegt, die auf die Hardware passende Variante allerdings noch nicht. Inzwischen fallen die RasPi-Modelle in drei Hardware-Kategorien. Am unteren Ende liegen der RasPi 1, die Pi-Zero-Varianten und das Compute Module 1 (CM1), am oberen Ende der RasPi 4 und RasPi 400. Dazwischen tummeln sich der RasPi 2 und 3 sowie das CM3 in einer eigenen Gruppe.
Listing 3
Basissystem erstellen
$ export target=pi2 $ ./2_basesystem.sh |& tee 2_basesystem.log
Die erste Zeile in Listing 3 sorgt für die richtige Zuordnung. Je nach Variante erzeugt das Skript ein eigenes Kernel-Image (kernel.img, kernel7.img und kernel8.img) sowie entsprechend darauf abgestimmte Module. Fehlt die Variable, erzeugt das Skript einen Kernel für die RasPi-2/3/CM3-Hardware.
Wenn Sie wie oben beschrieben beim Herunterladen nur den Branch per Variable festlegen, dann läuft das Skript ohne weitere Interaktion durch und erzeugt einen Kernel mit der Default-Konfiguration. Kopieren Sie dagegen eine .config-Datei ins detLFS-Verzeichnis, ruft das Skript make oldconfig auf. Da die Quellen üblicherweise jünger sind als die Kernel-Konfiguration und der eine oder andere Treiber hinzukam, müssen Sie in diesem Fall eine Handvoll Fragen beantworten. Die einfachste (und meist sinnvollste) Variante besteht im Annehmen des Default-Werts durch einen Druck auf die Eingabetaste.
Für die volle Kontrolle der Kernel-Konfiguration setzen Sie die Variable MENUCONFIG. Der Wert spielt keine Rolle, Hauptsache, die Variable ist nicht leer. In diesem Fall ruft das Skript make menuconfig auf, worauf sich der Kernel nach Belieben an Ihre Bedürfnisse anpassen lässt.
Wer sich die Mühe eines eigenen Kernels macht, tauscht oft auch gleich das Boot-Logo aus. Dazu kopieren Sie ein Bild in den Ordner logo/ im Wurzelverzeichnis des Projekts. Der Name muss mylogo.xxx lauten, für ein übliches JPEG also mylogo.jpg. Befinden sich Convert aus dem Imagemagick-Paket sowie die Tools aus dem Netpbm-Paket auf dem System, dann konvertiert der Skriptaufruf aus Listing 3 das Logo in das vom Kernel erwartete Format.
Auf die Karte
Nach dem Durchlauf des Skripts zum Erstellen des Basissystems liegen alle Dateien im Ordner Destination/. Das Originalprojekt kopiert die Dateien mit dem Skript 4_mksdcard.sh direkt auf eine SD-Karte. Alternativ gibt es noch 4_mkimg.sh, das wir empfehlen. Es erzeugt eine Image-Datei, die sich nur in Größe und Inhalt von den üblichen RasPi-Images unterscheidet. Die übertragen Sie dann mit den üblichen Werkzeugen auf eine SD-Karte. Beide Skripte benötigen Root-Rechte, weswegen Sie diese mit sudo starten müssen.
Verwenden Sie das Originalskript 4_mksdcard.sh, dann müssen Sie vorher mithilfe eines Editors den korrekten Device-Namen Ihres SD-Kartenlesers eintragen und den zur Sicherheit eingebauten vorzeitigen Abbruch entfernen.
