Gentoo Linux lässt sich flexibel und einfach an eigene Bedürfnisse anpassen. Diese Anleitung zeigt, wie man mit dem distributionseigenen Tool Catalyst individuelle Live-CDs herstellt.

Spätestens seit dem Erscheinen von Knoppix[1] sind Live-Distributionen in aller Munde. Kein Wunder, lassen sich diese doch vielfältig einsetzen: um Linux einfach nur mal kennen zu lernen, als Rettungssystem oder speziell angepasste Multimedia-Distribution. Für die meisten Einsatzszenarien gibt es bereits fertige Lösungen, zum Beispiel verschiedene Knoppix-Varianten, wie sie auf der Jubiläums-CD des Linux-Magazins 10/04 zu finden sind.

Wer lieber selbst Hand anlegt, sollte einen Blick auf Gentoo Linux[2] werfen, denn es bringt das praktische Tool Catalyst (Beschleuniger) mit[3], um selbst CD-Images zu schreiben. Unter anderem erzeugt der findige Benutzer damit individuelle Live-CDs.

Installation

Catalyst liegt aktuell in der stabilen Version 1.1.1 vor und lässt sich auf einem Gentoo-System inklusive aller Abhängigkeiten mit »emerge catalyst« installieren. Vorher ist allerdings eine Kontrolle zu empfehlen, ob das Use-Flag[4] »doc« gesetzt ist, sonst bleibt der Weg zu den mitgelieferten Beispielen versperrt. Dazu dient folgende Befehlszeile:

echo "dev-util/catalyst doc" >> 
  /etc/portage/package.use

Die Beispiele sind ausführlich kommentiert und bieten zurzeit die neueste Dokumentation zum Thema.

Nach erfolgreicher Installation lässt sich die Datei »/etc/catalyst/catalyst.conf« an die eigenen Bedürfnisse anpassen. Interessant sind vor allem die »options«, da sie spätere Catalyst-Läufe deutlich beschleunigen können. So aktivieren »ccache« respektive »distcc« die vom Samba-Projekt entwickelten Compiler-Erweiterungen[5].

Die Option »pkgcache« und das nicht dokumentierte »kerncache« sorgen dafür, dass Catalyst bereits übersetzte Pakete sowie Kernel-Images und -Module für eine neue Live-CD erneut verwendet und nicht noch einmal kompiliert.

Ebenfalls wichtig ist die Option »envscript«, die den Pfad zu einem Shellskript aufnimmt, in dem der Benutzer die Build-Umgebung über Variablen beeinflusst. Doch sollten Anwender ohne tiefere Kenntnisse keine Compiler-spezifischen Einstellungen ändern, da dies zu unerwünschten Effekten führen kann. Darüber hinaus gibt es mit »storedir« die Möglichkeit, Catalyst mitzuteilen, in welchem Verzeichnis es temporäre und Build-Dateien ablegen soll (Standard ist »/var/tmp/catalyst«). Listing 1 zeigt eine vollständige, von Kommentare befreite Beispielkonfiguration.

Programme kompilieren

Eine bootfähige Live-CD entsteht bei Catalyst in zwei Arbeitsschritten. Im ersten werden alle später auf der CD vorhandenen Programme übersetzt. Zuvor sind zwei Dinge erforderlich: ein fertiges Stage-3-Archiv sowie ein zuvor erstellter Snapshot des Portage Trees.

Das Stage-3-Archiv findet sich auf einem der zahllosen Spiegelserver[6]. Es enthält ein vorkompiliertes Basissystem, das man um die ausgewählten Pakete erweitert. Beide bilden die Grundlage des Live-CD-Dateisystems. Um sicherzustellen, dass das Endprodukt auf vielen Systemen läuft, empfiehlt es sich, ein generisches Stage-Archiv zu verwenden, das für x86 oder i686 kompiliert wurde. Wer mehr Wert auf Optimierungen als auf Kompatibilität legt, kann aber natürlich auch auf spezielle Stages für Pentium 4 oder Athlon XP zurückgreifen. Den ebenfalls benötigten Schnappschuss des Trees erstellt Catalyst auf Wunsch:

catalyst -C target=snapshot 
  snapshot=Datumsstempel 
  portdir_overlay=$PORTDIR_OVERLAY

Abbildung 1: Das Paket »livecd-tools« enthält praktische Applikationen wie das im Bild gezeigte »net-setup«.

Dabei handelt es sich lediglich um einen Tarball von »/usr/portage« und ein eventuell vorhandenes Overlay, das für die nötige Konsistenz der Build-Umgebung sorgt. Diese ist bei einem Live Tree nicht unbedingt gegeben. Sind diese zwei Voraussetzungen erfüllt, ist es an der Zeit, ein so genanntes Spec-File zu schreiben, das die für den Build-Prozess relevanten Optionen enthält. Listing 2 zeigt ein gekürztes Beispiel.

Dabei kann der Benutzer gleich »/usr /share/doc/catalyst-Version/examples/livecd-stage1_template.spec« an eine geeignete Stelle kopieren und an die eigenen Anforderungen anpassen. Diese Datei ist vorbildlich dokumentiert, deshalb hier nur ein kurzer Überblick.

Die Variablen »subarch« und »version_stamp« sind ohnehin selbsterklärend, als »target« muss in diesem Schritt »livecd-stage1« ausgewählt sein. Für die Option »profile« empfiehlt es sich, kaskadierende Profile[7] einzusetzen, da diese – falls nötig – einfach an eigene Bedürfnisse anzupassen sind. Entscheidend für die Funktionalität der fertigen Live-CD sind die Variablen »livecd/use« und »livecd/packages«, die Use-Flags und Pakete enthalten. Hier sind der eigenen Phantasie nur durch den limitierten Speicherplatz auf dem verwendeten Medium praktische Grenzen gesetzt – natürlich lassen sich mit Catalyst auch Live-DVDs erstellen.

Man sollte darauf achten, das Use-Flag »livecd« zu aktivieren und »baselayout« in die Paketliste mit aufzunehmen. Baselayout wäre im Stage-3-Archiv zwar eigentlich schon enthalten, muss aber neu kompiliert werden, um es für die später verwendete Chroot-Umgebung vorzubereiten. Darüber hinaus ist auch noch das Paket »livecd-tools« zu empfehlen, das praktische Werkzeuge wie »net-setup« (siehe Abbildung 1) zur Verfügung stellt.

Für den Endbenutzer richtig komfortabel wird die eigene Live-CD mit der Installation von »hwdata-knoppix« und »kudzu-knoppix«. Die beiden Pakete sorgen im Zusammenspiel mit »coldplug« für die von Knoppix gewohnte gute Hardware-Erkennung. Soll von der CD auch ein X-Server laufen, sind noch »ddcxinfo-knoppix« und »mkxf86config« eine gute Wahl.

Ist er mit der endgültigen Paketauswahl zufrieden, startet der Buildvorgang mit dem Kommando »catalyst -f /Pfad/zu/ livecd-stage1.spec«, der durchaus einige Zeit in Anspruch nimmt.

Anpassungen

Ging beim ersten Schritt alles glatt, findet sich unterhalb von »$storedir/tmp/default/livecd-stage1-x86-$snapshot<$>« die Verzeichnishierarchie der späteren Live-CD. Im nun folgenden Schritt kommt der eigentliche Zauber von Catalyst zur Geltung: Es übersetzt im selben Ablauf nicht nur den Bootloader und den Kernel inklusive seiner Module, sondern führt auch eine Vielzahl benutzerdefinierter Anpassungen durch. Abschließend komprimiert Catalyst das neu angelegte Dateisystem mittels »zisofs«, SquashFS oder »cloop«. Dann schreibt es ein ISO-Image, das nurmehr darauf wartet, gebrannt zu werden.

Da dies der Arbeitsschritt ist, der die Live-CD den eigenen Bedürfnissen anpasst, sollen die interessantesten Optionen an dieser Stelle etwas ausführlicher vorgestellt werden. Ein entsprechendes Spec-File findet sich aus Platzgründen auf dem Server des Linux-Magazins[8]. Es definiert bestimmte Werte aus der »livecd-stage1.spec« erneut, denn Catalyst vergisst die dort aufgeführten Kommandozeilen-Argumente nach der Ausführung sofort wieder. Der Wert von »source-subpath« muss den relativen Pfad zu dem im ersten Schritt erzeugten Dateisystem enthalten. Das Target selbst wird selbstverständlich auf »livecd- stage2« gesetzt.

Individuelle Startskripte

Die Option »livecd/cdfstype« bestimmt die Komprimierungsmethode. Mit anderen Optionen lassen sich das Bootsplash-Bild (Abbildung 2, es muss als »/etc/bootsplash« des Stage 1 vorliegen) sowie eine eventuell vorhandene Willkommensnachricht (»livecd/motd«) konfigurieren. Interessanter als diese rein kosmetischen Änderungen sind »live/ rcadd« respektive »livecd/rcdel« für die Runlevel-Konfiguration. Wer mehr über das von Gentoo Linux verwendete Init-System wissen möchte, wird im Handbuch[9] fündig.

01 distdir="/usr/portage/distfiles"
02 options="ccache pkgcache kerncache"
03 sharedir="/usr/lib/catalyst"
04 storedir="/tmp/catalyst"
05 envscript="/root/livecd/catalyst-env.sh"

01 subarch: x86
02 version_stamp: katalysator
03 target: livecd-stage1
04 rel_type: default
05 profile: default-linux/x86/2004.3
06 snapshot: 20041218
07 source_subpath: default/stage3-x86-2004.3
08 
09 livecd/use:
10         -arts
11         -gnome
12         -kde
13         -perl
14         -python
15         -qt
16         -ruby
17         X
18         crypt
19     livecd
20         [zusätzliche USE-Flags]
21 
22 livecd/packages:
23         app-admin/sudo
24         aumix
25         baselayout
26         beep-media-player
27         bootsplash
28         bootsplash-themes-livecd
29         coldplug
30         dhcpcd
31         livecd-tools
32         [zusätzliche Pakete]

Außerdem lässt sich über »livecd/xinirtc« ein Startskript für den X-Server einstellen. Das Schweizer Taschenmesser für die Live-CD-Personalisierung ist das Shellskript »livecd/fsscript.sh«. Listing 3 zeigt (angepasste) Auszüge des von Gentoo-Entwickler Tobias Scherbaum erstellten Skripts für die Gentoo-Live-CD Fizzle Wizzle[10], die bei der Linux World Expo 2004 in Frankfurt verteilt wurde.

Interessant ist auch die Möglichkeit, in »livecd/overlay« ein Verzeichnis spezifizieren zu können, dessen Dateien und Verzeichnisse später auf der Live-CD unter »/mnt/cdrom« zu finden sind. Die Installationsmedien von Gentoo Linux nutzen diese Methode beispielsweise, um den Benutzern Dokumentationen zur Verfügung zu stellen.

cp -L /etc/resolv.conf /mnt/gentoo/etc
mount -t proc none /mnt/gentoo/proc

Dateien überlagern

Der nächste Abschnitt des Spec-File widmet sich verschiedenen Aspekten der Kernelkompilierung mit »genkernel«[11]. Nachdem in »boot/kernel« beliebig viele Kernelimages aufgeführt sein dürfen, ist jedes nach dem Schema »boot/ kernel/Kernelname/Option« konfigurierbar. So hat der Anwender Einfluss auf die zu verwendenden Kernelquellen, die Konfigurationsdatei sowie Kernel-spezifische Use-Flags.

Wer ein möglichst breites Hardwarespektrum abdecken möchte, sollte einen generischen Kernel inklusive vieler Module erstellen. Im Zusammenspiel mit »coldplug« und der von Knoppix geborgten Hardware-Erkennung, ist die eigene Live-CD auf einer Vielzahl von Systemen lauffähig. Danach gibt man in »livecd/ unmerge« all jene Pakete an, die Catalyst vor dem Erstellen des ISO-Image wieder deinstalliert.

Dafür bieten sich unter anderem die GNU Autotools oder GCC an, da diese auf einem Live-System nur von bedingtem Nutzen wären. Zum finalen Großreinemachen bläst schließlich »livecd/rm«, das beispielsweise bei der Installation angelegte Log-Dateien entfernt. Hat der CD-Autor das Spec-File endlich an die eigenen Wünsche angepasst, startet er mittels »catalyst -f livecd-stage2.spec« den endgültigen Build-Vorgang. Das fertige ISO-Image liegt danach unter »/tmp /my-livecd.iso«.

Zugabe

Wer dachte, das sei schon alles, irrt. Denn Catalyst lässt sich auch für eine ganze Reihe anderer Aufgaben verwenden. So wird es nicht nur eingesetzt, um Portage-Snapshots und Stage-Archive für die Gentoo-Linux-Installationsmedien zu erzeugen. Mit dem Target »netboot« erstellt es zum Beispiel Netboot-Images. Über »tinderbox« ist es möglich, eine Build-Umgebung für die Qualitätssicherung zu implementieren, die jedes spezifizierte Paket in einer Chroot-Umgebung kompiliert und ein Buildlog anlegt. Das stellt sicher, dass ein Ebuild alle Abhängigkeiten enthält, um in einem frischen Stage-3-System installiert zu werden.

Abschließend sei noch darauf hingewiesen, dass es zusätzlich zur Dokumentation ([12],[13]) eine Mailingliste für Catalyst gibt, die Interessierte mit einer leeren E-Mail an die unter[14] angegebene Adresse abonnieren. (ofr/csc)

01 useradd -g users -G wheel,portage -m gentoo
02 
03 echo "tmpfs     /usr/X11R6/lib/X11/xkb/compiled tmpfs defaults 0 0" >> /etc/fstab
04 
05 ln -sf /usr/share/zoneinfo/Europe/Vienna /etc/localtime
06 
07 mkdir -p /home/gentoo/
08 cat > /home/gentoo/.xinitrc << EOF
09 exec ion3 &> /dev/null
10 EOF
11 
12 chown -R gentoo:users /home/gentoo
13 
14 echo "gentoo ALL=NOPASSWD:/bin/su" > /etc/sudoers
15 echo "echo "Um Root-Rechte zu erlangen geben Sie  'sudo su -' ein."" > /home/gentoo/.bash_profile
16 chown gentoo:users /home/gentoo/.bash_profile