Versionshinweise #

Die openSUSE Leap 15.3 Wartungseinrichtung besteht aus drei haupt Aktualisierungsquellen. Diese sind: repo-update, repo-backports-update, and repo-sle-update. Die letzten beiden sind neu und ein Ergebnis von der Nutzung der Binaries von SUSE Linux Enterprise. Diese Repositorys sind verfügbar und werden während der Online-Installation von openSUSE Leap überprüft. Wir empfehlen Ihnen, diese zu nutzen. Neue Update Repository Definitionen für openSUSE Leap 15.3 werden ebenfalls über ein 0Tag Wartungsupdate des openSUSE-release Pakets angeboten. Die Aktualisierung wird über den traditionellen repo-update Wartungskanal geliefert. Dieser wird eine spezielle Update-Markierung erhalten, welche bedeutet dass der Bereich der Software-Verwaltung berührt wird welcher dann besonders von zypper bearbeitet wird. Sie sollten eine zusätzliche Kontrolle mit dem Befehl zypper up durchführen dass alle Aktualisierungen verarbeitet worden sind. Weitere Informationen finden Sie unter https://bugzilla.opensuse.org/show_bug.cgi?id=1186593.

Das repo-update Repository ist für openSUSE Leap (OSS) Aktualisierungen. Es ist das kleinste und enthält Systemkonfigurationspakete, inklusive Veröffentlichungspaket, Branding und mögliche Abspaltungen von SUSE Linux Enterprise Paketen. Dieses Repository hat ebenfalls eine debug-info Variante.

Das repo-backports-update Repository ist ein Aktualisierungsrepository für openSUSE Backports welches den Hauptteil von Aktualisierungen von openSUSE Leap Paketen enthält. Dieses Repository hat ebenfalls eine debug-info Variante.

Das dritte Repository namens repo-sle-update ist ein Aktualisierungsrepository welches kombinierte Aktualisierungen von allen aktiven SUSE Linux Enterprise Update-Quellen enthält. Dieses Repository hat keine debug-info Variante.

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.2 arbeiten, auch mit der Systemrolle Transaktions-Server funktionieren.

Anmerkung: Inkompatible Pakete

Manche Pakete modifizieren die Inhalte von /var oder /srv in ihren RPM-%post-Skripten. Diese Pakete sind inkompatibel. Wenn Sie so ein Paket finden, erstellen Sie einen Bug-Report.

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

Wichtig: Transaktionaler Server benötigt mindestens 12 GB Festplattenplatz

Die Systemrolle Transaktionaler Server benötigt eine Mindest-Festplattengröße von 12 GB um Btrfs-Snapshots unterzubringen.

Wichtig: YaST funktioniert nicht Transaktionsmodus

Zur Zeit funktioniert YaST nicht mit Transaktionalen Updates. Dies liegt daran, dass YaST Dinge sofort ausführt und da es kein Nur-Lese Dateisystem bearbeiten.

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 hat Fehler, die das Starten verhindern, 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.

During installation on a laptop, the tlp package is installed (together with its sub-package tlp-rdw, if the installation of recommended packages is enabled). This package provides additional tools to save battery power on laptops, especially Lenovo laptops.

The service is not enabled by default because it might interfere with other specialized laptop tools, for example, laptop-mode-tools, rfkill, gnome-power-manager, or kde-power-manager. To enable and start the service explicitly, use YaST Services Manager or use the command systemctl enable --now tlp.service . If you encounter any unexpected behavior afterward, for example, WiFi problems or non-functional USB ports, disable the service again.

openSUSE Leap 15.3 wurde neu auf Basis von Binär-RPMs aus SUSE Linux Enterprise Server gebaut. Diese Änderung wurde im Rahmen des Closing The Leap Gap (CtLG) eingeführt um openSUSE Leap und SUSE Linux Enterprise Server näher aneinander zu rücken.

Im Gegensatz zu 15.2 enthält die Standardinstallation von openSUSE Leap 15.3 den Hauptteil von rpms aus SUSE Linux Enterprise Server. Diese rpms sind von SUSE LLC signiert anstelle des openSUSE Keys. Das libzypp Paket Version 12.25.8 führte eine Whitelist für den SUSE LLC und openSUSE Anbieteraustausch damit eine saubere Migration möglich ist. Diese Whitelist benötigt daher nicht, --allow-vendor-change anzugeben wobei sich dies auf den openSUSE und SUSE LLC Anbieteraustausch bezieht. Sie müssen gegebenenfalls trotzdem --allow-vendor-change während der Migration angeben sofern Sie OBS Repositorys nutzen, die mit anderen Schlüsseln signiert sind.

openSUSE Leap releases older than 15.2 do not contain this feature because they are not supported anymore. All users are advised to upgrade to openSUSE Leap 15.2 with the latest updates before upgrading to 15.3. The following parameters can be used as a workaround for libzypp versions older than 12.25.8 (replace 15.0 below with your current openSUSE version):

zypper addrepo --check --refresh --name 'openSUSE-Leap-15.0-Update' http://download.opensuse.org/update/leap/15.0/oss/ repo-update
zypper dup --allow-vendor-change --force-resolution

openSUSE Leap 15.3 bietet alle benötigten RPM Überprüfungsschlüssel an, inklusive die von SUSE Linux Enterprise Server, als Teil des openSUSE-build-key Pakets. Alle Schlüssel sind ebenfalls neu innerhalb des OSS Repositorys enthalten.

Das Paket libzypp Version 17.25.11 sollte automatisch die benötigten Schlüssel importieren, die als vertrauenswürdig identifiziert sind. Sofern dieses erfolgt ist, wirst man benachrichtigt und keine weitere Aktion ist erforderlich.

Wenn das System den Schlüssel zur Signierung von repodata nicht importiert hat müssen Sie diesen manuell importieren. Sie können dies mit dem folgenden Befehl überprüfen:

rpm -qa gpg-pubkey

Die Ausgabe sollte eine Zeile beinhalten die mit dem folgenden Text beginnt: gpg-pubkey-39db7c82-* Falls nicht dann sollten Sie folgendes tun um den Schlüssel manuell zu importieren:

Für weitere Informationen, siehe https://bugzilla.opensuse.org/show_bug.cgi?id=1184326.

Auf openSUSE Leap wurde der Standardkernel in drei Unterpakete aufgeteilt: kernel-default, kernel-default-extra und kernel-default-optional. Ebenso wurde kernel-preempt in kernel-preempt, kernel-preempt-extra, and kernel-preempt-optional aufgeteilt. Das -optional Paket enthält optionale Module rein für openSUSE Leap. Das -extra beinhaltet nicht unterstützt Module. Der Kernel-Preemption Modus kann durch die Eingabe des Kernel Parameters preempt=voluntary auf der Kommandozeile gesteuert werden. Dieser Parameter funktioniert mit kernel-default.

Wenn Sie diese Kernelvariante verwenden, vergewissern Sie sich dass alle RMPs für ihren Nutzungszweck installiert sind.

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 unterstützt werden: Stellen Sie sicher, dass lifecycle-data-openSUSE installiert ist. Dann verwenden Sie den Befehl:

zypper lifecycle

Entfernte Pakete werden nicht mehr als Teil dieser Distribution ausgeliefert.

Das neu eingeführte Paket openSUSE-signkey-cert wird für openSUSE KMPs wie virtualbox benötigt aber dies nur im Secure Boot Modus. Das Paket beinhaltet das Zertifikat des openSUSE Signingschlüssel zur Zeichnung der Kernelmoduldatei (.ko) in openSUSE KMP und ruft mokutil auf damit dem Benutzer geholfen wird, das Zertifikat in MOK einzubinden. Auf diese Weise kann openSUSE KMP durch den Kernel überprüft werden.

If you do not have the base pattern installed and are using any of these KMPs, we recommend installing the openSUSE-signkey-cert package manually. A system reboot is required. More information about this process and manual enrollment can be found at https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

openSUSE Leap 15.2 und neuer aktivieren jetzt einen Kernelmodul-Signatur-Check für Third-Party-Treiber (CONFIG_MODULE_SIG=y). Es ist eine wichtige Sicherheits-Maßnahme um das Laufen von vertrauensunwürdigen Code im Kernel zu verhindern.

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 packages are no longer part of openSUSE Leap 15.3. Update your system to Plasma 5 and Qt 5. Some Qt 4 packages may still remain for compatibility reasons. For more information, see https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.

Since IBus version 1.5.23 renamed some keyboard layouts, it cannot load configuration containing these renamed layouts after upgrading. Thereby, it might reset the layout to US. Layouts of the following languages are affected: Belgian, German, Greek, Romanian, and Slovak. See https://bugzilla.opensuse.org/show_bug.cgi?id=1177545 for more information.

Users need to migrate configuration manually. Open GNOME Settings and choose an appropriate layout. For desktop environments other than GNOME, run ibus-setup instead.