Kinoite ist die neueste offizielle Fedora-Variante und vereint KDE Plasma mit einem sehr robusten Grundsystem.

Mit der für den 19. Oktober geplanten Veröffentlichung von Fedora 35 [1] hat das Red-Hat-Projekt eine neue Variante namens Kinoite angekündigt. Dabei handelt es sich um das KDE-Pendant zu dem bereits seit Fedora 29 ausgelieferten Silverblue, das auf den Gnome-Desktop setzt und seinerseits aus der Fedora Atomic Workstation hervorging.

Sowohl Silverblue als auch Kinoite (und einige andere Distributionen wie Endless OS) sind ein Indiz für einen möglichen langsamen Wandel der Distributionsszene. Während die Mehrzahl der großen Distributionen an den erprobten Konzepten festhält, verfolgen einige Entwickler neue Ansätze.

Dazu gehören sogenannte Immutable-Distributionen, wobei der englische Begriff für “unveränderlich” steht. Das bedeutet, dass diese Systeme auf unterschiedlichen Wegen dafür sorgen, dass das Root-Dateisystem nur im Lese-Modus eingehängt ist, das System Änderungen aber trotzdem speichert. Diese landen auf einer eigenen Ebene (siehe auch Kasten “Systemd-Support”). Systeme wie Android oder Chrome OS bedienen sich ähnlicher Sicherheitsmerkmale.

Kinoite ist blau

In Ausgabe 10/2021 [2] haben wir die Distribution rlxOS vorgestellt, die diese Aufgabe per OverlayFS erledigt [3]. Bei dieser Art von System bedeutet ein Update, dass Sie jeweils ein komplettes Image einspielen und – falls etwas schiefgeht – auf den vorherigen Stand zurückrollen, indem Sie im Bootmanager ein älteres, intaktes Image auswählen.

Jetzt gesellt sich Fedora Kinoite als offizielle Fedora-Variante diesen Nischen-Betriebssystemen hinzu. Der Name stammt von einem Silikat-Mineral, dessen blaue Farbe in diesem Fall auf das Blau von KDE verweist. Damit ist Kinoite für den Fedora KDE Spin das, was Silverblue für die Fedora Workstation ist. Beide unterscheiden sich lediglich im verwendeten Desktop; ansonsten bedienen sie sich beim hybriden Paketmanager RPM/OSTree [4], der auf das Image-Format Libostree setzt. Weitere Distributionen, die RPM/OSTree verwenden sind Endless OS und Fedora CoreOS.

Mehrere Paketebenen

Damit eignen sich solche Distributionen unter anderem für Entwickler und für Anwender mit Container-basierten Arbeitsabläufen. Als bevorzugtes Paketformat dient Flatpak, alternativ lassen sich normale RPM-Archive einspielen. Das gelingt sowohl im Terminal via Rpm als auch in der grafischen Oberfläche über die KDE-App Discover.

Auf diese Weise stehen die meisten Pakete aus den Fedora-Repositories bereit. Die Anwendungen landen dabei in einer separaten Schicht außerhalb des Root-Dateisystems. Um die für die anvisierte Zielgruppe unabdingbaren Entwicklerwerkzeuge bereitzustellen, gibt es außerdem das Programm Toolbox [5], über das Sie mittels Podman [6] entsprechende Container erzeugen.

Kinoite befindet sich noch in einem frühen Stadium und basiert derzeit auf “Rawhide”, der jeweiligen Entwicklerversion von Fedora, von der die Entwickler vor jedem Release die Veröffentlichung abspalten. Zum Download stehen derzeit Daily Builds bereit, das von im Test verwendete Abbild stammt vom 21. August [7]. Wenn Sie diesen Beitrag lesen, gibt es vermutlich zumindest eine Beta-Version.

Für Kinoite wie für Silverblue bietet das Projekt keine Live-Version an. Um es zu testen, installieren Sie es am einfachsten in einer virtuellen Maschine. Wir haben Virtualbox und Gnome Boxen [8] als Grundlage ausprobiert, wobei Letzteres in diesem Fall besser abschnitt, da Virtualbox keinen Fullscreen-Modus erlaubte. Start und Installation von Kinoite unterscheiden sich nicht von dem der Fedora Workstation: Bei beiden kommt der Fedora-Installer Anaconda zum Zug.

Unscheinbar

Nach dem ersten Start ins installierte System könnten Sie zu der Annahme gelangen, Sie seien im normalen KDE-Spin von Fedora gelandet. Lediglich das begrenzte Angebot vorinstallierter Anwendungen weckt diesbezüglich Zweifel. Die spärliche Ausstattung besteht neben den grundlegenden KDE-Apps lediglich aus dem Browser Firefox. Musik hören, Videos schauen oder andere übliche Arbeiten am Computer fallen zunächst flach.

Flatpak ist als bevorzugte Installationsquelle vorkonfiguriert und das Fedora-Repository für Flatpaks eingebunden. Es fehlt eine Einbindung des besser ausgestatteten Flatpak-App-Stores Flathub. Fedora bindet ihn deswegen nicht standardmäßig ein, weil er proprietäre Apps wie Spotify, Dropbox und andere enthält. Bei Bedarf integrieren Sie Flathub über den Befehl aus Listing 1.

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Flatpak erwünscht

Alternativ klicken Sie auf den blau hinterlegten Schalter auf der Webseite [9] und wählen als Option das Öffnen des Links in Discover (Abbildung 1). In der sich öffnenden App klicken Sie oben rechts auf Installieren. Wechseln Sie nun links unten auf Einstellungen, dann können Sie durch einen Klick auf den nach rechts gerichteten Pfeil hinter Flathub oder der Fedora-Flatpak-Registry jeweils die Pakete durchstöbern und installieren. Dort finden Sie alles, was sonst zu einer Distribution gehört (Abbildung 2).

Abbildung 1: Im Software-Shop Discover von KDE sehen Sie für jedes Paket neben Informationen über Entwickler, Version und Lizenz, ob es als RPM oder als Flatpak vorliegt. Bei Flatpaks zeigt das Programm das jeweils ursprüngliche Repository an.

Abbildung 2: Über den Menüpunkt Einstellungen binden Sie in Discover bei Bedarf weitere Flatpak-Repositories ein. Dabei darf es sich um ein eigenes Archiv oder eines von einem anderen Anbieter handeln.

RPM erlaubt

Was Sie in Discover nicht finden, installieren Sie im Terminal über den Paketmanager Rpm. Solche Pakete verwaltet das System dabei isoliert in einer separaten Schicht außerhalb des Root-Dateisystems als sogenannte Layered Packages. Der Grundbefehl für das Paketmanagement in der Konsole lautet rpm-ostree. Per rpm-ostree install Paket installieren Sie Software aus den normalen Fedora-Archiven nach.

Beim ersten Einsatz bindet das Tool zunächst das Repository ein und legt die RPM-Datenbank an, bevor es das gewünschte Paket installiert. Generell dauert die Installation von Anwendungen etwas länger als beim herkömmlichen Paketmanagement (Abbildung 3). Das Aktualisieren der Installation verläuft ähnlich: Über rpm-ostree upgrade stoßen Sie den Vorgang an (Abbildung 4). Nach dessen Abschluss fragen Sie per rpm-ostree status ab, welche Abbilder beim Neustart bereitstehen (Abbildung 5).

Abbildung 3: Anwendungen, die Sie als RPM per rpm-ostree installieren, landen in einer separaten Ebene außerhalb des Root-Dateisystems, von der nur ein Lesen möglich ist.

Abbildung 4: Das Upgrade einer Installation läuft ähnlich wie bei anderen Distributionen. Die Wirksamkeit der Änderungen ist aber erst nach einem Neustart gegeben.

Abbildung 5: Über eine Statusabfrage sehen Sie vor einem Neustart, welche Abbilder der Bootmanager Grub Ihnen anbietet.

Ein Nachteil bei Silverblue und Kinoite sowie ähnlich aufgebauten Systemen: Damit die Änderungen greifen, steht nicht nur nach einem Upgrade ein Neustart des Systems an, sondern zusätzlich nach jeder Installation eines Pakets via Rpm. Dabei startet das System jeweils ein frisches Abbild der gesamten Installation, wobei Grub automatisch das zuoberst stehende aktuelle Abbild auswählt. Als Flatpak installierte Anwendungen stehen dagegen sofort ohne Neustart bereit.

Updates als Image

Stellen Sie nach einem Neustart fest, dass etwa ein installiertes Paket nicht funktioniert, so haben Sie zwei Möglichkeiten: Per rpm-ostree rollback versetzen Sie das System nach einem darauf folgenden Neustart wieder in den vorherigen Zustand (Abbildung 6). Das entfernt allerdings alle für dieses Abbild installierten Pakete.

Abbildung 6: Geht bei einem Upgrade oder der Installation eines Pakets etwas schief, rollen Sie aus der Konsole zurück und versetzen das System nach einem Neustart wieder in den vorherigen Zustand.

Alternativ leiten Sie per systemctl reboot einen Neustart ein, bei dem Sie dann in Grub die Auswahl mit den vorhandenen Abbildern erhalten. Hier wählen Sie einfach ein älteres Image aus. Das Abbild, das den Fehler enthält, bleibt so für eine eventuelle Fehlersuche erhalten.

Rebase

Neben dem Upgrade besteht die Möglichkeit, auf ein neues Release von Fedora umzusteigen. Dazu dient der Befehl rpm-ostree rebase. Damit wechseln Sie nicht nur nach der Veröffentlichung von Fedora 35 auf die neue Version von Kinoite, sondern bei Bedarf auf jede andere Variante oder sogar auf die normale Fedora Workstation.

Dazu sehen Sie zunächst in der Liste nach, welche Versionen für welche Architekturen bereitstehen (Listing 2, Zeile 1). Das Angebot reichte im Test bis Fedora 27 zurück. Probehalber stellten wir das System auf diese Workstation-Variante um (Zeile 7). Den letzten Teil hinter -b kopieren Sie dabei aus der Liste der Varianten. Wieder schließt ein Reboot die Aktion ab (Zeile 9).

$ ostree remote refs fedora
fedora:fedora/27/aarch64/atomic-host
fedora:fedora/27/ppc64le/atomic-host
fedora:fedora/27/x86_64/atomic-host
fedora:fedora/27/x86_64/testing/workstation
[...]
$ sudo rpm-ostree rebase -b fedora:fedora/27/x86_64/testing/workstation
[...]
$ systemctl reboot

Dritte Ebene

Eine weitere Möglichkeit, um Anwendungen zu installieren, führt über die bereits erwähnte vorinstallierte Applikation Toolbox [11]. Dabei kommen mit Podman erstellte Container zum Einsatz, um eine Umgebung bereitzustellen, in die Sie etwa Entwicklungswerkzeuge, Bibliotheken oder Treiber installieren und dann verwenden (Abbildung 7).

Abbildung 7: Installieren Sie Software innerhalb der Toolbox, landen die Pakete in einem Container, den die Software dabei völlig transparent ins System integriert.

Toolbox bringt dazu eine Anzahl von Befehlen zum Erstellen, Auflisten, Nutzen und Entfernen von Containern mit. Diese Container integriert das System dann in die normale Arbeitsumgebung, ohne dass Sie sich darum zu kümmern brauchen.

Mit dem Befehl toolbox create erstellen Sie einen solchen Container. Wollen Sie mehr als einen Container einsetzen, ist es sinnvoll, sie mit toolbox create --container Name --release f35 zu benennen sowie festzulegen, welche Fedora-Version Sie einsetzen möchten.

Mit toolbox list verschaffen Sie sich einen Überblick über die erstellten Container. Nachdem Sie mit toolbox enter -c Name den Container betreten haben, installieren Sie mit einem Kommando wie sudo dnf -y install gdb git die benötigten Werkzeuge. Alle Container räumen Sie mit toolbox rm -a ab, mit toolbox rm Name entfernen Sie einen bestimmten.

Fazit

Mit Silverblue und Kinoite setzt Fedora das Konzept eines unzerstörbaren Root-Dateisystems um. Bevorzugen Sie KDE Plasma, finden Sie in Kinoite eine gelungene Umsetzung des Immutable-Konzepts. In unserem Test war sie bereits zwei Monate vor der ersten stabilen Veröffentlichung in einem guten Zustand.

Probleme traten lediglich beim Installieren von Anwendungen aus dritter Hand auf. Das sollte in der Theorie eigentlich mit rpm-ostree install funktionieren, sofern ein RPM-Paket zum Download bereitsteht. Bei Google Chrome ließ sich jedoch ein Font als Abhängigkeit nicht installieren, bei Mullvad VPN fehlte ebenfalls eine Abhängigkeit. Der Passwortmanager Enpass stand als AppImage bereit und funktionierte einwandfrei. Darüber hinaus gab es aber beim Test keine Probleme mit Kinoite.

Flatpaks stammen ebenso wie Snaps und AppImages in der Regel direkt vom jeweiligen Entwickler. Setzen Distributionen nur noch auf solche Formate, macht das die Maintainer in den Distributionen überflüssig, deren Aufgabe darin lag, Pakete konform zur Distribution zu schnüren und auszuliefern.

Bei Debian etwa erfüllen die Maintainer aber die wichtige Aufgabe, die Anwendungen, die von Upstream kommen, gemäß der DFSG auszuliefern. Erhalten Sie Pakete über den Umweg Flathub direkt vom Entwickler, fällt das weg, mit allen Vor- und Nachteilen. Nicht zuletzt deswegen steht die Frage noch offen, ob sich diese Form der Distributionen letztlich durchsetzt. (agr)