Linux-Distribution oder Auto — der Aufwand, es zusammenzubauen ist etwa der gleiche

Ich hatte vor gut zehn Jahren das Vergnügen hin und wieder am Aufbau von Autos mitwirken zu dürfen. Das waren entweder Oldtimer oder wüste Rekombinationen vorhandener Teile, also der Bodenplatte eines Schräglenker-Käfers mit Subaru- oder Alfa-Romeo-Wasserboxern, Porsche-Schräglenkern und was sonst noch so herumliegt. Darauf kommt eine Karrosserie, die vom Radstand her eben passt, gerne auch mal aus Fiberglas. Heute würde man wahrscheinlich noch eine Megasquirt in den Ring werfen, und erstmal einen gepatchten GCC dazu verwenden, Firmware zu kompilieren.

Damit sind wir schon ziemlich nahe am Thema: Auch eine Linux-Distribution besteht aus “am Markt erhältlichen Komponenten”, die einfach zusammengefügt werden müssen — in der Theorie. Primär aus Neugier, aber auch weil das eine oder andere Projekt, an dem ich arbeite, eine simple “single purpose live distribution” erfordert, habe ich vor etwa zwei Jahren damit angefangen, eine Distribution auf Basis von BusyBox und einer minimalen Ramdisk aufzubauen.

In den letzten Wochen hatte ich etwas Zeit, daran weiterzuarbeiten und habe ein rudimentäres Paket- und Abhängigkeitsmanagement und eine Buildumgebung für ein glibc basiertes Rootdateisystem drumherum gebaut. Daraus ist bislang ein kleines Desktopsystem mit Xvesa und XFCE 4.6 entstanden, das derzeit 50 bis 70MB Squash-Container belegt und in einer bekannten Umgebung (nur wenige Kernelmodule werden geladen) etwa 12 Sekunden bis zum Desktop braucht. Kompiliert wird in einer Chroot-Umgebung, was die Integration neuer Pakete recht einfach macht: man kann jederzeit eine Kopie der Chroot-Umgebung erstellen, reinwechseln, basteln und das resultierende Buildscript sichern.

Und was ist daran besonders?

  • Initramfs modular: Die Tatsache, dass einem modernen Kernel beim Start mehrere Initramfs übergeben werden können, mache ich mir für die Modularisierung zunutze: Ein Initramfs für Kernelmodule, eines mit Scripten und Binaries, eines mit Einstellungen. Das erleichtert beispielsweise Tests mit verschiedenen Kerneln oder Updates der für das /home-Verzeichnis vorgesehenen Einstellungen.
  • Bootprozess einheitlich: Als Init kommt das “Simple Init” der Busybox (mit einfacher inittab) zum Einsatz, dieses triggert einige BSD-artige Scripte, jedes dieser Scripte kann über einen Cheatcode skipservices=|network|dropbear|...| deaktiviert werden. Die bei anderen Live-Distributionen übliche Trennung zwischen Startcode für Hardware-Erkennung und Startcode nach Mounten der Container ist damit aufgehoben.
  • Modulare Container: /bin, /usr etc. befinden sich jeweils auf eigenen Containern, zusätzliche Container können einfach als SquashFS gepackt und im Containerverzeichnis abgelegt werden. Ein Eintrag in der Datei “mount.txt” definiert dann den Einhängepunkt. Das erleichtert unabhängige Erweiterungen, ohne dass Container oder Initramfs geöffnet und neu gepackt werden müssen.
  • Drei Startmodi: Das gesamte System kann als Initramfs geladen werden, es wird dann beim Start in den Arbeitsspeicher entpackt, sinnvoll bei sehr kleinen Systemen wie einem Thinclient oder einem Backup- und Restoretool, das ohne NFS-Server so komplett per TFTP gestartet werden kann. Bei etwas größeren Dateisystemen wie einem Kiosksystem mit Desktop, Browser und Zugriff auf einzelne lokale Geräte, wo die Container gepackt etwa 60MB einnehmen (entpackt 200MB), können die SquashFS-Dateien als Initramfs geladen werden. Und drittens der klassische Startmodus beim Start von USB-Stick oder CD, bei dem die Container read-only vom Startmedium gemountet (oder ggf. vorher ins RAM kopiert) werden.
  • Kein Pivoting: Das Root-Dateisystem bleibt auf dem Initramfs. Wozu sollte man das Wurzelverzeichnis pivotieren, wenn sowieso ein temporäres Verzeichnis Root-Verzeichnis ist?
  • Busybox für Brot- und Butter-Aufgaben: Die statisch gegen uClibc gelinkte BusyBox stellt auf nur 800kB eine Menge typischer Unix-Tools bereit. Es müssen so nicht dutzende GNU-Pakete kompiliert und integriert werden. Wird während dem Build festgestellt, dass ein GNU-Werkzeug nicht integriert ist, wird auf die entsprechende BusyBox-Funktion verlinkt.

Was es nicht wird!

  • Keine Desktop-Distribution: Das können Ubuntu, Fedora, openSUSE und Co besser. Schon der schiere Aufwand, 10.000 Pakete zu pflegen erfordert hunderte Maintainer. Eine Zahl von 500 bis 1000 Paketen dürften ausreichen, ob die oben angesprochenen Einsatzzwecke gut abzudecken (derzeit sind es etwa 200 einzelne Pakete). Wer mehr will, muss obendrauf selbst kompilieren. Zehn bis zwanzig eigene Buildscripte für zusätzliche Pakete sind zumutbar
  • Keine Server-Distribution: Auch dutzende Serverpakete zeitnah mit Sicherheitspaketen zu versehen, ist schwierig. Denkbar ist in ferner Zukunft eine Möglichkeit, auch kompakte Xen-Images als Kombination aus ro-Dateisystemen für Anwendungen und rw-Dateisystemen für Daten zu erzeugen. Xen mit Linux-Instanzen, die mit 128MB RAM performant laufen und durch Austausch der ro-Container upzudaten sind, stellt eine interessante Alternative zum Shared Hosting dar… Aber das ist weit entfernt.
  • Keine Vielzweck-Live-Distri: Das können Knoppix, Sidux und auch Slax besser. Die Modularität von Slax kommt den Nutzern entgegen, die im Rahmen der vorgesehenen Container kombinieren möchte. Wer es etwas stärker angepasst haben möchte, dürfte dagegen bei “meiner” Distribution fündig werden.
  • Keine Cross-Compile-Distri für den Embedded-Bereich: Mittelfristig soll 32 Bit x86, 64 Bit x86/AMD64 und PowerPC 32 unterstützt werden. Aber bis auf die uClibc-Busybox alles in einer Chroot-Umgebung kompiliert. Wer für eingebettete Systeme crosscompilieren möchte, sollte das uClibc Buildroot, Poky, Rock Linux oder T2 ausprobieren.

Alles nur heisse Luft?

Mitnichten, das ISO welches ich im Moment vorliegen habe, hat 372MB — noch integriert es neben 80MB Squash-Containern (nicht optimiert und mit Firefox und Flash) zwei Kernel mit jeweils über 140MB Modulen. Wenn das aufgeräumt ist, gibt es eine erste “Technologiedemo”, die wenigstens auf den gängigsten Ethernet-Chips mit brauchbarer Vesa-Grafik booten sollte. Bereits enthalten ist ein Script welches mittels lshw, lspci und anderen Tools die Hardware-Infos ausliest und — falls vorhanden auf ein FAT32-Medium speichert, das den Ordner hwinfo im Wurzelverzeichnis enthält. Wer möchte, darf mir das dort abgelegte Hardwareprotokoll zu Analyse- und Statistikzwecken zukommen lassen. Mehr in den nächsten Tagen, Nutzer die nicht regelmäßig mitlesen, können mir eine Mail zukommen oder einen Kommentar hinterlassen. Ich informiere dann, wenn es etwas herunterzuladen gibt.

Und wie heisst das Kind?

Angedacht ist lesslinuxlight, embeddable, small, scalable linux oder lacking elegance, stupid, scary. :-)

Let the Flamewar begin, kommentiert schön fleissig.

13 thoughts on “Linux-Distribution oder Auto — der Aufwand, es zusammenzubauen ist etwa der gleiche

  1. andre

    Besteht die Möglichkeit schon heute dein Experiment zu testen?
    Welche mindest oder höchst Hardware wird unterstützt?

  2. Administrator Post author

    Im Laufe des Freitags wird es ein testfähiges Image geben, einen Kernel muss ich noch rausschmeissen und das Bootmenü etwas anpassen. Mindestanforderung für die Variante in den Screenshots dürften 256MB RAM sein, eine absolute Minimalversion sollte sich bis auf 32MB hinunter abspecken lassen. Nach oben gibt es keine Grenzen, allerdings werde ich bei den Versionen, die eher als Toolbox gedacht sind Kernel mit Unterstützung für max. 4GB RAM verwenden.

  3. Niko

    Nachdem TomTom erst kürzlich Probleme mit Microsoft wegen deren FAT-Dateisystem hat, würde ich doch mal vorschlagen nicht auf FAT32 sondern ein anderes, freies Dateisystem zu speichern!

  4. shikari

    Habe deinen Blogeintrag im uu-Planeten gelesen, und war irgendwie neugierig was hinter dem ganzen steckt bzw. bin ich aus dem nicht ganz schlau geworden.

    Und da ich ein Nutzer bin der nicht regelmäßig mitliest, frag ich doch einfach mal genau um was es sich da handelt was du da machst ?
    Von dem ganzen Codezeugs versteh ich eh nur Bahnhof, also erspar dir das :D
    Soll das ein Ubuntu/Linux werden, welches auch auf “schwachen” Pc’s läuft ?
    Oder ist es einfach vom Umfang her kleiner, dass es eben nur die absolut wichtigsten Sachen hat (darauf deutet zumindest die “geringe” Anzahl von Paketen hin.

    Wäre nett wenn du mir eine E-Mail schreiben könntest, da der Beitrag doch ein
    großes Interesse in mir geweckt hat mehr zu wissen :D

    Grüße

  5. Administrator Post author

    @Shikari: Mein Ziel ist es, eine kompakte Plattform für Live-Distributionen für bestimmte Einsatzzwecke zu schaffen. Die Basis ist keine bereits vorhandene Distribution, die erste Stufe der Build-Umgebung basiert auf “Linux from Scratch”. Mit dem Fokus auf den Live-Einsatz kann ich Konzepte austesten, die bei anderen Live-Distributionen, die beispielsweise Abkömmlinge von Desktop-Distris sind, nicht zum Einsatz kommen.

    Ich plane keine Neuerfindung des Rades, sondern möchte eine kompakte Basis für Nischen schaffen. So soll LessLinux beispielsweise zu einer Plattform avancieren, mit der sich leicht selbstbootende Wartungstools (bspw. Backup- und Restore-Applikationen), Kiosksysteme oder ähnliches bauen lässt.

    Mir wäre sehr geholfen, wenn auch skeptische Leser das im Laufe des Tages erhältliche ISO-Image herunterladen und testweise booten, sowie mir ein Hardware-Protokoll erstellen würden. Dazu später mehr.

  6. Alex

    Ich bin schon gespannt, wie groß dein ISO-Image letztendlich wird.
    Welche Kernel-Version benutzt du?
    Bislang hielt ich in dem Bereich ressourcensparende Mini-Distribution Damn Small Linux (http://damnsmalllinux.org/index_de.html) für das praktikabelste, da man die Distribution relativ leicht anpassen und es sogar übers Netzwerk laden kann.

  7. Administrator Post author

    @Alex: Derzeit einen Vanilla 2.6.29. Ein Image mit sehr begrenzter Hardwareunterstützung und einfacher Ruby-Gtk-GUI als Frontend für eine per PXE gebootete Imaging- und Restore-Umgebung liegt bei 15 bis 30MB, ein recht komfortabler Desktop liegt etwa in der Größenordnung von 200MB — also ähnlich wie bei Slax, aber dafür modularer aufgebaut und leichter anzupassen.

    Mit DSL habe ich lange gearbeitet, die harte Beschränkung auf ein 50MB-Grundsystem erzwingt jedoch viele Kompromisse, die ich nicht eingehen möchte.

    Für den PXE-/TFTP-Boot von DSL habe ich auch etwas Input liefern können, ist zwar schon ein paar Jahre her, aber…

    http://damnsmalllinux.org/f/topic-3-26-15960-0.html

  8. Ulrich Klotz

    Hallo,

    ich habe gerade die ComputerBild Notfall CD 3.0 ausprobiert und bin sehr beeindruckt, wie klein, schnell und vollständig das alles ist.
    Es gibt nur eine Sache, die mich stört und für die ich Abhilfe suche.
    Ich verwende ein MSI WindU100, das ein sehr empfindliches Sentelic-Touchpad hat. Ich wünschte mir einen Touchpad- oder Maustreiber, mit dem man die touch-klick-Funktion abschalten kann. Im Netz habe ich nur einen .deb (Debian)-Treiber gefunden, ich weiss aber nicht, ob und wie man den installieren kann –
    any ideas?
    Viele Grüße
    Ulrich Klotz

  9. Leibold

    Sehr geehrter Herr Schlenker,

    ich glaube ich habe einen Fehler in Ubuntu 10.10 64-bit-DVD-Edition gefunden.
    WLAN funktioniert überhaupt nicht, wenn der Zugang zum Router mit WPA2-Personal
    AES und Preshared Key (PSK) und nichtübertragenem SSID geschützt ist. In den Versionen Ubuntu 10.10 Netbook Edition und Xubuntu 10.10 32-bit Live funktioniert das diesbezügliche WLAN aber einwandfrei. Ich habe die Autoren diesbezüglich bereits per e-mail kontaktiert.
    Sollten mir diese nicht weiterhelfen können, dann müßte ich die parallel zu Ms-Vista installierte SW wieder deinstallieren. Die Ms-Bootprogramme enthalten offensichtlich ASCII- und Binärcode und sind mit den mir zur Verfügung stehenden MS-Editoren nicht zu öffnen. Leider habe ich die alten Versionen der Bootprogramme vor der Ubuntu-Installation nicht gesichert. Mit welchen Editoren oder Tools kann ich die Bootprogramme editieren? Dss von Ihnen im Artikel erwähnte Kommandozeilenprogramm ms.sys habe ich nirgends gefunden!? Ist dies ein altes DOS-Programm? Gibt es eine Referenz, die diese Prozeduren etwas ausführlicher behandelt?
    Wenn Sie an meinem ausführlicheren e-mail an die Autoren interessiert sind, dann benötige ich Ihre e-mail-Adresse um dieses an Sie weiterleiten zu können.

    Im Voraus möchte ich mich für Ihre Bemühungen bedanken.

    Mit freundlichen Grüßen
    Gerd Leibold

    Mit freundlichen Grüßen
    Gerd Leibold

Comments are closed.