Der Weg zur eigenen Minidistribution Klein, stark und selbst gebraut Bernhard Bablok

Jeder noch so altersschwache Computer kann als Printserver oder Router im Büro- oder Heimnetz mit Linux gute Dienste leisten - so heißt es jedenfalls. Im Prinzip ist das auch richtig. Wer aber für seinen 486er eine moderne Distribution kauft, hat ein Problem. Das erforderliche Abspecken und Konfigurieren verlangt eine Menge Spezialwissen - falls man überhaupt so weit kommt. Wenn schon die Installation wegen Speichermangels nicht abgelehnt wird, dann scheitert sie vielleicht an einer zu kleinen Festplatte.

Auch bei Embedded Devices sind Speicherplatz sparende Distributionen unerlässlich. Moderner Flash-Speicher hat zwar eine vergleichsweise hohe Speicherkapazität, der sollte aber vor allen Dingen dem Anwendungsprogramm und den Benutzerdaten zustehen und nicht dem Betriebssystem. Ein Basissystem von der Stange ist also für beide Fälle nicht geeignet.

Doch mit geringem Aufwand ist ein System nach Maß zusammengestellt. Dass ein lauffähiges Linux-System einen Kernel benötigt, ist eine Trivialität. Was mindestens sonst noch dazugehört, ist dagegen nicht jedem bekannt. Ein kleines Experiment weist den Weg. Dazu wird ein Kernel auf eine leere Diskette kopiert:

# cp /boot/vmlinuz /dev/fd0
# rdev /dev/fd0 /dev/fd0

Der Kernel kann je nach Ausgangssystem auch anders heißen. Der letzte Befehl wird später näher erläutert, er dient hier nur dazu, reproduzierbare Ergebnisse zu haben.

Aus dem Nichts

Danach wird ein Rechner damit gebootet. Die Frage nach der Root-Floppy erhält einfach eine Eingabe als Antwort. Die Abbildung 1 (hier im X86-Emulator Bochs[1]) zeigt das Ergebnis. Nachdem der Kernel während des Bootens alle Subsysteme initialisiert hat, übergibt er die Kontrolle an den Userspace. Dazu ist als erster Schritt das Root-Filesystem zu mounten. Dieses System heißt so, weil sich das Wurzelverzeichnis »/« hier befindet. Ohne Root-Filesystem kommt es zu einem bei normalen Linux-Systemen glücklicherweise recht seltenen Ereignis - zu einer Kernel Panic. Das System steht dann also still, noch bevor es richtig gestartet ist.

Damit ist das Root-Filesystem neben dem Kernel die zweite grundlegende Komponente eines Linux-Systems. Es besteht aus einer Verzeichnishierarchie und einer Reihe von notwendigen Dateien und befindet sich entweder auf einem Datenträger (in den meisten Fällen ist das eine Diskette oder eine Festplattenpartition) oder auf einer RAM-Disk, die einen Datenträger im Speicher simuliert. Diese Art von Datenträgern heißt Blockdevice.

Abbildung 1: Ein fehlendes Root-Filesystem führt zur Kernel Panic.

Das Root-Filesystem

Woher weiß der Kernel aber, welches Device er als Root-Filesystem mounten soll? Der Default ist im Kernel einkompiliert und im Byte 508 kodiert. Festgelegt ist er durch die Variable »ROOT_DEV« im Toplevel-Makefile der Kernel-Sourcen. Nachträglich lässt sich der Wert über den »rdev«-Befehl ändern, im Beispiel oben also auf das Floppy-Laufwerk. (»/dev/fd0« hat die so genannte Major-Nummer »2« und Minor-Nummer »0« - in der Fehlermeldung in Abbildung 1 ist auch die Major:Minor-Nummer des Device zu sehen, auf dem das Root-Filesystem gesucht wurde.)

Ohne das »rdev«-Kommando könnte das gezeigte Beispiel mit etwas Glück ein existierendes Linux-System booten, nämlich genau dann, wenn das einkompilierte Root-Filesystem tatsächlich auf der Festplatte vorhanden ist.

Zum Root-Filesystem gehören einige wenige Toplevel-Verzeichnisse und die darin enthaltenen Dateien und Unterverzeichnisse. Details zum richtigen Aufbau der Verzeichnishierarchie sind im so genannten Filesystem Hierarchy Standard (FHS) festgelegt[2]. Für eine Minidistribution sollen natürlich nur die allernötigsten Dateien vorhanden sein.

Was ist also das absolute Minimum, mit dem ein laufendes Linux-System auskommt? Das Mounten des Root-Filesystems. Es erfolgt mit dem Device »/dev /root«, das vom Kernel quasi automatisch erzeugt wird. Deshalb wird ein »/dev«-Verzeichnis benötigt.

Nach dem Mount folgen das Öffnen einer Initial Console sowie der Start des Init-Prozesses. Die Initial Console ist in den Kernel-Quellen fest als »/dev/console« verdrahtet, der Init-Prozess kann an sich ein beliebiges Programm sein. Als Default sucht der Kernel die Datei »/sbin/init«. Findet er diese Datei nicht, sucht er immer der Reihe nach »/etc /init«, »/bin/init« und »/bin/sh«. Hier zeigt sich wieder, dass der Kernel noch einiges an historisch wertvollen Stücken mit sich rumschleppt.

Bei vollständigen Linux-Systemen ist das Init-Programm natürlich deutlich komplexer als lediglich ein Shell-Aufruf. Es startet eine Reihe von Prozessen, die letztlich das gesamte System initialisieren. Der Init-Prozess mit der Prozess-ID »1« bleibt dabei bis zum Shutdown erhalten und bildet die Wurzel aller Prozesse. Das lässt sich sehr gut mit »pstree -pG« oder einer grafischen Prozessanzeige veranschaulichen.

Abbildung 2: Mu Linux ist ein kleines, aber umfassend erweiterbares System.

Angewandter Minimalismus

Ein wirklich minimales Root-Filesystem besteht also nur aus den beiden Dateien »/dev/console« und beispielsweise »/bin /sh«. Wer eine kleine, statisch gelinkte Shell hat (etwa die »ash«, der jedoch wesentlich mehr als nur das B im Namen fehlt), kann dies selbst ausprobieren. Das funktioniert jedoch nur, wenn kein Bootloader zum Start verwendet wird (siehe Kasten "Mit und ohne Bootloader"). Eine Anleitung zum Eigenbau findet sich im Kasten "Minidistribution im Eigenbau".

Das oben beschriebene Kleinst-Linux ist zwar lauffähig, besitzt aber so gut wie keine Funktionalität. Das eingebaute Kommando »echo *« ersetzt beispielsweise rudimentär ein »ls«, aber viel mehr ist wirklich nicht drin. Damit ist die Marschroute zur Minidistribution klar: Es gilt, die Balance zwischen Größe und Funktionalität zu finden.

Ein Ansatzpunkt, der aber hier nicht weiter verfolgt wird, ist der Einsatz eines alten Kernels der Linien 2.2. oder sogar 2.0. Sie sind für viele Aufgaben nach wie vor geeignet und deutlich kleiner als aktuelle 2.4.-Kernel. Unabhängig von der Kernel-Entwicklungslinie macht es aber Sinn, einen auf den Einsatzzweck hin optimierten (eventuell modularisierte) Kernel zu bauen, denn der ist natürlich kleiner als der in einer Normal-Distribution mitgelieferte.

Neben dem Kernel bieten sich also nur die Programme, die durch das Root-Filesystem zur Verfügung gestellt werden, als Ansatz zum Sparen an. Die folgenden Abschnitte beschreiben verschiedene Techniken, wie sich hier Platz schaffen lässt.

Nieder mit Optionsmonstern!

Selbst einfache Programme für die Linux-Kommandozeile bieten oft sehr viele Optionen an, um das Verhalten des Programms zu beeinflussen. Das »ls«-Kommando beispielsweise allein 74 Optionen (korrektes Nachzählen vorausgesetzt), viele davon sind Aliase. Nur um diese verschiedenen Argumente zu parsen, ist schon sehr viel Code nötig. Wirklich genützt werden von den vielen Optionen in den meisten Fällen nur einige wenige Standards.

Verzicht auf eher selten genutzte Funktionalität bringt also den Vorteil kleinerer Programme. Im Internet gibt es bereits verschiedene Tiny-Versionen bekannter Programme (siehe dazu die Links in den Infos. Neben den Programmen selbst haben aber auch die verwendeten Bibliotheken einen deutlichen Einfluss auf die Größe der Programme und des Gesamtsystems. Hier sind die Art der Bibliothek und das Linkverfahren entscheidend.

Es geht auch ohne Libc

Die Libc (auch Glibc genannt) ist die zentrale Bibliothek, gegen die praktisch alle Programme gelinkt werden. Im Laufe der Jahre ist die Funktionalität der Libc ständig gewachsen und damit natürlich auch ihre Größe.

Normalerweise linkt man Programme dynamisch. Dynamisch bedeutet hier, dass die Referenzen zu den Bibliotheksfunktionen erst beim Programmstart aufgelöst und dann auf die entsprechende Funktion in der Ladebibliothek (typischerweise »libc.so.6«) gesetzt werden. Dadurch werden die Programme kleiner und auch der Speicherbedarf des Gesamtsystems sinkt, da die dynamische Bibliothek nur einmal im Speicher vorzuhalten ist. Die Libc ist auch der Garant für die Portierbarkeit von Anwendungen. Verwenden diese nur Funktionen aus der Libc, ist das Portieren meist kein Problem, da diese Bibliothek in aller Regel schon portiert ist.

Was für normale Systeme gut und sinnvoll ist, muss es für Minidistributionen nicht notwendigerweise ebenfalls sein. Gerade bei wenigen kleinen Programmen, die sowieso nur einen eingeschränkten Funktionsumfang haben, macht es keinen Sinn, die gesamte Libc zu installieren, denn diese Programme verwenden nur eine Teilmenge der Funktionen. In diesem Fall ist das statische Linken, bei dem die Funktionen schon beim Linken fest in das Programm eingebunden werden, vorzuziehen.

Für viele kleine Distributionen kommt die Libc5 zum Einsatz, die deutlich kleiner ist als ihr Nachfolger. Unter einem Libc6-System Programme für Libc5 zu entwickeln, ist zwar nicht ganz einfach, doch große Distributionen wie Red Hat oder Debian bieten dafür spezielle Libc5-Environments.

Abbildung 3: Fli4l - der On(e)-Disk-Router.

Sparzwang auch bei Bibliotheken

Eine weitere Option ist es, auf die Libc komplett zu verzichten und stattdessen kleine Alternativen einzusetzen, die zwar nur einen Teil der Funktionsvielfalt der Libc bieten, aber genau jenen Teil, der gemeinhin nötig ist.

Besonders hervorzuheben ist die über[3] erhältliche »uClibc«. Das u steht hier für den griechischen Buchstaben My, englisch wie "mju" gesprochen, zusammen mit dem C wird dies zu "micro". Die uClibc ist nicht nur klein, sondern auch im Funktionsumfang konfigurierbar (etwa bezüglich der Mathematik-Funktionen). Damit ist eine Lösung nach Maß möglich. Natürlich gilt beim Linken für die uClibc dasselbe wie für die Libc. Die uClibc wurde auch schon auf verschiedene Plattformen portiert und hat momentan nur im Threading-Bereich noch größere Lücken, aber daran wird hart gearbeitet.

Neben der uClibc gibt es eine weitere lohnenswerte Alternative, die Dietlibc[19]. Diese Bibliothek entstand ursprünglich ausschließlich mit Blick auf das statische Linken. Inzwischen gibt es aber auch einen dynamischen Loader. Die Dietlibc verfolgt eine etwas andere Strategie als die uClibc, deshalb sind in vielen Fällen kleinere Änderungen an den Makefiles oder dem Quellcode von Programmen notwendig. Ein großer Vorteil dieser Bibliothek ist, dass es auf den Dietlibc-Webseiten schon fertige Binaries für eine ganze Reihe beliebter Programme zum Download gibt.

Auch die so genannten Multicall-Binaries helfen Platz sparen. Jedes Programm hat notwendigerweise neben dem vom Programmautor gelieferten Code auch einen generischen Teil, den Startup-Code, den der Linker hinzufügt. Wer also 100 Programme installiert hat, der hat auch 100-mal diesen Startup-Code auf der Platte.

Sag mir, wer ich bin

Multicall-Binaries verwenden folgende Strategie: Das Betriebssystem übergibt den Programmnamen immer als Argument »0«. Je nachdem, mit welchem Namen das Programm aufgerufen wird, verhält es sich anders. Heißt das Programm »ls«, verhält es sich wie »ls«, heißt es »cat«, verhält es sich wie »cat«. Der Overhead für die Auswertung des Programmnamens ist geringer als der so eingesparte Startup-Code.

Über Hard- oder Symlinks kann nun ein Programm mehrere Namen erhalten. Hardlinks benötigen dazu nur den Platz eines zusätzlichen I-Node, bei Symlinks schwankt der Platzbedarf je nach eingesetztem Dateisystemtyp.

Der Klassiker unter den Multicall-Binaries ist Busybox[4], das Schweizer Offiziersmesser des Linux-Systems. Über eine einfache Konfigurationsdatei lassen sich damit Multicall-Binaries nach Maß mit der genau benötigten Funktionalität erzeugen. Es ist wohl überflüssig zu erwähnen, dass Busybox Teil fast jeder existierenden Minidistribution sowie der Start- und Rettungsdisketten der großen Distributionen ist. Busybox harmoniert auch optimal mit der uClibc - die Entwicklung wird nicht zufällig vom selben Autor vorangetrieben, der auch längere Zeit beim Embedded-Spezialisten Lineo angestellt war.

Ein paar Zahlen zum Größenvergleich: Busybox (mit der überwiegenden Zahl der enthaltenen Anwendungen) dynamisch gegen die Glibc 2.2.5 gelinkt kommt auf eine Größe von 276 KByte. Die »libc6.so«-Datei hat gestrippt ungefähr 1,2 MByte. Busybox statisch gelinkt kommt auf 823 KByte, das ist aber immer noch weniger als Busybox und Bibliothek zusammen. Unter der uClibc sehen die Daten wie folgt aus: dynamisch 275 KByte bei einer Bibliotheksgröße von 207 KByte, statisch sind es 356 KByte. Die genauen Größen hängen sehr stark von der gewählten Konfiguration ab. Die uClibc-Bibliothek schrumpft so zum Beispiel auf 169 KByte, falls man auf RPC - unter anderem notwendig für NFS-Mounts - verzichtet.

Weitere Techniken

Eine zusätzliche wichtige Technik, um Programme und Bibliotheken zu verkleinern, ist das Entfernen unnötiger Sections, etwa mit Debug-Informationen. Dazu werden die Tools »strip(1)« oder »objcopy(1)«, sie sind Teile der Binutils, verwendet. Für Binaries bietet sich

objcopy --strip-all Quelle Ziel

an, für Bibliotheken, die etwas empfindlicher sind, dagegen:

objcopy --strip-unneeded Quelle Ziel

Nach dem Strip folgt die Kompression. Auch unter Linux sind sich selbst entpackende Binaries möglich, sie werden vom Loader im Speicher transparent entpackt. Der Nutzen komprimierter Binaries für Minidistributionen ist aber eher fraglich, da bei ihnen das Root-Filesystem sowieso komprimiert ist. Bei Systemen, bei denen das Linux-System direkt vom Speichersystem (zum Beispiel eines Flash-Speichers oder einer Root-Diskette) gefahren wird, könnte der Einsatz aber durchaus sinnvoll sein.

Grafische Anwendungen auf kleinen Systemen sind nichts für Monster-Umgebungen wie etwa KDE oder Gnome. In diesen Fällen spielen alternative GUI-Toolkits ihre Stärke aus. Zu nennen wären zum Beispiel das Fast Light Toolkit FLTK[9] oder Qt-Embedded. Ebenfalls möglich ist auch der vollständige Verzicht auf X - die Programmentwicklung wird dann aber deutlich aufwändiger.

Als Weg zu kleinen Programmen sei zu guter Letzt auch noch das gezielte Programmieren erwähnt. Im Extremfall geht es dann natürlich um Assembler. Albrecht Kleine hat es mit dem Editor E3 geschafft, auf 8 KByte statisch einen Editor für Minisysteme zu schaffen[10]. E3 bietet dabei trotz seiner Winzigkeit Emacs-, Vi- und Wordstar-Belegungen an, natürlich nur mit eingeschränkter Funktionalität, aber für Rettungsdisketten mehr als ausreichend.

Fazit

Maßgeschneiderte Linux-Systeme sind zwar nichts für Einsteiger, aber mit etwas Erfahrung sind sie auch kein Hexenwerk. Beim Zusammenbau lernt man sehr viel darüber, wie verschiedene Linux-Komponenten zusammenspielen, um ein großes Ganzes zu bilden. Die Leistungen der großen Distributoren lernt man - trotz immer wieder auch berechtigter Kritik - gerade dadurch erst richtig zu würdigen.

Einer der großen Vorteile von Open Source ist es, dass das Rad zwar nicht immer wieder neu erfunden werden muss, aber im Sinn einer gesunden Konkurrenz durchaus erfunden werden kann. Aus diesem Grund gibt es auch Unmengen von Klein- und Kleinstdistributionen. Einen guten Überblick gibt die Distributionsliste der Linux Weekly News[5]. Eine Reihe persönlicher Favoriten zeigen die Kästen.

Wer selbst in die Produktion eines Linux-Systems einsteigen will oder muss, findet hier aber eher eine Quelle für Anregungen als einen Ausgangspunkt. Die Neuerstellung führt in der Regel zu besseren Ergebnissen als Anpassungen von Vorhandenem. Die existierenden Bausteine lassen sich aber dank GPL mit Erfolg verwenden. (uwo)

# mkdir -p ~/src/LM-Dist/root-fs
# cd ~/src/LM-Dist/root-fs
# mkdir -p bin boot cdrom dev etc floppy home \
lib mnt opt proc root sbin tmp usr var/log
# cd ..

# ldd programm

# tar -cpf - -C /dev . | tar -xpf - -C root-fs/dev

# dd if=/dev/zero of=initrd bs=1k count=2600
# mke2fs -F initrd
# mkdir -p mnt
# mount -o loop initrd mnt
# tar -cpf - -C root-fs . | tar -xpf - -C mnt

# umount mnt
# gzip -9n initrd

01 # mkdosfs /dev/fd0
02 # syslinux /dev/fd0
03 # mount -t vfat /dev/fd0 mnt
04 # cp initrd.gz mnt
05 # cp boot/vmlinuz mnt/linux
06 # cat > mnt/syslinux.cfg << EOF
07 default linux
08 prompt 1
09 timeout 30
10 display bootinfo
11 append initrd=initrd.gz root=/dev/ram
12
13 label linux
14 kernel linux
15 EOF
16 # cat > mnt/bootinfo << EOF
17 Welcome to LM-Dist
18
19 Just hit enter or wait 3 seconds
20
21 Enjoy LM-Dist
22 EOF
23 # umount mnt

Copyright © 2002 Linux New Media AG

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.