Aus einem Arch-Linux-System heraus bauen Sie ein Live-Linux nach Ihren Vorstellungen, samt grafischer Oberfläche und praktischer Tools.

Arch-Linux-Installationen entstehen mithilfe einer Live-Disk [1], die sich gleichzeitig als Rescue-Medium nutzen lässt. Doch getreu dem Motto “Keep it simple, stupid” (KISS [2]) verzichtet das Arch-Installationsmedium zugunsten der Flexibilität auf eine grafische Oberfläche. Mit Gparted (Abbildung 1) geht das Partitionieren der Festplatten aber intuitiver von der Hand. Auch die Gefahr, per “fat finger” bestehende Daten ins Jenseits zu befördern, ist in diesem übersichtlichen Programm geringer als beim Tippen der Partitionsnamen.

Abbildung 1: Arch Linux verzichtet auf eine grafische Installationsumgebung. Viele Anwender wünschen sich jedoch schon alleine für das Partitionieren der Festplatte Tools wie hier Gparted.

Arch Linux wäre nicht Arch Linux, wenn es nicht auch die zur Distibutionspflege genutzten Tools wie Archiso, das Skript zum Erstellen der offiziellen Images, veröffentlichen (gleichnamiges Paket im extra-Repository) und vor allem im Wiki ausführlich dokumentieren würde [3]. So kann sich jeder seine eigenen Live-Medien zusammenstellen. Arch-typisch ist auch, dass der Vorgang auf recht simplen Bash-Skripten beruht, statt auf einer komplizierten Infrastruktur wie beim OpenSuse-Live-Image-Tool Kiwi [4].

Archiso lässt sich nicht nur für Installationsmedien mit ein paar zusätzlichen Paketen nutzen: Das Projekt DidJiX [5] baut mit seiner Hilfe zum Beispiel eine DJ-Arbeitsumgebung als Live-Disk (Abbildung 2). Das Werkzeug erlaubt, beliebige Arch-Linux-Pakete in ein ISO-Image zu packen – auch selbst gebaute. Ebenso mühelos bauen Sie eigene Konfigurationsdateien ein, sei es systemweit in /etc oder im Home. Administrative Befehle wie systemctl enable sshd zum Aktivieren des SSH-Diensts schreiben Sie einfach in ein bei jedem (Neu-)Bau des Images ablaufendes Skript.

Abbildung 2: Das Projekt DidJiX baut auf der Basis von Archiso eine DJ-Umgebung, die – unabhängig vom Zustand beim Herunterfahren – jedes Mal mit der gleichen Fensteranordnung startet.

Wahrscheinlich fragen Sie sich, warum Sie stattdessen nicht einfach eine normale Arch-Linux-Installation auf einem USB-Stick einrichten sollten. Das gelingt zwar problemlos, doch es gibt ein paar Gründe, warum das Live-System die bessere Lösung sein kann: Normale Linux-Systeme schreiben große Datenmengen auf das Speichermedium, zumindest, wenn Sie das nicht durch den Einsatz von Tmpfs abmildern. Das Live-System dagegen nutzt von Haus aus das Overlay-Filesystem [6] aus dem Read-only-Dateisystem und ein im RAM liegendes Tmpfs.

Praktisches Sandwich

USB-Sticks enthalten in aller Regel preiswerte Flash-Chips, die sich nur bedingt für den Dauerbetrieb als Root-Dateisystem eignen. Darum empfiehlt es sich, länger laufende Systeme auf einem ausgewachsenen Datenträger wie einer Festplatte oder einer SSD einzurichten. Bei ausschließlich lesbaren CD-ROMs oder DVDs stellt sich die Frage gar nicht erst.

Das Live-System greift nur lesend auf den Stick zu: Alle Schreibvorgänge landen im RAM – das begrenzt allerdings die maximale Datenmenge. Dafür startet das System beim nächsten Booten zuverlässig wieder genauso, wie Sie es bei der Image-Erstellung vorbereitet haben, was beispielsweise dem DJ in DidJiX seine gewohnte Fensteranordnung garantiert. Freuen wird es ihn auch, dass er das System nicht beschädigt, wenn er am Ende einer langen Disco-Nacht einfach den Stecker zieht. Auch für den Raspberry Pi, der zumindest in der Plus-Version leicht von gewöhnlichen USB-Mass-Storage-Geräten bootet [7], wäre diese Robustheit oft wünschenswert.

Es ist klar, dass sich ein Read-only-System nicht mit pacman -Syu aktuell halten lässt. Doch es kostet nur einen Aufruf des Build-Skripts, um mit einer vorbereiteten Konfiguration ein neues ISO mit aktuellen Paketen zu backen. Mithilfe von Dd geht es sogar schneller, es auf mehrere USB-Sticks zu verteilen, als jede Installation gesondert zu aktualisieren [8].

Zum Konfigurieren der Live-Umgebung genügen drei Schritte: Editieren der Liste der installierten Pakete, Anlegen eines skel/-Ordners mit den (Konfigurations-)Dateien im Home-Verzeichnis und das Eintragen der Shell-Befehle, die beim Starten ablaufen sollen, in einem Skript.

Im Standard-Repository

Als ersten Schritt zu Ihrem eigenen Live-Medium installieren Sie zunächst im Arch-Linux-Arbeitssystem das Paket archiso. Es enthält zwei vorkonfigurierte Profile mit den Namen baseline und releng. Baseline liefert ein minimales System, das sich nicht wie hier beschrieben modifizieren lässt. Die beiden Profile stehen als Verzeichnisse unter /usr/share/archiso/configs bereit.

Releng kommt unmodifiziert zum Erzeugen der offiziellen Installationsmedien zum Einsatz. Standardmäßig findet beim Start ein Root-Login statt, was für die Installations- und Rettungsdisk passt. Bei Bedarf lässt sich das Auto-Login abschalten oder in ein normales Benutzer-Login umwandeln [9].

Als simples Beispiel wollen wir eine erweiterte Installations-Disk mit GParted zur Festplattenpartitionierung erzeugen. Das System soll automatisch eine grafische Umgebung mit einem GParted- und einem Konsolenfenster starten, und zwar als Root – auf einem Read-only-System ist das akzeptabel.

Kopieren Sie dazu zuerst den Inhalt des Verzeichnisses /usr/share/archiso/configs/releng in einen Arbeitsordner. Da Sie die Disk-Images als Root erstellen, wählen Sie am besten ein Verzeichnis außerhalb der Homes, damit beispielsweise Ihr Backup nicht über fehlende Zugriffsrechte stolpert.

Dann fügen Sie der Datei packages.x86_64 im releng-Ordner die Einträge aus Listing 1 hinzu, jeweils in einer eigenen Zeile. Bei xorg, xorg-drivers und xfce4 handelt es sich um Paketgruppen, die neben der X-Server-Umgebung auch alle verfügbaren Video-Treiber sowie den Grundbestand der Desktop-Umgebung XFCE installieren.

xorg
xorg-drivers
xorg-xinit
xfce4
gparted

Die Liste mit Paketnamen dient beim Erstellen des Images als Eingabe für einen Aufruf des Paketmanagers Pacman. Abhängigkeiten wählt der Paketmanager also automatisch, Paketgruppen funktionieren wie gewohnt. Wegen der Aufrufoption --noconfirm im Build-Skript kommt bei Letzteren immer die Standardvorauswahl zum Zuge.

Bei Bedarf können Sie eine ganz eigene Paketsammlung zusammenstellen, statt wie im Beispiel nur einige Pakete hinzuzufügen. Die Pakete der Gruppe base installiert ein vorausgehender Pacman-Aufruf unabhängig von der Liste. Alle Änderungen im releng-Ordner müssen Sie als Root vornehmen, sonst kann es laut Wiki beim Erstellen der Abbilddatei zu falschen Dateirechten kommen.

Autostart

Die Installation der grafischen Umgebung allein startet sie noch nicht. Um XFCE direkt beim (Auto-)Login hochzufahren, tragen Sie den Befehl startxfce4 in eine Shell-Profil-Datei ein. XFCE aktiviert dabei auch den X-Server, falls er noch nicht läuft. Die Installationsdisk nutzt die Z-Shell. Ein Login-Skript .zlogin für diese Shell liegt im Verzeichnis releng/airootfs/root/. Dort ist in der ersten Zeile bereits ein Skript eingetragen. Fügen Sie dieser Datei am Ende den Aufruf exec startxfce4 hinzu.

Nun startet XFCE beim Booten der Live-Umgebung ohne Benutzerinteraktion (Abbildung 3). Der XFCE-Desktop hat jedoch die Eigenart, beim ersten Start zu fragen, ob er eine leere Desktop-Leiste anlegen oder die Standardkonfiguration übernehmen soll. Um diese Frage zu unterdrücken, müssen die XFCE-spezifischen Konfigurationsdateien im Home-Verzeichnis vorliegen, in unserem Fall also in /root. Die Konfigurationsdateien für normale Benutzer gehören dann in das Verzeichnis releng/airootfs/root/etc/skel, das Sie erst anlegen müssten.

Abbildung 3: Ohne weitere Konfiguration startet XFCE zwar beim Booten, nervt aber mangels vorheriger Konfiguration mit einer Frage nach der Default-Einstellung.

Wenn Sie XFCE auch auf Ihrem Arbeitsrechner nutzen, kopieren Sie die Ordner .config/xfce4 und ./config/Thunar aus Ihrem Home ins Verzeichnis releng/airootfs/root/. Ansonsten bietet es sich an, das Live-Medium jetzt erst einmal zu erstellen und zum Testen in einer virtuellen Maschine zu starten, egal, ob KVM oder VirtualBox.

Dazu genügt es, aus dem Ordner releng heraus ./build.sh -v aufzurufen. Dank der Option -v sehen Sie, womit sich das Skript gerade beschäftigt: Zuerst installiert es die Paketgruppe base in ein Chroot, dann die Pakete aus packages.x86_64. Nach der Installation ruft es das Skript releng/airootfs/root/customize_airootfs.sh auf.

Wenn Sie es in einem Editor betrachten, sehen Sie, dass es einige Konfigurationsdateien verändert, locale-gen aufruft sowie ein Systemd-Unit aktiviert und das Systemd-Default-Target auf multi-user setzt. Daran lässt sich erkennen, wozu das Skript gedacht ist: Jede administrative Aufgabe, die Sie hier eintragen, findet im Chroot statt, aus dem build.sh später das Root erzeugt.

Aktivieren Sie hier eine Systemd-Unit, dann startet sie beim Booten der Live-Umgebung. Legen Sie hier mit useradd -m Name einen Benutzer an, dann existiert er im Live-System und besitzt ein Home-Verzeichnis mit den Dateien aus /etc/skel. Auch das zugehörige Password können Sie hier setzen.

Möchten Sie einen Vorgang während des Bootens der Live-Umgebung starten, dann legen Sie in releng/airootfs/etc/systemd/system eine entsprechende Systemd-Unit an und aktivieren sie im Skript mit systemctl enable meine-unit.service [10].

Backautomat

Dass Shell-Profil-Dateien in Zusammenhang mit dem Auto-Login ebenso zum automatischen Starten von ausführbaren Dateien taugen wie eine Systemd-Unit, sehen Sie, sobald Sie das vom Build-Skript erstellte ISO-Image booten. Bevor es fertig vorliegt, muss build.sh jedoch noch ein komprimiertes SquashFS-Dateisystem erstellen (was die CPU ein wenig fordert) sowie das Ergebnis in einem ISO-Image verewigen. Letzteres finden Sie dann, sofern alles geklappt hat, im Ordner releng/out.

Nach dem Start des selbst erstellten Live-Systems schließen Sie erst einmal die Meldung Welcome to the first start of the panel. Anschließend erstellt XFCE im Verzeichnis .config einige Konfigurationsdaten. Starten Sie dann den Settings-Manager, und öffnen Sie das Modul Session and Startup. Im Reiter Application Autostart fügen Sie xfce4-terminal sowie gparted hinzu und melden sich ab. Das Auto-Login meldet Sie sofort wieder an, GParted und das Terminal sollten nun starten (Abbildung 4). Kopieren Sie jetzt das Verzeichnis .config/ aus dem Root per Scp nach releng/airootfs/root/, um dasselbe Verhalten in die Live-Umgebung zu übertragen.

Abbildung 4: Nach dem Integrieren des Ordners .config/ in die Live-Umgebung startet XFCE unterbrechungsfrei und öffnet auch gleich per Autostart das XFCE-Terminal und Gparted.

Um das ISO-Image erneut zu erstellen, genügt es allerdings nun nicht, lediglich erneut das build.sh-Skript aufzurufen. Um das ISO zuverlässig in allen Szenarien neu zu bauen, müssen Sie vorab das Verzeichnis releng/work löschen. Das zwingt Archiso zwar, erneut alle Pakete ins Chroot zu installieren, doch der in der Regel einige Minuten dauernde Vorgang kommt ohne Benutzerinteraktion aus. Auch benennen Sie am besten das bestehende ISO in releng/out/ um.

Fazit

Der Live-System-Generator Archiso bietet drei Ansatzpunkte für Anpassungen, nämlich die Paketliste packages.x86_64 sowie die systemweiten beziehungsweise Benutzer-Konfigurationsdateien in /etc oder /etc/skel/. In das Skript customize_airootfs.sh tragen Sie dieselben Shell-Befehle ein, die Sie zur Administration auch auf Ihrem lokalen System ausführen würden, wie etwa useradd zum Hinzufügen eines Benutzers oder systemctl enable Dienst zum Aktivieren eines Diensts.

Um die Konfigurationsdateien für eine bestimmte Konstellation in einer grafischen Umgebung zusammenzustellen, starten Sie am einfachsten diese (Desktop-)Umgebung auf Ihrem Arbeitsrechner oder in einer virtuellen Maschine. Dann brauchen Sie nur noch die Unterverzeichnisse .config und eventuell share in den skel-Ordner der Archiso-Umgebung zu kopieren, um sie in das Live-System zu übertragen.

Live-Systeme zeichnen sich dadurch aus, dass sie immer wieder exakt gleich hochfahren, egal, wie (und ob) Sie sie heruntergefahren haben. Handlich verpackt in eine ISO-Datei, lassen sie sich schnell auf mehrere Speichermedien verteilen. Images mit aufgefrischten Paketen, aber derselben Konfiguration zu erstellen, kostet Sie nur den Aufruf des Build-Skripts und einige Minuten Wartezeit.