© gstockstudio / 123RF.com

Mithilfe von Linux from Scratch erstellen Sie eine für Ihre Zwecke maßgeschneiderte Distribution – etwa als Ablösung für ein bald nicht mehr unterstütztes CentOS.

Nicht zuletzt aufgrund des Rummels um die Abkündigung des Urgesteins CentOS 8 für Ende 2021 und daraus entstehenden Diskussionen um Alternativen wie Rocky Linux [1] mag sich so mancher überlegt haben, ob es nicht möglich wäre, ein eigenes Linux zu bauen. Dieser Artikel erklärt auf der Basis von Linux from Scratch (LFS), wie das funktioniert.

Bei Linux from Scratch [2] und Beyond Linux From Scratch (BLFS [3]) handelt es sich um online verfügbare Anleitungen, die das Kompilieren und Zusammenstellen eines eigenen Linux-Systems direkt aus frei verfügbaren Quellen Schritt für Schritt beschreiben. Im Folgenden verwenden wir die Abkürzung LFS sowohl für die Dokumentation als auch für das daraus entstehende Linux-System. LFS und BLFS werden meist zweimal im Jahr aktualisiert, im März und im September.

Gerard Beekmans, der Autor von LFS, begann 1998, sich mit Linux zu beschäftigen. Nach Einsatz diverser Distributionen reifte bei ihm die Erkenntnis, dass es für ihn kein “one size fits all” gab und er ein eigenes System benötigte. Open Source bot ihm per definitionem die Möglichkeit dazu. Er begann zu kompilieren und sich mit Compile-Time-Errors sowie zirkulären Abhängigkeiten auseinanderzusetzen. Die gesammelten Erfahrungen, die er mit der Linux-Community teilte, stießen auf so breites Interesse, dass daraus das Projekt LFS entstand.

Neben LFS gibt es eine Reihe an Linux-Distributionsbaukästen, von denen sich die meisten auf den Embedded-Bereich spezialisieren und deren bekanntester Vertreter BitBake [4] aus dem Yocto-Projekt ist. Daneben gibt es noch Linux Target Image Builder [5], OpenWrt [6] und Scratchbox [7].

LFS versucht soweit wie möglich, gängigen Standards zu folgen. Dazu gehören POSIX.1-2008 [8], das eine Betriebssystemschnittstelle samt Environment zu Portabilitätszwecken definiert, der Filesystem Hierarchy Standard FHS [9] in Version 3.0 sowie die Linux Standard Base LSB [10] in Version 5.0 (2015). Letztere definiert vier teils kontrovers diskutierte Standards für Core, Desktop, Runtime Languages und Imaging, die LFS schon aufgrund seiner minimalen Softwareausstattung nur in Teilen umsetzen kann. Aber man hat ja die Trümpfe in der Hand, das bei Bedarf selbst zu ändern.

Folgen Sie der Anleitung, erhalten Sie ein minimales Linux-System (Abbildung 1) mit Ext4-Dateisystem, Grub 2.04, Kernel 5.10.17, Bash 5.1, GCC 10.2, Perl 5.32.1, Python 3.9.2 und Vim 8.2 (Stand LFS v10.1 von März 2021). Sie haben die Wahl zwischen LFS mit SysVinit [11] und mit Systemd und D-Bus [12]. Diese Artikelserie behandelt letztere Variante. Mit Systemd erhält LFS nicht nur das modernere Init-System, sondern auch einen DHCP- und NTP-Client sowie andere Kleinigkeiten, die in der SysVinit-Variante erst in BLFS behandelt werden.

Abbildung 1: LFS in der Grub-Auswahl. Der Bootloader gehört zur Minimalausstattung des selbstgebauten Linux.

Vorbemerkungen

Mit dem Herunterladen der Kernel-Quellen und dem Anwerfen des C-Compilers ist es allerdings nicht getan. LFS splittet das Erstellen eines Linux-Systems in drei relevante Teile (Abbildung 2): die Konfiguration eines Build-Hosts (Part II, Abschnitt 2 bis 4), das Bauen einer Cross-Toolchain (siehe Kasten “Cross-Compilation erklärt”) und nur temporär benötigter Tools (Part III, Abschnitt 5 bis 7) und erst daran anschließend das Erstellen des eigentlichen LFS-Systems (Part IV, Abschnitt 8 bis 11). Die Abschnitte 2 bis 11 beschreiben wir hier zusammengefasst und referenzieren sie so auch in den Shell-Kommentaren im nächsten Teil der Artikelserie.

Abbildung 2: Die drei Teile des Build-Prozesses von LFS.

Der Build-Prozess basiert auf dem Prinzip des Cross-Kompilierens: Ein Cross-Compiler produziert Code für andere Maschinentypen, dient also normalerweise dazu, Code für andere Systemarchitekturen zu übersetzen. Auf Ihrer Build-Maschine ist das theoretisch nicht nötig, da Sie mit hoher Wahrscheinlichkeit auf x86_64 für x86_64 bauten. LFS soll aber auf jeden Fall von hineingelinkter Software des Build-Hosts freibleiben, was cross-kompilierte Software garantiert – daher der Aufwand.

Um die Vorgehensweise zu verdeutlichen, nimmt die LFS-Dokumentation drei Hosts mit jeweils unterschiedlichen Architekturen an. Host A besitzt einen Compiler für die eigene Architektur. Der Host ist langsam und seine Kapazitäten begrenzt. Host B besitzt keinen Compiler, ist aber schnell und gut ausgestattet. Er soll Software für Host C produzieren. Host C mit nochmals anderer Architektur besitzt ebenfalls keinen Compiler und ist klein und langsam.

Dieses Szenario erfordert zwei Cross-Compiler: Cross-Compiler A und Cross-Compiler B. Auf Host A baut der Compiler den Cross-Compiler A, der wiederum den Cross-Compiler B erstellt. Letzterer kommt auf Host B zum Einsatz, um den Compiler C sowie alle Programme für Host C zu bauen. Auf Host B lassen sie sich aber nicht testen. Deswegen rebuildet und testet auf Host C der Compiler C sich selbst.

Auf einem Host

Damit für LFS das Cross-Kompilieren auf demselben Host funktioniert, müssen Sie das bekannte Vendor-Triplet »x86_64-pc-linux-gnu« (das heutzutage immer vier Komponenten enthält) in »LFS_TGT« behutsam anpassen, um dem Compiler verschiedene Architekturen vorzugaukeln. Anschließend baut auf dem Build-Host der Compiler-Build-Host zunächst den Cross-Compiler-Build-Host, der wiederum den Compiler-LFS erstellt. In der LFS-Chroot auf dem Build-Host rebuildet und testet sich der Compiler-LFS dann selbst und steht danach zum Einsatz bereit.

Für LFS müssen Sie mithilfe des Cross-Compilers nicht nur den C-Compiler, sondern auch die Glibc und die Libstdc++ übersetzen. Das Problem dabei: Der zu erstellende C-Compiler baut intern auf die Libgcc, die wiederum gegen die Glibc gelinkt sein muss – und die gibt es noch nicht.

Um diese zirkulären Abhängigkeiten zu umgehen, erstellen Sie zunächst eine Minimalversion des Cross-Compiler-Build-Host, die gerade dazu taugt, eine vollwertige Glibc sowie eine minimal funktionsfähige Libstdc++ zu übersetzen. Die Libstdc++ wird später in Chroot nochmals gebaut, diesmal komplett. Weitere Details nennt die LFS-Dokumentation.

Beyond LFS

Anders als dem LFS-Buch folgt man der BLFS-Anleitung übrigens nicht linear, sondern sucht sich aus über 50 Abschnitten diejenigen aus, die das eigene Linux in die gewünschte Richtung bringen. Da BLFS von Security über Virtualisierung bis hin zu Desktop-Umgebungen so ziemlich alle Bereiche sowie die gängigsten Softwarepakete abhandelt, verwundert es nicht, dass es ungefähr drei Mal so umfangreich wie LFS ist.

Nach Anleitung

Dieser Artikel fasst die LFS-Anleitung zusammen und erklärt zunächst die Prinzipien und die Vorgehensweise. In der nächsten Folge der Artikelserie finden sich dann die Kommandos, die Sie (soweit wie möglich) per Copy & Paste auf einem Build-Host unter CentOS 8 ausführen, um in einem Rutsch zum ersten selbst gebauten Linux zu kommen. Die Anleitung verfrachtet »/home« darüber hinaus auf eine eigene Partition und bereitet die LFS-Disk auf ein autarkes Booten vor. Das Bauen nimmt reichlich Zeit in Anspruch: Mit der im der nächsten Folge beschriebenen Test-VM unter KVM auf einem Rechner mit Core i7 10th Gen und NVMe-SSD dauert der Build auch mit abgeschalteten Tests mehrere Stunden.

Möchten Sie nach dem Build, dem Booten von LFS und den ersten Tests tiefer in die Materie eintauchen, verweisen wir dazu auf die vorbildliche Originaldokumentation. Da http://linuxfromscratch.org so seine Mühen mit Geschwindigkeit und Erreichbarkeit hat, empfiehlt sich, dafür einen der Mirror-Server zu nutzen.

Vorzüge …

Man kann sich freilich fragen, ob der Bau eines eigenen Linux-Systems lohnt, wo man doch aus einer breiten Masse an Distributionen auswählen kann. Das Team um den LFS-Projektleiter Gerard Beekmans hat darauf mehrere Antworten.

Zum einen möchte das Projekt zeigen, wie man eine Distribution baut, aus welchen Komponenten sie besteht, wie diese zusammenspielen und wie sie voneinander abhängen. Wer will, kann LFS auch als Ausgangspunkt für eigene Weiterentwicklungen nutzen.

Zum anderen erhält man mit LFS ein aktuelles, funktionierendes und sehr kompaktes Linux-System, das nicht viel mehr umfasst als den Kernel und einige Werkzeuge. Die Doku berichtet von einem auf LFS laufenden Apache mit einer Gesamtgröße von 8 MByte und weniger, was besonders für Embedded Systeme von Interesse sein kann.

Wer selbst baut, bleibt zudem extrem flexibel. Mit LFS erhalten Sie quasi den Rohbau eines Hauses, das Sie ganz nach Geschmack individuell vom 1-Zimmer-Apartment bis zur Luxusvilla gestalten. LFS lässt sich bei Bedarf komplett auditieren, und – vielleicht noch wichtiger: Sie haben das Management aller Security-Patches selbst in der Hand. Und zu guter Letzt: LFS ist einfach cool.

… und Nachteile

Um die Erwartungen etwas zu dämpfen: Im produktiven Betrieb lässt sich mit LFS nicht komfortabel arbeiten. Ein SSH-Daemon fehlt ebenso wie Sudo, Wget oder Parted. Kein LVM verwaltet das Dateisystem, der Netzwerk-Stack ist alles andere als komplett. BLFS liefert das zwar als Advanced Topic nach, ein Paketmanager kommt aber im ganzen Projekt nicht zum Einsatz.

Sie müssen Ihre eigene Distribution daher über Downloads und Kompilieren selbst aktuell halten und regelmäßig mit Updates und Sicherheitsaktualisierungen versorgen. Wer auf Slackware & Co. zu Hause ist, kann LFS jedoch auch in dieser Hinsicht erweitern, indem er einen Manager wie Pacman oder GNU Stow [13] hinzufügt oder eine Strategie wie den Package-User-Ansatz [14] verfolgt. Generell gilt bei LFS: Linux-Kenntnisse werden nicht vermittelt, sondern vorausgesetzt.

Von einer klassischen Linux-Distribution bleibt LFS ohnehin weit entfernt. Dazu fehlen ihm Merkmale wie eine aktive User Community, QA-geprüfte Pakete inklusive Errata und Patch-Management, ein umfangreiches Mirror-Netzwerk, zuständige und kontaktierbare Entwickler und Annehmlichkeiten wie ein Wiki, ein IRC-Chat, Mailing-Listen, Foren, Bugtracker oder eine FAQ.

Ob sich neben dem Lerneffekt auch ein praktischer Nutzen findet, hängt also wie immer von den eigenen Anforderungen ab. Mit LFS bekommen Sie jedenfalls ansatzweise ein Gefühl dafür, welche Investition an Zeit und Know-how im Linux-Kernel, in Open-Source-Software und in allen Linux-Distributionen steckt. (jcb/jlu)