openSUSE Leap 16.1 (release candidate) Test

21. Oktober 2026 Stefan Draxlbauer Lesezeit: 3 Minuten Auf Mastodon ansehen

Nach einem Test in einer virtuellen Maschine habe ich den Release Candidate von openSUSE Leap 16.1 auf einem Laptop installiert. Hier mein Bericht.

opensuse leap 16.1 (release candidate) test

Ich stand vor der Aufgabe, einen Laptop für die Aufbewahrung in der Schule vorzubereiten - den will ich nämlich nicht dauernd hin- und herschleppen. Bedeutet für mich: Gesicherte Updates, wenig Pflege, Vollverschlüsselung (full disk encryption, FDE). Nach meinen schlechten Erfahrungen mit Debian und debian-basierten Distributionen und da Solus ja wöchentliche Updates erhält (≠︎ wenig Pflege), fiel meine Wahl auf openSUSE Leap. Das Release von 16.1 soll am 03.11. stattfinden, also lohnt es sich jetzt nicht wirklich, 16.0 zu installieren, nur um dann in nicht mal einem Monat ein Upgrade durchzuführen. Folglich "muss" der Release Candidate herhalten. Schauen wir mal, was passiert! 😋

Plan

Folgendes ist als Ziel geplant bzw. soll geprüft werden, ob es geht:

openSUSE Leap 16.1 installieren
Vollverschlüsselung für NVMe und SSD (/home auf SSD)
Entschlüsselung per TPM
LXQt mit Wayfire (Wayland) als Oberfläche
Apps vornehmlich als Flatpaks, um diese aktuell zu halten. Vor allem für LibreOffice ist das in Hinblick auf Kompatibilität mit OOXML besser.
Funktionsfähigkeit des Grafiktablets und Zuordnung zum korrekten Bildschirm
Ton muss per HDMI auf einfache Weise ausgegeben werden können

Manches davon scheint trivial, aber der Teufel steckt im Detail.

Ich wähle die Variante ohne immutable Ansatz. Erstens kenne ich mich damit nicht gut aus, zweitens gibt es LXQt nicht als Auswahl als Desktop bei der Installation. D.h. ich müsste dann nach der Installation mit transactional-updates arbeiten usw. und dann kann ich mir auch das immutable sparen - soweit meine aktuelle Einstellung. Dazu brauche ich flatpak-builder, den Flatpak empfiehlt von den Repositories der Distribution zu installieren.

Installation der Distribution

Ich bitte um Entschuldigung für die teilweise schlechten Bilder. Ein paar Optionen gibt es in der VM nicht (bzw. ich weiß nicht, wie man diese provoziert), sodass hier Fotos vom realen Installer auf realer Hardware herhalten müssen.

Die Installation ist soweit recht unspektakulär. Man lädt zuerst die ISO von der Webseite herunter; bei mir das Offline-Image. Das Online-Image hat keine anderen Optionen, soweit ich sehen konnte.

Wir wählen Leap 16.1 und "Standard" aus, akzeptieren die Lizenzbestimmungen.

Dann können wir die einzelnen Aspekte der Installation bearbeiten. Hierbei müssen wir in jedem Schritt wieder auf "Installation" oben klicken, um auf den Überblick zu gelangen. 😑

Tipp: Wählt oben rechts die Sprache und Eingabe-Einstellungen auf Deutsch (bzw. eure Sprache). Leider wird für den Installer Agama nicht das ausgewählt, was man für die Installation selbst bei Sprache einstellt. Andersrum aber schon!... vorausgesetzt man wählt es an... Kurios: Ein mal heißt die Sprache "German", einmal "Deutsch":

Wichtig: Beim Speichermedium auf jeden Fall drauf achten, dass "/" genügend Platz bekommt! Ich musste openSUSE 2x installieren, weil er beim ersten mal <40GB für "/" reserviert hat. 😤 Das ist natürlich viel zu wenig, vor allem da openSUSE Btrfs benutzt, das Snapshots generiert. Für /home auf meiner zweiten Festplatte hat openSUSE Xfs eingerichtet. Da ich mich nicht wirklich mit Dateisystemen auskenne, habe ich das mal so gelassen.

Ich wähle KDE als Desktop-Oberfläche, werde diese aber nachher mit LXQt ersetzen/ergänzen. Da LXQt auch auf Qt aufbaut und ein paar der KDE Frameworks nutzt, ist das für mich eine passende Kombination.

Spannend für mich: Ich kann zwar die TPM-Verschlüsselung anwählen, aber der Warnhinweis sagt mir, dass die fde-tools nicht verfügbar sind. Bedeutet, ich muss mich darum später kümmern, und das trotz Internetverbindung per WLAN! Sehr ärgerlich! Die TPM-Entschlüsselung musste ich folglich abwählen.

Wir haben bei der Authentifizierung die Wahl:

Administratorbenutzer (mit und ohne SSH-Schlüssel) erstellen
Öffentlichen SSH-Schlüssel (für Root-Benutzer) hinzufügen
Root-Benutzer mit Passwort erstellen

Ich wähle einen Administratorbenutzer mit Passwort und deaktiviere die Anmeldung per Root (Standard). Theoretisch kann man sich damit aussperren, wenn die Platte voll läuft, aber mir ist das noch nie passiert.

Hinweis: Verfügbare WLANs kann man über Netzwerk oder "2 more" bei der Angabe der IP-Adresse(n) hinzufügen:

Post-Install

Der erste Schritt nach der Installation sind natürlich die Updates. Da es ein RC ist, gibt es davon doch einige. Wir machen also:

sudo zypper ref
sudo zypper up

zypper ist die Paketverwaltung von openSUSE, die in meinen Augen auch sehr gut ist; "ref" bedeutet "refresh [der Paketlisten]"; "up" bedeutet "upgrade". Wobei ich mir nicht sicher bin, ob "up" nicht auch ein "ref" mit macht... 🤔 Anschließend starte ich das System neu. Das muss man nicht nach jedem Update machen, aber am Anfang halte ich es für sinnvoll. Speziell wenn der Kernel aktualisiert wird, lohnt es sich.

Anschließend benutze ich den grafischen Paketmanager Myrlyn. Dieser löst seit openSUSE 16 den Paket-Manager-Teil von YaST ab und ist mit Qt6 geschrieben - also mit einem aktuellen Software-Stack. Myrlyn wie YaST vorher auch hat einen Reiter "Patterns" bzw. "Schemata". In diesen werden Pakete sortiert aufgelistet bspw. passend für KDE, XFCE aber auch LXQt. Die für LXQt notwendigen bzw. passenden Pakete habe ich mir dort bezogen. Man klickt auf das Kästchen es jeweiligen Pakets, dieses wird zu einem "+" und per Klick auf "Accept" bzw. "Annehmen" werden die Pakete heruntergeladen und installiert. Als Wayland-Compositor habe ich Wayfire gewählt. Es ist recht leichtgewichtig, bietet aber bspw. IPC-Anbindung, sodass Tastaturkürzel und weiteres funktionieren.

Schön finde ich die grafische Darstellung des Prozesses.

Zusätzlich habe ich mir Flatpak mit dem Flathub-Repository eingerichtet. Darüber beziehe ich (aktuellere oder "fehlende") Pakete, aber auch meine Notenverwaltung installiere ich über flatpak-builder, das ich ebenfalls installiert habe. Zu den "Pflicht-Programmen" für mich zählen unter anderem:

PDF Arranger (solange Imprint noch nicht verfügbar ist)
LibreWolf
Chromium (für Schulwebseiten, kein Kommentar...)
Xournal++
KeePassXC (+ Flatpak-Browser-Fix)
(GNOME) Vaults
Kile + Texlive

TPM-Entschlüsselung

openSUSE hat die fde-tools in den Repositories. Dieses Werkzeug kommt von ALP und kümmert sich eine vereinfachte Ent-/Versiegelung von TPM. Wenn ich das richtig vestehe: Damit soll man also bspw. die Passwörter zur Verschlüsselung im TPM versiegeln können. Dadurch muss man diese nicht mehr eintragen. Die Sicherheit ist insofern weiter gewährleistet, dass nur die Kombination aus Platte + TPM die Passwörter hergibt. Sie liegen also nicht "frei rum".

Die Seite auf Github beschreibt das Vorgehen zum Glück gut, wenn auch auf Englisch.

Hinweis: Alle Befehle müssen als root oder über sudo ausgeführt werden. Ich spare mir das in den Listings.

Zunächst prüfen wir, ob ein TPM vorhanden und erreichbar ist.

fdectl tpm-present

Über

fdectl tpm-disable
fdectl tpm-enable

können wir das TPM (de-)aktivieren. Und über

fdectl tpm-wipe

können wir eingetragene Schlüssel löschen.

Anmerkungen:

Jetzt wird es etwas "experimentell", weil ich mir nicht sicher bin, ob ich alles richtig verstanden habe. Wichtig ist: Die folgenden Maßnahmen haben nichts "kaputt" gemacht, aber die Entschlüsselung per TPM hat bei mir nicht vollständig funktioniert.

Da die Entschlüsselung der Swap-Partition über TPM nicht funktionieren wollte, habe ich versucht, die Swap-Partition zu deaktivieren und durch ein Swapfile zu ersetzen. Und das obwohl beim Einfügen der Schlüssel (siehe unten) die entsprechende Partition immer mit gelistet wurde. Leider hat auch das nicht funktioniert.

Zunächst tragen wir alle Geräte ein, für die ein Schlüssel im TPM hinterlegt werden soll. Das geschieht in der Datei /etc/sysconfig/fde-tools . Dort gibt es einen Eintrag namens

# Specify the devices to be managed by fdectl
# NOTE: Those devices must use the same recovery password.
FDE_DEVS=""

Welche Devices tragen wir da ein? Quasi alle, die ein cr_... unter sich haben. Per lsblk kann man sich alle Blockdevices aka Platten, Partitionen,... anzeigen lassen. Bei mir sieht das so aus:

$ lsblk
sda           8:0    0 465,8G  0 disk  
└─sda1        8:1    0 465,8G  0 part  
  └─cr_home 254:2    0 465,7G  0 crypt /home
nvme0n1     259:0    0 238,5G  0 disk  
├─nvme0n1p1 259:1    0   512M  0 part  /boot/efi
├─nvme0n1p2 259:2    0   236G  0 part  
│ └─cr_root 254:0    0   236G  0 crypt /var
│                                      (...)
└─nvme0n1p3 259:3    0     2G  0 part  
  └─cr_swap 254:1    0     2G  0 crypt

Ich brauche also nvme0n1p2 und sda1, jeweils mit einem /dev/ vornedran. nvme0n1p3 ist die Swap-Partition, mit der es nicht geklappt hat, egal, ob sie da gelistet war oder nicht.

# Specify the devices to be managed by fdectl
# NOTE: Those devices must use the same recovery password.
FDE_DEVS="/dev/nvme0n1p2 /dev/sda1"

Anschließend reicht ein

$ fdectl regenerate-key

Das läuft dann durch, wobei der Output mir zu lang war, um ihn hier abzulichten. Schließlich werden Grub, / und /home per TPM ohne Eingabe des Passworts entschlüsselt.

Anmerkung: openSUSE ist die einzige mir bisher begegnete Distribution, die standardmäßig bei FDE auch den Grub mit verschlüsselt.

Grafiktablet-Test

Zusammenfassung: Anschließen. Geht.

... Leider nicht die Zuordnung des Stifts zum entsprechenden Display. Das lässt sich über Wayfire aber zum Glück beheben! Und zwar garnicht so kompliziert, wie ich mir das vorgestellt habe. Die Schritte:

Schritt 1: Identifizieren des korrekten Bildschirms

via:

wlr-randr

oder alternativ das grafische Programm WDisplays. Bei mir ist das HDMI-A-1.

Schritt 2: Herausfinden des Namens des Stifts

Dies schauen wir mittels libinput nach, für das ich zuerst das Paket "libinput-tools" installieren musste.

sudo libinput list-devices | grep "Device"

An der Stelle heißt es suchen... Wir brauchen wirklich nur diesen "Namen" inklusive Leerzeichen etc.. Bei mir: "Wacom One Pen Display 13 Pen".

Schritt 3: Eintragen in Wayfire

Leider gibt es keine (mir bekannte) GUI dafür. Das heißt wir müssen die wayfire.ini bearbeiten, die für LXQt hier liegt: ~/.config/lxqt/wayland/lxqt-wayfire.ini . Immerhin brauchen wir dafür keine Root-Rechte, sodass das hier reicht:

nano ~/.config/lxqt/wayland/lxqt-wayfire.ini

Dort tragen wir folgenden Code ein:

[input-device:DEVICE NAME]
output = OUTPUT

Für mich also:

[input-device:Wacom One Pen Display 13 Pen]
output = HDMI-A-1

Anschließend musste ich den Wacom-Bildschirm ein mal aus- und einschalten und dann ging es - schwierig, hier ein Beweisbild dafür zu zeigen. Glaubt es mir einfach. 😅

Hinweis: Das geht nur so lange gut, wie derselbe HDMI-Anschluss genutzt wird. Zumindest war das bei mir so. Denn ein anderer HDMI-Anschluss bekommt einen anderen Namen.

HDMI- + Ton-Test

Zu meiner Überraschung: Anschließen -> geht. 👍️

Fazit

Ein Check der Liste zeigt:

openSUSE Leap 16.1 installieren ✅
Vollverschlüsselung für NVMe und SSD (/home auf SSD) ✅
Entschlüsselung per TPM ❌
LXQt mit Wayfire (Wayland) als Oberfläche ✅
Apps vornehmlich als Flatpaks, um diese aktuell zu halten. Vor allem für LibreOffice ist das in Hinblick auf Kompatibilität mit OOXML besser. ✅
Funktionsfähigkeit des Grafiktablets und Zuordnung zum korrekten Bildschirm ✅
Ton muss per HDMI auf einfache Weise ausgegeben werden können ✅

Probleme, die ich noch bemerkt habe:

nm-tray existiert nach Start zwei mal - beide reagieren aber nicht auf Linksklick, sodass ich keine WLANs oder VPNs auswählen kann. Hier musste ich mit "env QT_QPA_PLATFORM=xcb nm-tray" einen Umweg gehen.
Qt-Flatpaks übernehmen nicht das global gesetzte Theme.

openSUSE Leap 16.1 bleibt bei mir auf jeden Fall auf der Platte. Es läuft stabil und macht das, was ich von ihm will. Die Vollverschlüsselung und gute Performanz erfreuen mich. LXQt in Version 2.4 ist gut gereift, ist und bleibt aber ein System, das man anpassen wollen muss. Aber soweit ich das Projekt verstehe, ist das auch so gewollt. 👍️