Der Installer unterstützt die Systemrolle Transaktions-Server. Diese Systemrolle bietet ein Update-System, das Updates atomar (als einzelne Operation) einspielt und erleichtert diese rückgängig zu machen, sollte dies notwendig werden. Diese Features basieren auf den Paketmanagement-Tools, auf welche alle anderen SUSE und openSUSE-Distributionen bauen. Das bedeutet, dass die große Mehrheit an RPM-Paketen, die mit anderen Systemrollen von openSUSE Leap 15.4 arbeiten, auch mit der Systemrolle Transaktions-Server funktionieren.

Um diese Features anzubieten, ist dieses Update-System auf folgendes angewiesen:

Um mit Transaktionsaktualisierungen zu arbeiten, verwenden Sie immer den Befehl transactional-update anstelle von YaST und Zypper für die gesamte Softwareverwaltung:

Wenn Sie diese Systemrolle verwenden, führt das System standardmäßig eine tägliche Aktualisierung und einen Neustart zwischen 03:30 Uhr und 05:00 Uhr durch. Beide Aktionen sind systemd-basiert und können bei Bedarf mit systemctl deaktiviert werden:

systemctl disable --now transactional-update.timer rebootmgr.service

Weitere Informationen zu transaktionalen Updates finden sie unter https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ und https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

Das Installationsprogramm schlägt nur dann ein Partitionierungsschema vor, wenn die verfügbare Festplattengröße größer als 12 GB ist. Wenn Sie beispielsweise sehr kleine Images virtueller Maschinen einrichten möchten, verwenden Sie das geführte Setup, um die Partitionierungsparameter manuell einzustellen.

Bevor Sie openSUSE auf einem System installieren, welches UEFI (Unified Extensible Firmware Interface) zum Booten verwendet, sollten Sie unbedingt nach empfohlenen Firmwareaktualisierungen Ihres Hardwareherstellers suchen und diese, falls verfügbar, installieren. Eine Vorinstallation von Windows 8 oder aktueller ist ein starkes Indiz dafür, dass Ihr System UEFI nutzt.

Hintergrund: Manche UEFI-Firmware beinhaltet Fehler, die einen Abbruch verursachen, wenn zu viele Daten in den UEFI-Speicherbereich geschrieben werden. Es gibt allerdings keine klaren Daten darüber, wie viel „zu viel“ ist.

openSUSE minimiert das Risiko, indem es nicht mehr Daten schreibt, als für das Starten des Betriebssystems absolut notwendig ist. Das Minimum bedeutet, dass die UEFI-Firmware also nur den Ort gesagt bekommt, an dem es den openSUSE-Bootloader findet. Neue Linux-Kernel-Funktionen, welche den UEFI-Speicherbereich nutzen, um Boot- und Absturzinformationen (pstore) zu hinterlegen, wurden standardmäßig deaktiviert. Dennoch wird empfohlen, alle Firmwareaktualisierungen zu installieren, die vom Hardwarehersteller empfohlen werden.

Zusammen mit der EFI/UEFI-Spezifikation kam eine neue Art der Partitionierung auf: GPT (GUID Partition Table). Dieses neue Schema nutzt global eindeutige Bezeichner (128-Bit-Werte, dargestellt als eine Folge von 32 hexadezimalen Ziffern), um Geräte und Partitionstypen zu identifizieren.

Zusätzlich erlaubt die UEFI-Spezifikation auch herkömmliche MBR-Partitionen (MS-DOS). Die Linux-Bootloader (ELILO oder GRUB2) versuchen automatisch eine GUID für diese herkömmlichen Partitionen zu erzeugen, und schreiben sie in die Firmware. So eine GUID-Änderung kann häufig passieren und verursacht ein Überschreiben in der Firmware. Das Überschreiben besteht aus zwei verschiedenen Operationen: Entfernen des alten Eintrags und Erzeugen eines neuen Eintrags, der den ersten ersetzt.

Moderne Firmware hat einen Garbage Collector (Aufräum-Mechanismus), der gelöschte Einträge sammelt und den Speicherplatz freigibt, der von alten Einträgen belegt war. Es kommt zu einem Problem, wenn eine fehlerhafte Firmware die alten Einträge nicht sammelt und von diesen Einträgen befreit. Das kann dazu führen, dass das System nicht mehr startet.

Konvertieren Sie die herkömmliche MBR-Partition in eine GPT-Partition, um das Problem gänzlich zu vermeiden.

Veraltete Pakete werden weiterhin als Teil der Distribution ausgeliefert, sollen aber in der nächsten Version von openSUSE Leap entfernt werden. Diese Pakete existieren, um die Migration zu erleichtern, aber von ihrer Verwendung wird abgeraten und sie erhalten möglicherweise keine Updates.

Zur Überprüfung, ob installierte Pakete nicht länger maintained werden: stellen Sie sicher, dass das Paket lifecycle-data-openSUSE installiert ist und verwenden Sie den Befehl:

zypper lifecycle

Entfernte Pakete werden nicht mehr als Teil dieser Distribution ausgeliefert.

Starting with openSUSE Leap 15.2, kernel module signature check for third-party drivers (CONFIG_MODULE_SIG=y) is now enabled. This is an important security measure to avoid untrusted code running in the kernel.

Dies könnte Kernelmodule von Drittanbietern daran hindern, geladen zu werden, wenn UEFI Secure Boot aktiviert ist. Kernel Modul Pakete (KMPs) aus den offiziellen openSUSE Repositorys sind nicht betroffen, weil die dort verfügbaren Module mit dem openSUSE-Schlüssel signiert sind. Die Signaturüberprüfung verhält sich wie folgt:

Es besteht die Möglichkeit eigene Zertifikate zu generieren, sie in die MOK (Machine Owner Key) Datenbank des Systems zu laden und lokal kompilierte Kernel Module mit dem Schlüssel dieses Zertifikates zu signieren. Module, die auf diese Weise signiert wurden, werden weder blockiert noch lösen sie Warnungen aus. Siehe https://en.opensuse.org/openSUSE:UEFI.

Seitdem das auch NVIDIA-Grafiktreiber betrifft, adressieren wir das in unseren offiziellen Paketen für openSUSE. Allerdings muss ein neuer MOK-Schlüssel nach der Installation manuell ausgerollt werden, damit die neuen Pakete funktionieren. Für eine Anleitung, wie die Treiber installiert werden und MOK-Schlüssel ausgerollt werden, siehe https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

KDE 4 Pakete weder nicht Teil von openSUSE Leap 15.4 sein. Bitte aktualisieren Sie Ihr System auf Plasma 5 und Qt 5. Manche der Qt 4 Pakete können trotzdem aus Kompatiblitätsgründen erhalten bleiben https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.