Der Umstieg auf Linux ist nach dem Support-Ende von Windows 10 ein gefragtes Thema. OpenSuse macht Wechselwilligen ein attraktives Angebot: Suse Aeon bietet ein System, das sich ohne Benutzereingriff selbst aktualisiert.

Die Chancen, neue Anwender zu gewinnen, stehen für Linux im Moment gut. Zumindest sucht mancher Windows-10-Benutzer, der seit einigen Monaten ohne Support dasteht, ein neues Betriebssystem. Ein oft gehörter Kritikpunkt an Linux lautet, dass es User mit zu vielen Auswahlmöglichkeiten überfordert. Bei OpenSuse Aeon [1] ist das nicht der Fall. Es bietet ausschließlich den aktuellen Gnome-Desktop aus Tumbleweed (Abbildung 1), derzeit in Version 49.4 [2]. Der Installer fragt nach der Festplatte für die Installation (Abbildung 2), sonst sind keine weiteren Eingaben nötig.

Abbildung 1: Der Gnome-Desktop von Aeon ist identisch mit dem von Tumbleweed. Sein Dock enthält nach der Installation jedoch weniger Programmstarter.

Abbildung 2: Der Aeon-Installer stellt bei der Installation nur die Frage, auf welcher Platte er das System installieren soll. Er löscht stets das ganze gewählte Speichermedium.

Beim ersten Start gilt es, Sprache und Zeitzone zu wählen. Wie Windows lädt Aeon Updates für das Grundsystem automatisch im Hintergrund herunter und empfiehlt einen Neustart, ohne ihn zu erzwingen (Abbildung 3). Die Softwareinstallation erfolgt über einen grafischen Software-Store (Abbildung 4). Von der bemängelten “Frickelei” unter Linux findet sich hier keine Spur.

Abbildung 3: Der Aeon-Installationsdienst holt täglich Updates ab und weist auf einen demnächst angebrachten Neustart hin.

Abbildung 4: Unter Aeon ist der Gnome-Software-Store so konfiguriert, dass er ausschließlich distributionsübergreifende Flatpak-Pakete vom zentralen Repository Flathub installiert.

Systemaktualisierungen laufen atomar ab. Bricht ein Update-Vorgang aus irgendeinem Grund vorzeitig ab, dann verwirft das System die Veränderungen und behält den Zustand vor dem Update bei. Falls das System nach einem Update nicht mehr vollständig startet, erfolgt ebenfalls automatisch eine Rückkehr zum letzten funktionierenden Zustand.

Die Parallelen zu Smartphone-Systemen gehen noch tiefer: Das Grundsystem ist gegen Änderungen geschützt, wenngleich nicht durch einen fehlenden Root-Account, sondern durch ein nur lesbar eingehängtes Dateisystem. Updates spielt Aeon in einen neuen System-Snapshot ein, den erst ein Neustart aktiviert.

Problemlos

Diese Vorgehensweise schließt Probleme mit Aktualisierungen, die durch Eingriffe an den Systembibliotheken die laufende Desktop-Umgebung zum Absturz bringen – und damit auch das Konsolenfenster, in dem das Upgrade läuft – kategorisch aus.

Eine manuelle Rückkehr zu früheren Systemzuständen klappt jederzeit, falls durch ein Upgrade verursachte Probleme erst nach einiger Zeit zutage treten. Dazu genügt es, beim Booten die Leertaste gedrückt zu halten und einen der im Bootmenü (Abbildung 5) angezeigten Snapshots auszuwählen. Funktioniert im gewählten Systemzustand alles wie gewünscht, macht das Kommando sudo transactional-update rollback ihn zur aktuellen Variante, die dann ohne manuelle Auswahl startet.

Abbildung 5: Selbst wenn der Bootvorgang in einer frühen Phase hängenbleibt, können Aeon-Anwender im Bootmenü einen älteren, noch funktionierenden Snapshot auswählen.

Die eingebaute Selbstheilung hilft Anwendern, die sich das Zurückspielen eines alten Systemzustands per Auswahl im Bootmenü und Konsolenbefehl nicht zutrauen. Es entlastet aber auch die Nerven von alten Hasen, die sich, wenn die Zeit für eine wichtige Aufgabe ohnehin drängt, gleichfalls nicht mit einem manuellen Restore herumschlagen müssen.

Primär installieren Aeon-Anwender Software per Flatpak aus dem zentralen Flathub-Repository [3]. Dazu genügt ein Klick auf Installieren im grafischen Software-Store Gnome Software (Abbildung 4). Dafür ist bereits alles vorkonfiguriert. Wer Apps auf seinem Smartphone installiert, kommt auch damit sofort zurecht. Die Installation erfolgt mit Benutzerrechten. Flatpak installiert jedes Paket in einen eigenen Container. Das schließt aus, dass eine Installation eines Pakets eine andere Software oder gar das System zerstört.

Dass Aeon für die Installation von Anwendungen durch den Benutzer auf Flatpaks setzt, bringt jedoch auch Nachteile mit sich. Zunächst fällt auf, dass die Installation deutlich länger dauert als bei nativen OpenSuse-Paketen. Zudem fällt das Download-Volumen oft um ein Vielfaches größer aus, weil Flatpak-Pakete ihre Abhängigkeiten nicht mit anderen Paketen teilen. Flatpak-Programme deduplizieren lediglich Basispakete wie die Laufzeitumgebungen der Desktops – immerhin die umfangreichsten Abhängigkeiten.

Aeon installiert Flatpaks mit Benutzerrechten, was wegen des Read-only-Root-Dateisystems obligatorisch ist. Das bedeutet jedoch, dass alle nachinstallierten Anwendungen nur für ein Benutzerkonto zur Verfügung stehen. Die dadurch nötige Mehrfachinstallation jeglicher Software schränkt die Tauglichkeit von Aeon als Mehrbenutzersystem ein.

Der Vorteil: Kommt es nach einem Upgrade eines Flatpak-Pakets, das Gnomes Software-Store automatisch vornimmt, zu Problemen, bleiben die aufgrund der Container-Architektur von Flatpak immer auf ein Programm beschränkt. Die Entkopplung der Flatpaks von einer bestimmten Distribution macht es zudem unwahrscheinlich, dass ein Problem ausschließlich unter OpenSuse Aeon auftritt. Das sollte das Auffinden und Beheben des Bugs beschleunigen.

Nacharbeiten

Dennoch ist es unverständlich, dass Gnome Software zwar die Versionshistorie eines jeden Flatpak-Pakets anzeigt, es aber nicht gestattet, auf eine ältere Version zurückzukehren. Das wäre technisch durchaus möglich, jedoch nur auf der Konsole, was schlecht zum Konzept des einsteigertauglichen Softwareladens passt.

Auf der Konsole fragt flatpak list alle auf dem System installierten Flatpak-Pakete ab. Neben einem Programmnamen ist jedem Paket eine Anwendungskennung zugewiesen. Für das grafische Distrobox-Verwaltungsprogramm BoxBuddy lautet sie beispielsweise io.github.dvlv.boxbuddyrs.

Der Aufruf aus der ersten Zeile von Listing 1 listet vier Commits, sprich auf Flathub veröffentlichte Versionen, mit einer kurzen Beschreibung der Änderungen (Abbildung 6). Hinzu kommt ein langer, den Commit identifizierender Hash-Wert. Übergeben Sie diesen Hash über den Parameter --commit=Hash dem Kommando flatpak update, dann installieren Sie statt der aktuellsten die so gekennzeichnete Version. Die letzte Zeile des Listings zeigt den entsprechenden Aufruf für die BoxBuddy-Version vom September 2025.

# flatpak remote-info --log flathub io.github.dvlv.boxbuddyrs
# flatpak update --commit=d44fa754f9d12983ec5b5b3515129276cee3f2ea6822baa370af2ae1fa50effc io.github.dvlv.boxbuddyrs

Abbildung 6: Der Gnome-Software-Store zeigt zwar im Flathub-Repository vorhandene Versionen der Pakete, für ältere Versionen steht ein Rückgriff auf die Konsole an.

Wie vernagelt

Auf den ersten Blick wirkt Aeon wie ein System, das seine Anwender an die kurze Leine nimmt: Einerseits überfordert es Anwender mit beschränktem technischen Wissen nicht durch Auswahlmöglichkeiten, andererseits lässt es aber wenig Gestaltungsspielraum. Das gilt jedoch nur für das Grundsystem mit der Desktop-Umgebung, das durch ein Read-only-Dateisystem vor Experimenten abgeschottet ist. Die benutzerfreundliche Containerverwaltung Distrobox [4] gehört jedoch gleichfalls fest zu Aeon.

Distrobox gestattet es, mit einem einzigen Konsolenbefehl eine Minimalversion fast beliebiger Linux-Distribution in einem Container einzurichten. Dort lassen sich dann alle Programme aus den Repositories dieser Distribution installieren. Die Fenster der isoliert vom Grundsystem installierten Anwendungen erscheinen in nativer Performance auf dem Desktop und lassen sich sogar direkt in das Startmenü des Gastsystems einbinden (Abbildung 7). Sie können damit direkt auf das Home des Gastsystems zugreifen.

Abbildung 7: Distrobox exportiert mit einem einfachen Kommandozeilenaufruf die im Container installierten Programme in das Startmenü von Aeon.

Haben Sie einige Gigabyte Plattenspeicherplatz übrig, können Sie dank des im Grundsystem von Aeon integrierten Distrobox mit verschiedenen Linux-Distributionen und der Installation experimenteller Software vom Build-Service nach Lust und Laune experimentieren. Das Grundsystem gerät dadurch nicht in Gefahr.

Ohne weitere Parameter aufgerufen, erzeugt distrobox create unter Aeon einen Tumbleweed-Container, denn Tumbleweed ist hier als Standardsystem konfiguriert. Die Eingabe distrobox enter öffnet dessen Kommandozeile zum Installieren und Starten von Programmen. Im per distrobox create erzeugten Rumpfsystem fehlt eine grafische Paketverwaltung. Zunächst gelingt die Installation von Software dort nur mit dem Kommandozeilenaufruf sudo zypper in Paket. Das ändert sich jedoch nach der Installation der grafischen Paketverwaltung Myrlyn mit sudo zypper in myrlyn (Abbildung 7).

Normalerweise lassen sich Kommandozeilen- und grafische Programme einfach mit ihrem Namen an der Distrobox-Konsole aufrufen. Der Start eines Programms mit Root-Rechten, wie es für die Paketverwaltung erforderlich ist, erfordert jedoch mehr. Die einfachste Lösung besteht darin, aus Distrobox heraus distrobox-export -a myrlyn aufzurufen: Dann erscheinen die Einträge Myrlyn (on tumbleweed) und Myrlyn (readonly on tumbleweed) im Startmenü des Gastsystems.

Beim Start von Myrlyn mit administrativen Rechten fragt es wie Sudo in einem Distrobox-Container nicht nach einem Root-Passwort: Es agiert ja nicht auf Systemebene, sondern nur in einem mit Benutzerrechten laufenden Container. Generell exportiert distrobox-export die von den Paketen vorgesehenen Startmenüeinträge, im Fall von Myrlyn eine Variante mit und eine ohne Administrationsrechte.

Das Kommando aus der ersten Zeile von Listing 2 legt eine Leap-Distrobox in der gegenwärtig aktuellen Version 16.0 mit dem Namen leap an. Die Eingabe aus der zweiten Zeile, eigentlich die kanonische Schreibweise für die gerade aktuelle Version, installiert unverständlicherweise immer noch Leap 15.6. Der Befehl aus Zeile 3 öffnet die Kommandozeile, was beim ersten Mal die vorgesehenen Standardpakete installiert und daher etwas Zeit braucht. Beim nächsten Mal geht es deutlich schneller.

$ distrobox create -i registry.opensuse.org/opensuse/leap:16.0 -n leap
$ registry.opensuse.org/opensuse/leap:latest
$ distrobox enter leap
$ distrobox stop Name
$ distrobox rm Name
$ distrobox update Name
$ distrobox clone

Container verbrauchen deutlich weniger Systemressourcen als virtuelle Maschinen. Nicht genutzte Distrobox-Instanzen stoppen Sie dennoch am besten mit der Eingabe aus Zeile 4. Der Befehl aus Zeile 5 entfernt nicht aktive Boxen inklusive der von ihnen exportierten Startmenüeinträge. Zu guter Letzt gibt es noch einen Befehl, der die Software einer Distrobox aktualisiert, ohne dass Sie dazu deren Kommandozeile öffnen müssen (Zeile 6). Wünschen Sie sich eine grafische Verwaltung der Distrobox-Container, wie sie für virtuelle Maschinen gängig ist, installieren Sie via Gnome-Software das Programm BoxBuddy (Abbildung 8).

Abbildung 8: BoxBuddy, in Aeon per Flatpak nachrüstbar, verwaltet die per Distrobox eingerichteten Linux-Systeme grafisch.

Klonarmee

Mit dem Befehl aus der letzten Zeile von Listing 2 klonen Sie eine bestehende Instanz, zum Beispiel eine Distrobox, in der Sie bereits eine grafische Paketverwaltung vorinstalliert haben. Es ist auch sinnvoll, neue Instanzen anzulegen, bevor Sie Pakete aus dem Build-Service einbinden, die Systembestandteile durch experimentelle Versionen ersetzen. Nicht nur das Grundsystem bleibt dann von Risiken verschont, Sie sichern dadurch eine funktionierende Fassung des Systems in der Distrobox.

Die simpel gehaltene Distrobox-Software beherrscht lediglich das Klonen von Instanzen. Die hinter den Kulissen von Distrobox genutzte Containerverwaltung Podman [5] unterscheidet dagegen zwischen lauffähigen Instanzen, den namensgebenden Containern, und Images, die lediglich als Basis für neue Container dienen, ohne selbst ein laufendes System zu beherbergen. Das schützt Images vor unbeabsichtigter Veränderung. Der Befehl podman ps -a listet alle auf dem System vorliegenden Container. In unserem Fall zeigt die Ausgabe (Listing 3) eine Tumbleweed- und eine Leap-Distrobox sowie Details zu beiden.

CONTAINER ID  IMAGE                                             COMMAND               CREATED         STATUS                      PORTS       NAMES
4bd6d9dbc645  registry.opensuse.org/opensuse/leap:latest        --verbose --name ...  19 minutes ago  Exited (143) 9 minutes ago              leap
2bf9cce8e4fe  registry.opensuse.org/opensuse/tumbleweed:latest  --verbose --name ...  5 minutes ago   Up 5 minutes                            tumbleweed

Haben Sie also an der Distrobox leap Veränderungen vorgenommen, die Sie für einen späteren Rückgriff festhalten wollen, dann erzeugt das Kommando aus der ersten Zeile von Listing 4 dafür ein neues Image. Der Befehl podman images listet alle vorliegenden Images auf. Der Name der selbst erstellten Images beginnt in dieser Auflistung mit dem Präfix localhost.

Der Befehl aus der zweiten Zeile löscht ein Image und gibt den von podman images ebenfalls genannten Speicherplatz frei. Löschen Sie eine Distrobox mit distrobox rm Name, dann bleiben per Commit daraus erstellte Images davon unberührt. Zum Erzeugen neuer Distrobox-Instanzen auf der Basis eines lokalen Images geben Sie den Namen des Images statt des Pfads zu einem öffentlichen Server an (Zeile 3). Wegen der größeren Datenmenge dauert das Erstellen länger, doch dafür entfällt eine Installation der Grundpakete beim ersten Betreten der Box.

Mit commit erzeugte lokale Images liegen als nicht für den Zugriff von außen konzipierte Dateien im Container-Store. Sie lassen sich jedoch mit dem Kommando aus Zeile 4 leicht für Backups oder die Übertragung auf einen anderen Rechner in eine Datei sichern. Der Befehl aus Zeile 5 lädt solche Dateien in den Container-Store, wo das Image dann für die Neuerstellung von Distrobox-Instanzen bereitsteht.

# podman commit leap my_leap_01
# podman image rm Name
# distrobox create -i my_leap_01 -n leap_01
# image_name:latest | bzip2 > Datei.tar.bz
# podman load < Datei.tar.bz

Regelbruch

Die zentrale Maxime von Aeon lautet, Software nie direkt in das Grundsystem zu installieren. Was in den automatisch für jedes Paket angelegten Flatpak-Containern und in den Distrobox-Containern geschieht, tangiert die Systempartition nicht. Sie lässt sich selbst mit Root-Rechten nicht direkt beschreiben.

Doch Ausnahmen bestätigen die Regel. So erfordert beispielsweise die Installation der Nvidia-Grafiktreiber einen Eingriff in das Grundsystem. Zwar lässt sich die Software nicht direkt in das Read-only-System einspielen, doch die Installation gelingt analog zu Aktualisierungen auf Basis eines neuen Snapshots mit anschließendem Reboot. Der Befehl aus der ersten Zeile von Listing 5 richtet alle Nvidia-spezifischen Pakete ein. Danach legen Sie mit dem Kommando aus der zweiten Zeile eine Konfigurationsdatei an, in die Sie die Zeile blacklist nouveau eintragen.

$ transactional-update -i dup pkg in nvidia-drivers-G06 nvidia-driver-G06-kmp-default nvidia-video-G06 nvidia-gl-G06 nvidia-compute-G06
$ sudo vim /etc/modprobe.d/nouveau.conf
[...]
$ distrobox create -nvidia

Nach einem Reboot funktioniert die Hardwarebeschleunigung für Nvidia-GPUs. Der Befehl aus der letzten Zeile überträgt das Ganze in neu angelegte Distrobox-Instanzen. Besitzer von AMD- oder Intel-Grafikkarten brauchen nichts weiter zu unternehmen: Die entsprechende Grafikbeschleunigung funktioniert im Aeon-Grundsystem und innerhalb von Distrobox ohne weitere Schritte.

Prinzipiell lässt sich jede Software aus den Tumbleweed-Repositories wie der Nvidia-Treiber per transactional update im Aeon-Grundsystem installieren. Sehr wahrscheinlich geht dabei wie unter Tumbleweed, von dem die Pakete stammen, nichts kaputt. Es sollte sich aber nicht um experimentelle Pakete handeln, die Systembibliotheken auf instabile Versionen auffrischen. Trotzdem weicht dieses Vorgehen das Alleinstellungsmerkmal Aeons auf, die besondere Stabilität auf der Basis des minimalen Read-only-Grundsystems.

Zu beachten gilt es für die Installation auf älteren Rechnern noch, dass die bei der Installation nicht abschaltbare Vollverschlüsselung des Systems auf das Vorhandensein von TPM-2.0-Hardware im Rechner setzt, die den Schlüssel zum Entsperren beim Booten speichert. Windows-11-kompatible Computer erfüllen diese Voraussetzung.

Der Startvorgang fragt dann nicht nach einem Passwort und schützt daher nicht vor dem Starten durch Unbefugte. Das Vorgehen verhindert aber, dass sich Schadsoftware unbemerkt in den Bootvorgang einklinken kann. Auf Computern ohne TPM-2.0-Unterstützung ist die Installation von Aeon zwar prinzipiell möglich. Der dann zum Einsatz kommende Fallback-Modus verlangt allerdings die manuelle Eingabe eines Passworts in einer blanken Konsolenumgebung.

Fazit

Aeon besticht mit seinem praktisch unzerstörbarem Grundsystem, das sich selbst aktuell hält und bei Problemen automatisch zu einem funktionierenden Systemzustand zurückkehrt. Distrobox und Flatpaks erweisen sich als nützliche Beigaben, sind aber keine Alleinstellungsmerkmale von Aeon. Alle Tipps zum Umgang damit aus diesem Artikel gelten ebenso für Leap und Tumbleweed. In Aeon kommt diesen beiden Systembestandteilen jedoch ein höherer Stellenwert zu, weil sie hier sämtliche vom Anwender installierte Software bereitstellen. (uba/jlu)