Distrobox richtet mit einem einzigen Aufruf Linux-Systeme abgeschottet in einem Container ein. Deren grafische Umgebung kann den Bildschirm vollständig übernehmen, sodass der Eindruck eines nativ installierten Systems entsteht.

Das praktische Tool Distrobox [1] haben wir in den OpenSuse-Tipps schon Ende 2023 vorgestellt [2]. Mit ihm holen Sie sich schnell und risikolos Anwendungen aus anderen Linux-Distributionen in Ihr System (Abbildung 1). Startmenüeinträge und der im Container vorbereitete Zugriff auf das Home-Verzeichnis sorgen dafür, dass sich die Fremdprogramme wie native Anwendungen anfühlen.

Abbildung 1: Die Arduino-IDE fehlt in den OpenSuse-Repositories. Hier startet sie über eine Arch-Linux-Distrobox. Eine Funktion zum Erstellen eines Startmenüeintrags ist vorhanden.

Diese OpenSuse-Tipps erklären, wie Sie das handliche, simpel zu bedienende Tool nicht nur für die Bereitstellung einzelner Programme nutzen, sondern mit ihm die gesamte grafische Umgebung einer (fast) beliebigen Distribution auf den Bildschirm zaubern (Abbildung 2). Ihr OpenSuse-System verschwindet dabei im Hintergrund, während die Fremddistribution den Bildschirm vollständig übernimmt (Abbildung 3). Das Hostsystem auf der Festplatte bleibt unangetastet.

Abbildung 2: Ähnlich wie sich Startmenüeinträge für Anwendungen aus einer Distrobox anlegen lassen, klappt das auch für in einem Container installierte Desktop-Umgebungen.

Abbildung 3: Dass es sich hier um einen in der Distrobox tumbleweed laufenden Plasma-6-Desktop handelt, merkt man erst beim Öffnen eines Konsolenfensters.

Distrobox einrichten

Distrobox installiert die Containersysteme im Verzeichnis .local/share/containers/. Sie müssen weder die Partitionierung der Festplatte verändern, um Platz für eine neue Installation zu schaffen, noch einen neuen Bootloader installieren. Diese Art der Installation benötigt nicht einmal Root-Rechte und läuft daher völlig risikofrei. Distrobox-Installationen basieren auf sogenannten OCI-Containern [3], die es für alle gängigen Linux-Distributionen gibt. Weitere Informationen dazu finden Sie auf der Github-Seite von Distrobox und lokal in der Manpage distrobox-compatibility (man distrobox-compatibility) [4].

Ein einziger Kommandozeilenaufruf genügt, um ein Image herunterzuladen und einzurichten. Ähnlich, wie die Fremdprogramme nach Aufruf von distrobox export im Startmenü des Gastsystems erscheinen, binden Sie die Desktop-Umgebungen der per Distrobox bereitgestellten Distributionen in deren grafischen Login-Screen (Display-Manager) ein (Abbildung 2).

Unter Leap und Tumbleweed spielen Sie zunächst die Pakete distrobox und podman ein. Das Distrobox-Paket installiert Docker als Abhängigkeit, doch das Tool arbeitet besser mit dem moderneren Drop-in-Replacement Podman [5] zusammen, das Sie daher explizit installieren sollten. Nach dem Einrichten beider Pakete funktioniert alles auf Anhieb. Der gleichzeitige Start mehrerer Distrobox-Container überschreitet allerdings schnell das Limit der für einen Benutzer erlaubten Prozesse und Dateideskriptoren. Fügen Sie daher vorsorglich in der Datei /etc/security/limits.conf die Zeilen aus Listing 1 ein.

@users  soft    nproc   4096
@users  soft    nofile  4096

Zum Einrichten eines neuen Tumbleweed-Systems genügt der Aufruf aus Listing 2. Dabei geben Sie hinter -i die vollständige Internet-Adresse des von Suse bereitgestellten Container-Images ab. Für Tumbleweed-Container genügt unter OpenSuse der simple Aufruf distrobox create, weil Tumbleweed hier als Default-Image eingestellt ist. Über den Parameter -n weisen Sie dem Image einen Namen zu. Die Option -I startet Systemd im Container – viele Desktop-Umgebungen bauen inzwischen fest auf den Systemmanager.

$ distrobox create -i registry.opensuse.org/opensuse/tumbleweed:latest -n tumbleweed -I

Nach dem Einrichten gelangen Sie mit distrobox enter Name in den Container (Abbildung 4). Bei den per distrobox create installierten Images handelt es sich gewöhnlich um Minimalinstallationen. Um von dort aus eine grafische Umgebung starten zu können, müssen Sie die zunächst mit dem Paketmanager der Distribution im Container installieren.

Abbildung 4: Beim ersten Betreten einer Distrobox-Umgebung mit enter installiert das System etliche Pakete. Sehen Sie anschließend ein den Prompt kennzeichnendes Box-Symbol, hat alles geklappt.

Erscheint am Ende des Startvorgangs einer Distrobox die Meldung Error: could not set up init system, no init found!, dann entfernen Sie die Box mit distrobox rm Name und legen sie dann mit der zusätzlichen Option --additional-packages systemd neu an.

Innenausbau

Bleiben wir beim OpenSuse-System und der Desktop-Umgebung KDE Plasma: Unter Tumbleweed installieren Sie den Plasma-6-Desktop und die gesamte KDE-Umgebung auf der Kommandozeile des Tumbleweed-Containers am schnellsten mit sudo zypper in --type pattern kde.

Während mit distrobox export ein Werkzeug zum Erstellen von Startmenüeinträgen bereitsteht, müssen Sie die Einträge für Distrobox-Desktop-Umgebungen im Login-Screen manuell erstellen. Es handelt sich dabei wie bei Startmenüeinträgen um .desktop-Dateien, also Textdateien mit einem simplen Aufbau. Sie liegen im Verzeichnis /usr/share/xsessions/. Eine Datei /usr/share/xsessions/tumbleweed_kde.desktop mit dem Inhalt aus Listing 3 startet im Gastsystem einen KDE-Desktop in der Distrobox tumbleweed.

[Desktop Entry]
Name=Tumbleweed KDE
Comment=KDE in a Tumbleweed Distrobox
Exec=/usr/bin/distrobox-enter tumbleweed  -e /usr/bin/startplasma-x11
Type=Application
DesktopNames=KDE
X-GDM-SessionRegisters=true

Dabei sind Name und Comment rein deskriptive Felder. Entscheidend für die Funktionalität ist die Exec-Zeile. Sie ruft die Einwort-Variante des Befehls distrobox enter für die Box tumbleweed auf und übergibt Distrobox per Parameter -e einen Befehl, den es nach dem Hochfahren im Container-System ausführt. Er startet die X-Window-KDE-Session. Der Zugang zum X-Server auf dem Host, den Dateizugriff auf das Home, die Soundkarte und der Netzwerkzugriff werden automatisch eingerichtet.

Möchten Sie Einträge für andere Desktop-Umgebungen als KDE Plasma erstellen, dann sehen Sie sich dazu die bei der Installation der Desktop-Umgebungen angelegten Dateien im Verzeichnis /usr/share/xsessions/ in der Box selbst an. Abbildung 5 zeigt das exemplarisch für den Cutefish-Desktop [6]. Welche Oberfläche eine solche Datei startet, ergibt sich aus dem Dateinamen, notfalls lesen Sie es durch einen Blick in den Dateiinhalt nach.

Abbildung 5: In dieser Distrobox liegt nach Installation des Cutefish-Desktops die Datei /usr/share/xsessions/cutefish-xsession.desktop. Für die Integration ins Hostsystem kopieren Sie sie in dessen gleichnamiges lokales Verzeichnis und fügen der Exec-Zeile das Kommando distrobox-enter archlinux -e hinzu.

Kopieren Sie den gewünschten Startereintrag mit Root-Rechten in das lokale Verzeichnis /usr/share/xsessions/ und setzen Sie am Anfang der Exec-Zeile das Kommando /usr/bin/distrobox-enter Name -e ein. Die zahlreichen Name– und Comment-Einträge mit Länderkürzel dürfen Sie dabei löschen.

TryExec-Zeilen entfernen Sie ebenfalls. Sie testen, ob die für Exec angegebene Programmdatei vorhanden ist, und blenden ansonsten den Eintrag aus. In unserem Fall handelt es sich bei der Programmdatei um Distrobox und der Check, ob die Desktop-Umgebung installiert ist, funktioniert deshalb nicht wie gedacht. Die Direktive X-GDM-SessionRegisters=true betrifft nur den Gnome-Display-Manager GDM, schadet aber generell nicht.

Schönheitsfehler

Auf den ersten Blick unterscheiden sich die grafischen Distrobox-Umgebungen nicht von denen in nativ installierten Linux-Systemen. Das bedeutet aber nicht, dass sie sich in allen Aspekten genauso verhalten. Eine unangenehme Überraschung erlebt, wer zum ersten Mal versucht, die Bildschirmsperre einer Desktop-Umgebung aufzuheben. Selbst bei Eingabe des richtigen Passworts schlägt das fehl.

Die Passwortüberprüfung funktioniert im Container schlicht nicht wie in einem nativen System. Es bleibt nichts anderes übrig, als die Bildschirmsperre zu deaktivieren. Weiterhin verweigert Su den Dienst, dafür funktioniert Sudo ohne Passwort. Root-Rechte außerhalb der Box erlangen Sie damit nicht. Störend fällt auf, dass das Gastsystem beim Herunterfahren für 90 Sekunden hängt, falls Sie eine Distrobox nicht vorher mit distrobox stop Name abschalten.

Im Test dauerte außerdem das Starten von KDE in einer Tumbleweed-Distrobox, nicht aber von KDE in anderen Distributionen, verdächtig lange. Nach dem Start arbeitete KDE aber normal. Distrobox teilt standardmäßig das Home mit dem im Container installierten System, also auch die Einstellungen aller Programme inklusive der Desktop-Umgebung.

Nutzt man dieselben Einstellungsdateien unter $HOME/.config/ für Programme in neuerer und dann wieder älterer Version, wie es sich beim Einsatz unterschiedlicher Linux-Distribution oft ergibt, lassen sich Probleme nicht ausschließen. Allerdings bietet Distrobox dafür mit der Option --home eine Lösung an: Geben Sie darüber beim Aufruf von distrobox create ein Unterverzeichnis im Home an, setzt das in der Container-Umgebung die Umgebungsvariable $HOME entsprechend. Der Zugriff auf das Benutzerverzeichnis bleibt erhalten, doch die Konfigurationsdateien landen im angegebenen Unterverzeichnis.

Sie tun gut daran, die Desktop-Containerisierung per Distrobox als einen experimentellen Ansatz zu betrachten, der nicht für den Produktiveinsatz zu empfehlen ist – zumindest nicht als alleiniges Arbeitssystem. Da sich viele Linux-Systeme gleichzeitig sicher, ohne risikobehaftete Veränderungen an der Plattenpartitionierung oder am Bootloader einrichten lassen, lädt diese Technik aber dazu ein, nach Herzenslust zu experimentieren.

Containerterminal

Viele Linux-Anwender reagierten konsterniert auf das Gerücht, Suse könnte mit seiner Enterprise-Strategie auch die OpenSuse-Desktop-Distributionen in containerbasierter Architektur ausliefern. Für die absehbare Zukunft bleibt aber nach derzeitigem Kenntnisstand alles beim Alten. Es gibt nun lediglich als zusätzliches Angebot OpenSuse Aeon (Abbildung 6) mit MicroOS-basiertem Gnome-Desktop. Dass Aeon seit einem Jahr im Release-Candidate-Stadium festhängt, ändert nichts an der Tatsache, dass es insgesamt stabiler und praxisnäher läuft als die hier vorgestellte Einbindung via Distrobox.

Abbildung 6: OpenSuse-Aeon bindet den Gnome-Desktop – allerdings nur diesen – fest integriert und getestet per Container ein, statt auf eine experimentelle Lösung wie Distrobox zu setzen.

Wie erwähnt, arbeitet Software im Container mit praktisch nativer Performance. Es ist keine Emulation der Hardware per Software erforderlich, wie bei virtuellen Maschinen. Container benötigen keinen eigenen Linux-Kernel, sondern nutzen den des Gastsystems. Die lokale Desktop-Umgebung, die für den Löwenanteil des vom System belegten Arbeitsspeichers verantwortlich ist, muss also nicht parallel zu der aus dem Container laufen.

Sie tragen noch weiter zum Abbau des Overheads bei, wenn Sie für die Container-Laufzeitumgebung nicht ein Vollsystem wie Leap oder Tumbleweed einsetzen, sondern das schlanke MicroOS [7]. Von Haus aus sind dort die Container-Verwaltung Podman und Distrobox vorinstalliert, wenn Sie bei der Installation als Systemrolle den MicroOS Container-Host (Abbildung 7) wählen. Das gilt aber nicht für das X-Window-System und einen Display-Manager für das grafische Login.

Abbildung 7: Der MicroOS Container-Host installiert Distrobox und den Containermanager Podman vor.

Bei der Tumbleweed-Ausgabe von MicroOS [7], die das Software-Repository von Tumbleweed einbindet, lässt sich das trotz des Read-only-Root-Dateisystems nachrüsten, und zwar nach demselben Prinzip wie die automatisiert eingespielten Updates. Während der aktuelle System-Snapshot mit ausschließlichem Lesezugriff weiterläuft, legt die Systemkomponente Snapper einen neuen, vorerst beschreibbaren Snapshot an, der Aktualisierungen oder neu installierte Software aufnimmt. Erst ein Reboot aktiviert den neuen Schnappschuss dann als nur lesbares Root-Dateisystem.

Transaktionen

Das Tool, mit dem Sie einen neuen, zunächst beschreibbaren System-Snapshot anlegen, heißt transactional-update. Paketinstallationen handhabt der Unterbefehl pkg, der seine Argumente an Zypper weitergibt. Das Kommando aus der ersten Zeile von Listing 4 installiert das Metapaket für ein Grafiksystem ohne Desktop-Umgebung sowie den für den Login-Screen zuständigen Display-Manager SDDM. Den dabei auftretenden Abhängigkeitskonflikt mit Busybox-Komponenten lösen Sie durch die Option 1 auf, sprich deren Entfernung.

$ transactional-update pkg install patterns-microos-desktop-common sddm
$ systemctl set-default graphical.target
$ useradd -m -G users User
$ passwd User

Damit der grafische Login-Screen startet, rufen Sie noch den entsprechenden Systemctl-Befehl auf (zweite Zeile). Konfigurationsänderungen in /etc überleben einen Reboot. Nun legen Sie noch einen Benutzer an und setzen für ihn ein Passwort (letzte zwei Zeilen), damit Sie sich später über den grafischen Login-Screen anmelden können.

Nach dem Neustart ist ein simpler Login-Screen zu sehen (Abbildung 8), dem Sie genau wie unter Leap über .desktop-Dateien unter /usr/share/xsessions/ Einträge zum Starten der Oberflächen in den Distroboxen hinzufügen. Wegen des Read-only-Root-Dateisystems fällt dazu wieder ein Transactional Update an: Mit transactional-update shell starten Sie eine Shell für einen neuen, im Moment beschreibbaren Snapshot.

Abbildung 8: Bei dem als konsolenbasierte Container-Laufzeitumgebung konzipierten MicroOS lässt sich per Transactional Update ein grafischer Login-Screen nachrüsten.

Sie können nun Konfigurationsdateien mit Kommandozeileneditoren wie Vim oder Nano bearbeiten und dann neu booten. Vorher verlassen Sie die transactional-update-Umgebung mit exit. Sie haben jetzt ein Basissystem für per Distrobox bereitgestellte Systeme eingerichtet, das inklusive grafischer Umgebung mit einer RAM-Belegung von rund 600 MByte auskommt (Abbildung 9).

Abbildung 9: MicroOS belegt nach dem Start einer blanken X-Session ohne Fenstermanager gerade einmal gut 600 MByte RAM.

Zum Abschluss noch zwei Hinweise: Für eine Nvidia-Grafikkarte sollten Sie beim Befehl distrobox create den zusätzlichen Parameter --nvidia angeben, damit die Software in der Box die Hardwarebeschleunigung nutzen kann. Wenn die Distrobox-Kompatibilitätsliste für eine Distribution mehrere Optionen enthält, sollten Sie die Variante mit der Anmerkung Toolbox bevorzugen. Bei Toolbox [8] handelt es sich um ein ähnliches, jedoch weniger leistungsfähiges Werkzeug als Distrobox.

Fazit

Distrobox macht mit einem einzigen Kommandozeilenaufruf andere Linux-Distributionen per Container auf Ihrem OpenSuse-Desktop verfügbar. Kenntnisse zur Container-Technologie benötigen Sie dazu nicht. Obwohl sich das Tool selbst als Kommandozeilenumgebung versteht, gelingt es leicht, den gesamten Desktop einer Fremddistribution in den lokalen OpenSuse-Login-Screen zu integrieren. So richten Sie ein weiteres vollständiges Linux-System ein, ohne dass Sie Ihre Festplatte neu partitionieren oder den Bootmanager antasten müssen.(uba)