• LessLinux: Auch mit “meiner” eigenen, lose auf Linux From Scratch aufbauenden Live-Distribution LessLinux ging es in den letzten Wochen in vielen kleinen Schritten weiter. Mittlerweile wird viel Standard-Netzwerk-Hardware automatisch erkannt, WLAN kann mit WICD angesprochen werden, einige eigene Ruby-Gtk-Scripte sorgen für eine komfortable Installation auf USB-Stick oder die Erstellung von Containern mittels Cryptsetup.

  Jetzt kommt die Stelle, an der Ihr helfen könnt: Bitte ladet Euch den aktuellsten Build herunter und erstellt ein Hardware-Protokoll. Mit diesem Hardware-Protokoll (es enthält die Ausgaben von lspci, lsusb und lshw), habe ich es leichter, die Hardwareerkennung zu verbessern.

• Android: Das Handy-Linux kommt nun auch mit einem Native Development Kit, mit dem sich native Linux-Anwendungen erstellen lassen, die direkt auf dem Linux des Android und nicht auf der aufgesetzten Dalvik VM laufen. Insbesondere die Portierung von Emulatoren und einigen Spielen, die SDL verwenden, dürfte vom NDK profitieren.

  Unterdessen zeigt Android bereits erste Fragmentierungserscheinungen: HTC stellte auf dem eigenen Telefon eine erweiterte Oberfläche “Sense UI” vor, die leider nicht auf die Telefone mit Google Branding kommen soll. Mal gespannt, ob das Resultat bald drei verschiedene Adressbuch-APIs sind.

• SkyOS: Bei SkyOS handelte es sich bislang um proprietäres ein Ein-Mann-Betriebssystem. Ein C++-lastig implementiertes OS für 32-Bit-x86, das mit einer gut durchdachten Architektur glänzen kann. Als Problem stellte sich in den letzten Jahren jedoch die Treiber-Unterstützung heraus, zuletzt kam die Entwicklung fast zum Erliegen. Nun hat der Entwickler Robert Szeleney einen radikalen Schritt gewagt und SkyOS auf einen Linux-Kernel und ein minimales Linux-Userland gestellt. Die Vorgehensweise erinnert etwas an NeXTstep bzw. MacOS X. Auf jeden lohnt es sich, ein Auge auf die weitere Entwicklung zu werfen. Mehr im Blog von Robert Szeleney

• Netbooks: In den letzten Monaten hat sich hier wenig getan. Netbooks sind beinahe eine Commodity und unterscheiden sich nur noch im Preis. Die letzten Juli für 399 Euro verkauften Medion Akoya E1210 gibt es nun als B-Ware für 219 Euro. Da fällt es umso positiver auf, dass HP mit dem hübschen, wenn auch nicht ganz billigen HP 5101 zeigt, dass Alu und Magnesium im Understatement-Gehäuse noch ihre Berechtigung haben. Nachtrag, 30. Juni: Golem hat Details und Bilder der hierzulande verkauften Version mit UMTS.

http://cdprojekte.mattiasschlenker.de/Public/LessLinux/

Das Live-System macht noch nicht viel mehr, als einen Xvesa-Server mit simplem XFCE 4.6-Desktop und Firefox 3.0.8 zu starten. Die meisten gängigen Ethernet-Treiber werden geladen und Karten per DHCP konfiguriert.

Zum gegenwärtigen Zeitpunkt dürfte das System vor allem für Nutzer interessant sein, die Ideen für eigene Live-Distributionen (das Konzept der “narrow purpose” oder “single purpose distribution” für eingeschränkten oder auf eine Applikation spezialisierten Anwendungszweck) erwähnte ich ja schon. Die Distribution erstellt Hardware-Protokolle, mit denen auch technisch weniger versierte Nutzer einen Beitrag zur Weiterentwicklung leisten können.

Cheatcodes in der Alpha (mit Tab im Bootmenü erreichbar)

• toram=… Schwellwert in kB für das Kopieren ins RAM, wer es ganz vermeiden möchte, gibt einen unsäglich hohen Wert, bspw. 999999999999 an.
• skipcheck=1 Überspringt die SHA1-Prüfung von Bootdateien und Container
• skipservices=|service1|service2|…| Überspringt den Start einzelner Dienste, hier kann bspw. dropbear entfernt werden, damit der SSH-Daemon auf Port 22222 startet.
• xmode=BREITExHOEHE[xFARBTIEFE] Bevorzugte Bildschirmauflösung für den Xvesa-Server, hier kann bspw. 1680×105 oder 1280×800 übergeben werden, um die native Auflösung eines Breitbild-Displays zu verwenden.
• rootpwhash=… MD5-Hash des Root- und Userpasswortes, bspw. mit openssl passwd -1 erzeugt. Standardhash entspricht dem Passwort test

Hardwareprotokoll

Beim Start wird in /tmp/ eine Protokolldatei hwinfo.unkown.zeitstempel.tgz angelegt. Wenn beim Start ein USB-Stick anwesend ist, der einen Ordner hwinfo enthält, wird die Datei automatisch dorthin kopiert. Ich wäre dankbar, diese Hardwareprotokolle von möglichst vielen Rechnern zu erhalten. Außer der MAC-Adresse von Netzwerkkarten und dem Partitionierungsschema (Ausgabe von fdisk -l) enthalten diese Dateien keine eindeutig einem bestimmten PC zuordnenbare Informationen — ich behandle die Hardware-Protokolle natürlich vertraulich.

Bitte schickt mir Eure Hardware-Protokolle per Mail an ms@mattiasschlenker.de. Falls Ihr mit CD und Stick von Rechner zu Rechner zieht, könnt Ihr auch mit dem Cheatcode hwid=modell (bspw. hwid=akoya_e1210) eindeutigere Dateinamen ereugen lassen. Falls Ihr einen Webmailer nutzt, könnt Ihr natürlich auch die Datei in /tmp ohne Umwege versenden.

Boot von USB-Stick

Wenn ein Stick mit Syslinux bootfähig vorbereitet wurde, genügt es den Inhalt der CD auf den Stick zu kopieren.

Und weiter?

Im Laufe des Wochenendes folgen die vollständigen Quellcodes und nächste Woche dann eine erste Version der Build-Umgebung.

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 lesslinux — light, embeddable, small, scalable linux oder lacking elegance, stupid, scary.

Let the Flamewar begin, kommentiert schön fleissig.

Zweimal wird mit Backticks die Ausgabe eines Befehls in eine Variable eingelesen. Einmal ein simples echo, einmal ein ganzes Script, das ein paar verschachtelte if und case hat. Beim einfachen echo evaluiert grep korrekt zu true, beim Script nicht.

Ich habe jetzt einen Workaround, bei dem ich nicht per Übergabe eines Parameters die Startup-Scripte sagen lasse, was sie tun, sondern verwende speziell formatierte Kommentare, die ich direkt greppe. Das ganze ist Teil eines etwas umfangreicheren, modularen Mini-Linux, an dem ich gerade arbeite — mehr dazu in den nächsten Tagen.

Wer mit meinem Build der Busybox spielen möchte: busybox-1.13.2-static-ulibc-i686.tar.gz

Downloads

• uclibc-chroot-20080316.tar.bz2
• Artikel PC-Magazin Linux 2007/05 “Dich krieg ich klein!”

Kurz und bündig zum Einsatz

Das RootFS ist als Chroot-Umgebung für i686 oder AMD64 gedacht. Wenn Sie einen Kernel vorbereiten oder einen Xen-Kernel zur Hand haben, können Sie auch direkt vom RootFS booten — your mileage may vary.

• Zuerst wird entpackt:

  tar xvjf uclibc-chroot-20080316.tar.bz2

• Mounten Sie jetzt ein paar typische Verzeichnisse im Chroot:

  mount -o bind /tmp uclibc-chroot/tmp
  mount -o bind /dev uclibc-chroot/dev
  mount -t proc none uclibc-chroot/proc

  Sollten Sie im Chroot Netzwerkzugriff benötigen, kopieren Sie die /etc/resolv.conf des Hosts in die Chroot-Umgebung.

• Jetzt wechseln Sie in den Chroot-Käfig:

  chroot uclibc-chroot /bin/bash

  Unter AMD64 kann es nützlich sein, mit setarch den im Chroot gestarteten Programmen eine andere Architektur vorzugaukeln

  setarch i386 chroot uclibc-chroot /bin/bash

Gehen Sie wie folgt vor, um im Chroot eine Busybox 1.9.1 zu bauen. Zunächst außerhalb des Chroots:

• Entpacken und konfigurieren im gemeinsamen /tmp:

  cd /tmp
  wget http://busybox.net/downloads/busybox-1.9.1.tar.bz2
  tar xvjf busybox-1.9.1.tar.bz2
  cd busybox-1.9.1.tar.bz2
  wget -O .config http://cdprojekte.mattiasschlenker.de/Public/Chroot-Umgebungen/uclibc-chroot-20080316.src/.config-busybox-static
  make oldconfig

• Sie können die Konfiguration nun anpassen:

  make menuconfig

• Vergessen Sie nicht, möglicherweise vorhandene Binaries, die gegen glibc gelinkt sind, aufzuräumen

  make clean

Im Chroot findet das eigentliche Bauen statt:

• Zuerst kompilieren:

  make

• Dann Installation in _install:

  make install

Bei unveränderter Verwendung meiner .config-busybox-static sollte ein etwa 800k großes, statisch gelinktes Binary die Folge sein, das auch unter einem glibc-Linux (normales Server- oder Desktoplinux) läuft. Sie können mit diesem Binary und einem Kernel bereits ohne zusätzliche Bibliotheken ein Minilinux auf Initrd erstellen.

Hinweise zum Selbstbau der Chroot-Umgebung

Prinzipiell ist der Selbstbau mit den Buildroot-Scripten von uClibc.org recht einfach zu bewerkstelligen. Man konfiguriert mit make menuconfig die gewünschte Toolchain und die im Ziel enthaltenen Pakete und baut schließlich mit make. Das uClibc-Root-Filesystem lässt sich auf die unterschiedlichsten Architekturen anpassen, mit Bootloader und Kernel ausstatten. Sogar viele X11-Pakete sind mittlerweile an Bord, so dass Embedded-Entwickler recht flott zu einem RootFS für Entwicklungsboards kommen. Dazu gibt es ein kleines README, in dem Detaileinstellungen der verwendeten Busybox etc. erklärt sind — unbedingt lesen. Dennoch wird nicht alles auf Anhieb klappen. Mir sind folgende Probleme aufgefallen:

• Im RootFS fehlen trotz angewählter Toolchain im Target die uClibc-Header. Die manuell in der .config gesetzte Variable BR2_CROSS_TOOLCHAIN_TARGET_UTILS=y schuf Abhilfe.
• Das ar im RootFS war dennoch ein Softlink auf die Busybox. Das fehlende ar (es war gebaut worden) fand find . -name ar -type f — ldd entlarvte dann unter den gefundenen Binaries das für uClibc crosscompilierte.
• Gcc 4.2.1 war ein Griff ins Klo, er produzierte nur Binaries, die abschmierten. Zum Debuggen hatte ich keine Lust, probierte also zunächst mal Gcc 4.1.2. Mit dem klappte alles und der im RootFS installierte Gcc 4.1.2 produziert auch lauffähige Binaries.
• Hin und wieder können Quellcodes nicht heruntergeladen werden. Auf diese Tools verzichtete ich. Schlimmstenfalls müssen die fehlenden Programme im Chroot mit den dort enthaltenen Tools nachinstalliert werden.

Quellcodes und Konfigurationen

Sie können meine Konfigurationsdateien verwenden, um selbst ein RootFS zu erstellen. Bitte vergessen Sie nicht, ein make oldconfig durchzuführen, wenn Sie mit einem anderen Snapshot als vom 16. März 2008 arbeiten.

Die Verwendung ist einfach:

• Zuerst werden einige spezielle Dateisysteme ins Chroot gemountet:
  mount -t proc none uclibc-chroot/proc
  mount -t devpts none uclibc-chroot/dev/pts
  mount -o bind /tmp uclibc-chroot/tmp
• Dann kann per Chroot ins uClibc-System gewechselt werden
  LC_ALL=C chroot uclibc-chroot /bin/bash
  

Im Chroot können Sie beispielsweise im nun gemeinsam mit dem Hostsystem genutzten /tmp die gewünschten Programme statisch bauen, herausfischen und auch auf älteren Linux-Systemen oder Systemen mit C-Bibliotheksproblemen laufen lassen.

Ich nutzte derartige Binaries beispielsweise um auf ganz alten Systemen “rsync” nachzurüsten. Die uClibc-Umgebung ist gegen uClibc 0.9.29 gebaut und verwendet die Header von Linux 2.6.20. Beim Einsatz der erzeugten Binaries auf einem ganz alten Linux kann es unter Umständen erforderlich sein, eine Chroot-Umgebung mit Headern von 2.4 zu erstellen. Dabei helfen die Buildrootscripte von uClibc.org. Nach Fertigstellung ist allerdings zu beachten, dass unter Umständen “ar” und einige der von BusyBox bereitgestellten Tools nicht ausreichend funktionieren. In der zum Download angebotenen Umgebung ist dies korrigiert.

• uclibc-chroot-20070601.tar.bz2

Das hier vorgestellte System basiert auf den Komponenten:

• BusyBox 1.2.1
• uClibc 0.9.29 (beta) uClibc-Xen-Image als Chroot-Umgebung
• Dropbear 0.48.1 SSH-Server
• Rsync 2.6.8 für den Dateitransfer

Update: Auf cdprojekte.mattiasschlenker.de steht ein fertiges ISO-Image mit vielen IDE- und SATA-Treibern zur Verfügung. Dieses sollte nicht in Produktivumgebungen eingesetzt werden, da es seine IP-Adresse per DHCP bezieht und ein schwaches Rootpasswort (“test”) verwendet!

Die Arbeitsumgebung

Ich bevorzuge die kompakte C-Bibliothek uClibc, wenn ich BusyBox basierte Systeme baue. Nicht nur, weil uClibc kompakter als die Glibc ist, sondern selbst bei einer statisch gelinkten Glibc oft einzelne Bibliotheken dynamisch benötigt werden, was die Arbeit erschwert. Mein Beispiel zeigt deshalb eine dynamisch gelinkte BusyBox, bei der ich die Bibliotheksabhängigkeiten von Hand mit ldd auflöse.

Als Arbeitsumgebung dient dabei ein uClibc-Rootdateisystem. Sie können eines als komprimiertes Image von www.uclibc.org herunterladen oder das von mir eigentlich für Xen erstellte zu nutzen. Letzteres verwendet die Header von Kernel 2.6.12 und kommt mit GCC 4.0.

Erstellen Sie ein Arbeitsverzeichnis und einen Mountpoint für die später anzulegende Initrd:

mkdir busybox-build
mkdir busybox-initrd

Das uClibc-Rootdateisystem benötigt einen temporären Mountpoint:

mkdir /tmp/uclibc
mount /tmp/uclibcroot.img /tmp/uclibc

Der Inhalt des uClibc-Dateisystems wird ins Arbeitsverzeichnis synchronisiert:

rsync -avHP /tmp/uclibc/ busybox-build/

Das busybox-build soll mit chroot genutzt werden. Hierfür muss /proc verfügbar sein:

mount -t proc none busybox-build/proc/

Die weitere Arbeit findet im chroot statt:

chroot busybox-build /bin/sh

Passen Sie im chroot die /etc/resolv.conf an. Sie hilft, wenn Sie aus dem Chroot heraus etwas herunterladen wollen.

Bauen der Busybox

Sie können die aktuelle Version der BusyBox unter www.busybox.net herunterladen. Entpacken Sie die Busybox (ich gehe im weiteren Verlauf der Anleitung von der Arbeit in /tmp aus) und konfigurieren Sie diese mit

make menuconfig

In meiner uClibc-Umgebung funktionierte übrigens make menuconfig bei BusyBox 1.2.1 nicht, weshalb ich mit zuerst mit make clean aufräumte und vom Hostsystem aus die Konfiguration der BusyBox vornahm. Anschließend war ein erneutes make clean notwendig, um das BusyBox-Buildverzeichnis von Überresten gegen Glibc gelinkter Binaries zu befreien. Sie können abkürzen und meine BusyBox-Konfiguration verwenden (nach .config kopieren) Wählen Sie die enthaltenen Tools nicht zu sparsam und achten Sie darauf, dass auch init mit Unsterstützung für eine /etc/inittab enthalten ist. Es wird benötigt, um einen fast normalen Start eines Linux-Systems zu simulieren.

Gebaut und installiert wird die BusyBox ganz gewöhnlich mit make && make install. Im Verzeichnis _install im Arbeitsverzeichnis finden Sie dann das Ergebnis. Beim Bauen auf meinem uClibc-Root-Filesystem beschwerte sich BusyBox dann über den fehlenden Befehl od, woraufhin ich die Coreutils im Chroot übersetzte und od von Hand nach /usr/bin kopierte. Der nächste Versuch klappte dann problemlos.

Bauen von dropbear (SSH-Server und -Client) und rsync

Dropbear ist ein kompakter SSH-Server, -Client und ein Schlüsseltool. Er ist nicht gerade der flotteste und vielseitigste SSH-Server und arbeitet nicht richtig mit SCP und SFTP zusammen. Da unser Mini-Linux aber Rsync zum Kopieren von Dateien nutzen soll, fällt dies nicht ins Gewicht.

Den von matt.ucc.asn.au/dropbear/ heruntergeladenen Dropbear habe ich mit einem simplen

./configure --prefix=/usr/

konfiguriert. Anschließend habe ich in der Datei options.h die Quelle für Zufallszahlen angepasst:

#define DROPBEAR_RANDOM_DEV "/dev/urandom"

Beim make-Lauf sind die gewünschten Programme anzugeben:

make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" install

Die Installation resultiert in fünf Dateien:

/usr/sbin/dropbear
/usr/bin/dbclient
/usr/bin/dropbearkey
/usr/bin/dropbearconvert
/usr/bin/scp

Wie bei BusyBox handelt es sich bei Dropbear um ein Multicall-Binary, die letzten vier Dateien sind demnach nur Softlinks.

Rsync erhalten Sie unter samba.anu.edu.au/ftp/rsync/. Wir konfigurierten und bauten auf dem üblichen Weg mit:

./configure --prefix=/usr
make
make install

Sowohl rsync als auch dropbear sollten Sie mit strip von Debug-Symbolen befreien — das bringt ein paar hundert KByte Platzersparnis:

strip /usr/sbin/dropbear
strip /usr/bin/rsync

Die eigene Initrd

Wir haben nun alle benötigten Tools vorbereitet und können damit beginnen, eine Initrd zu erstellen. Die chroot-Shell sollte zunächst geöffnet bleiben während die folgenden Befehle in einer Shell im Hostsystem ausgeführt werden. Ich nutze meist klassische 4096 KByte und Ext3 als Dateisystem:

dd if=/dev/zero of=busybox-initrd.img bs=1024 count=4096
mkfs.ext3 busybox-initrd.img

Dieses Image kann nun gemountet werden:

mount -o loop busybox-initrd.img busybox-initrd

Die Initrd wird nun mit einigen grundlegenden Verzeichnissen versehen, die später benötigt werden:

mkdir -p busybox-initrd/etc/dropbear
mkdir busybox-initrd/etc/init.d
mkdir busybox-initrd/lib
mkdir busybox-initrd/bin
mkdir busybox-initrd/proc
mkdir busybox-initrd/sbin
mkdir -p busybox-initrd/usr/lib
mkdir busybox-initrd/usr/bin
mkdir busybox-initrd/usr/sbin
mkdir -p busybox-initrd/var/log
mkdir busybox-initrd/root
mkdir busybox-initrd/tmp
touch busybox-initrd/var/log/wtmp
touch busybox-initrd/var/log/lastlog

Kopieren von von busybox und rsync

Es folgt das Kopieren von busybox und Co.:

rsync -avP busybox-build/tmp/busybox-1.2.1/_install/ \
busybox-initrd/

…gefolgt vom dropbear..

rsync -avP busybox-build/usr/sbin/dropbear \
busybox-initrd/usr/sbin/
rsync -avP busybox-build/usr/bin/{dbclient,dropbearkey,dropbearconvert} \
busybox-initrd/usr/bin/

…und rsync…

rsync -avP busybox-build/usr/bin/rsync \
busybox-initrd/usr/bin/

Auflösen der Bibliotheksabhängigkeiten

Alle drei verwendeten Binaries haben Bibliotheksabhängigkeiten, die wir noch nicht berücksichtigt haben. Ermitteln Sie zunächst im chroot diese mit ldd:

ldd /tmp/busybox-1.2.1/_install/bin/busybox
ldd /usr/sbin/dropbear
ldd /usr/bin/rsync

Die gefundenen Dateien und die auf Sie zeigenden Softlinks müssen ebenfalls auf die Initrd. Bei insgesamt zehn Dateien ist dieser Vorgang überschaubar:

rsync -avP busybox-build/lib/libutil* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/libz* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/libcrypt* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/libc.* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/libuClibc* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/libgcc* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/ld-uClibc* \
busybox-initrd/lib/
rsync -avP busybox-build/lib/libm* \
busybox-initrd/lib/

Auch das /dev muss gefüllt werden. Am einfachsten ist es, das /dev des uClibc-Root-Images zu kopieren:

rsync -avHP busybox-build/dev/ busybox-initrd/dev/

Ein kleiner Check zwischendurch ergibt, dass von 4MB Ramdisk erst zweieinhalb belegt sind!

Konfiguration in /etc

Schlüssel für Dropbear

Noch fehlen die Schlüssel für den SSH-Server und die Startscripte. Ich habe sie mit dropbearkey im Chroot-System erzeugt:

dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key

Alternativ können Sie mit ssh-keygen den Schlüssel erzeugen, in die Chroot-Umgebung kopieren und dort mit dropbearconvert umwandeln. Die Schlüssel werden von außerhalb der Chroot-Umgebung auf die Initrd kopiert.

rsync -av busybox-build/etc/dropbear/ \
busybox-initrd/etc/dropbear/

Die Startscripte

Das Init der BusyBox orientiert sich am klassischen Init unter Linux und benutzt ebenfalls eine /etc/inittab. Deren Syntax ist jedoch deutlich einfacher als beim SysVinit von Linux. So steht im ersten Feld nicht die ID, sondern das Terminal auf dem der Befehl ausgeführt wird. In der ersten Zeile starte ich ein BSD-ähnliches Startscript:

::sysinit:/etc/init.d/rcS
tty1::respawn:/sbin/getty 38400 tty1
tty2::respawn:/sbin/getty 38400 tty2
tty3::respawn:/sbin/getty 38400 tty3
::ctrlaltdel:/sbin/reboot

Das Script /etc/init.d/rcS ist äußerst simpel:

#!/bin/sh
/bin/mount -t proc none /proc
/bin/mount -t devpts none /dev/pts
/sbin/ifconfig lo inet 127.0.0.1
/sbin/ifconfig eth0 inet 192.168.1.82
/bin/sleep 5
/usr/sbin/dropbear -E

Passwort- und Gruppendateien

Neben einer /etc/group…

root:x:0:

…muss eine /etc/passwd existieren…

root:x:0:0:root:/root:/bin/sh

…und eine /etc/shadow:

root:$1$zqm.tew8$To0AViNUqhJvlP13zIBKt.:10933:0:99999:7:::

Achtung: die /etc/shadow darf nur für root lesbar sein! Den Passwort-Hash habe ich mit openssl erzeugt:

openssl passwd -1

Kernel und Bootvorgang

Als Kernel verwende ich in der Regel einen sparsam konfigurierten Vanilla-Kernel. Dieser muss Unterstützung für eine Initrd und wenigstens die Dateisysteme Ext2 und Ext3 enthalten. Ratsam ist es zudem, Treiber für Netzwerkkarte und IDE-Chipsätze sowie die Dateisysteme, auf die zugegriffen werden soll, zu integrieren. Alternativ können Sie diese Treiber als Module auf die Inird packen und in der Datei /etc/init.d/rcS mit insmod laden.

Die initrd wird anschließend ausgehängt und komprimiert:

umount busybox-initrd
gzip -c busybox-initrd.img > busybox-initrd.gz

Unsere war komprimiert etwa 2,2 Megabyte groß. Zusammen mit dem Kernel ergaben sich ca. 4MB für ein komplettes Linux-Rettungssystem.

In die /boot/grub/menu.lst von Grub trugen wir die folgenden Zeilen ein:

title BusyBox Minisystem
root (hd0,0)
kernel /boot/vmlinuz-2.6.16.27 rw splash
initrd /boot/busybox-initrd.gz
boot

Bingo! Das Minisystem bootete auf Anhieb und ich konnte mich per SSH einloggen. Natürlich ist meine Konfiguration nur als Anregung zu verstehen. Um mit dem Minisystem automatisierte Restores durchzuführen, muss beispielsweise parted und ein Bootloader wie Grub oder Extlinux an Bord.

Update: 17. März 2008

Einen Artikel, der aus diesem Blog-Eintrag entstanden ist, sowie eine neue Chroot-Umgebung zum Bauen biete ich unter blog.rootserverexperiment.de/2008/03/17/neue-uclibc-chroot-umgebung-artikeldownload/ an. Bitte künftig auch die Kategorie Mini-Linux beachten.