Upgradehandbuch
SUSE Linux Enterprise Desktop 15 SP7

# Upgradehandbuch

Dieses Handbuch führt Sie durch das Upgrade von SUSE Linux Enterprise Desktop.

Versionsgeschichte: Upgradehandbuch
Veröffentlicht: 11. Dezember 2025

- 1.1 Hauptversionen und Service Packs
- 1.2 Langfristiger Service Pack-Support
- 2.1 Überblick über die unterstützten Upgrade-Pfade

- 1.1 Sicherheitsaktualisierungen und Fehlerbehebungen

- 3.1 Über `df ‑h` angezeigte Liste

Copyright © 2006–2025 , SUSE LLC und Mitwirkende. Alle Rechte vorbehalten.

Es wird die Genehmigung erteilt, dieses Dokument unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder (optional) Version 1.3 zu vervielfältigen, zu verbreiten und/oder zu verändern; die unveränderlichen Abschnitte hierbei sind der Urheberrechtshinweis und die Lizenzbedingungen. Eine Kopie dieser Lizenz (Version 1.2) finden Sie in Abschnitt „GNU Free Documentation License“.

Die SUSE Marken finden Sie in https://www.suse.com/company/legal/. Die Rechte für alle Marken von Drittanbietern liegen bei den jeweiligen Eigentümern. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und ihren Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.

Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Auch hierdurch kann jedoch keine hundertprozentige Richtigkeit gewährleistet werden. Weder SUSE LLC, ihre Tochtergesellschaften, die Autoren noch die Übersetzer können für mögliche Fehler und deren Folgen haftbar gemacht werden.

# Vorwort #

## 1 Verfügbare Dokumentation #

Online-Dokumentation

  Unsere Dokumentation ist online verfügbar unter https://documentation.suse.com. Durchsuchen Sie die Dokumentation oder laden Sie sie in verschiedenen Formaten herunter.

  Anmerkung: Neueste Aktualisierungen

  Die neuesten Aktualisierungen sind normalerweise in der englischen Version dieser Dokumentation verfügbar.

SUSE Knowledgebase

  Wenn Sie auf ein Problem stoßen, lesen Sie die technischen Informationsdokumente (TIDs), online verfügbar unter https://www.suse.com/support/kb/. Durchsuchen Sie die SUSE Knowledgebase nach bekannten Lösungen, die sich an den Bedürfnissen der Kunden orientieren.

Versionshinweise

  Die Versionshinweise finden Sie unter https://www.suse.com/releasenotes/.

In Ihrem System

  Für die Offline-Nutzung sind die Versionshinweise auch unter `/usr/share/doc/release-notes` auf Ihrem System verfügbar. Die Dokumentation zu den einzelnen Paketen finden Sie unter `/usr/share/doc/packages`.

  Viele Befehle sind auch auf den Handbuchseiten beschrieben. Führen Sie zu deren Anzeige `man` gefolgt von einem bestimmten Befehlsnamen aus. Sollte der `man`-Befehl nicht auf Ihrem System installiert sein, müssen Sie es mit `sudo zypper install man` installieren.

## 2 Verbessern der Dokumentation #

Feedback und Beiträge Ihrerseits zu dieser Dokumentation sind willkommen. Für Feedback stehen die folgenden Kanäle zur Verfügung:

Serviceanforderungen und Support

  Informationen zu Diensten und Support-Optionen, die für Ihr Produkt verfügbar sind, finden Sie in https://www.suse.com/support/.

  Zum Öffnen einer Service-Anforderung benötigen Sie ein SUSE-Abonnement, das beim SUSE Customer Center registriert ist. Gehen Sie zu https://scc.suse.com/support/requests, melden Sie sich an und klicken Sie auf Neu erstellen.

Fehlerberichte

  Melden Sie Probleme mit der Dokumentation unter https://bugzilla.suse.com/.

  Klicken Sie zur Vereinfachung dieses Vorgangs neben einer Überschrift in der HTML-Version dieses Dokuments auf das Symbol für Report an issue (Problem melden). Dadurch wird das richtige Produkt und die Kategorie in Bugzilla vorab ausgewählt und ein Link zum aktuellen Abschnitt hinzugefügt. Sie können somit sofort mit der Eingabe Ihres Berichts beginnen.

  Ein Bugzilla-Konto ist erforderlich.

Beiträge

  Wenn Sie zu dieser Dokumentation beitragen möchten, klicken Sie neben einer Überschrift in der HTML-Version dieses Dokuments auf das Symbol Edit source document (Quelldokument bearbeiten). So gelangen Sie zum Quellcode auf GitHub, wo Sie eine Pull-Anforderung öffnen können.

  Ein GitHub-Konto ist erforderlich.

  Anmerkung: Edit source document (Quelldokument bearbeiten) nur in englischer Version verfügbar

  Die Symbole für Edit source document (Quelldokument bearbeiten) sind nur in der englischen Version der Dokumentation verfügbar. Für alle anderen Sprachen können Sie stattdessen die Symbole für Report an issue (Problem melden) verwenden.

  Weitere Informationen zur Dokumentationsumgebung für diese Dokumentation finden Sie in der README des Repositorys.

E-Mail

  Sie können auch E-Mails mit Fehlerberichten und Feedback zur Dokumentation an <doc-team@suse.com> senden. Geben Sie den Titel des Dokuments, die Produktversion und das Datum der Veröffentlichung des Dokuments an. Stellen Sie außerdem die entsprechende Abschnittsnummer und den Titel bereit (oder geben Sie die URL an), und fügen Sie eine kurze Beschreibung des Problems hinzu.

## 3 Konventionen in der Dokumentation #

Im vorliegenden Dokument werden die folgenden Hinweise und typografischen Konventionen verwendet:

- `/etc/passwd`: Verzeichnis- und Dateinamen

- PLACEHOLDER: Ersetzen Sie PLACEHOLDER durch den tatsächlichen Wert

- `PATH`: Eine Umgebungsvariable

- `ls`, `--help`: Befehle, Optionen und Parameter

- `user`: Der Name eines Benutzers oder einer Gruppe

- package_name: Der Name eines Softwarepakets

- Alt, Alt–F1: Eine zu drückende Taste bzw. Tastenkombination. Tasten werden wie auf einer Tastatur in Großbuchstaben dargestellt.

- Datei, Datei › Speichern unter: Menüelemente, Schaltflächen

- Chapter 1, „Example chapter“: Ein Querverweis auf ein anderes Kapitel in diesem Handbuch.

- Befehle, die mit `root`-Privilegien ausgeführt werden müssen. Sie können diesen Befehlen auch den Befehl `sudo` voranstellen, um sie als nicht privilegierter Benutzer auszuführen:

      # command
      > sudo command

- Befehle, die von nicht privilegierten Benutzern ausgeführt werden können:

      > command

- Befehle können durch ein Backslash-Zeichen (`\`) am Ende einer Zeile in zwei oder mehrere Zeilen aufgeteilt werden. Mit dem Backslash wird die Shell darüber informiert, dass der Befehlsaufruf nach dem Ende der Zeile fortgesetzt wird:

      > echo a b \
      c d

- Ein Codeblock, der sowohl den Befehl (mit vorangestellter Eingabeaufforderung) als auch die entsprechende von der Shell zurückgegebene Ausgabe anzeigt:

      > command
      output

- Hinweise

  Warnung: Warnhinweis

  Wichtige Informationen, die Sie kennen müssen, bevor Sie fortfahren. Warnt vor Sicherheitsrisiken, potenziellen Datenverlusten, Beschädigung der Hardware oder physischen Gefahren.

  Wichtig: Wichtiger Hinweis

  Wichtige Informationen, die Sie beachten sollten, bevor Sie den Vorgang fortsetzen.

  Anmerkung: Anmerkung

  Ergänzende Informationen, beispielsweise zu unterschiedlichen Softwareversionen.

  Tipp: Tipp

  Hilfreiche Informationen, etwa als Richtlinie oder praktische Empfehlung.

- Kompaktinfos

  Ergänzende Informationen, beispielsweise zu unterschiedlichen Softwareversionen.

  Hilfreiche Informationen, etwa als Richtlinie oder praktische Empfehlung.

## 4 Support #

Nachfolgend finden Sie die Supportbestimmung für SUSE Linux Enterprise Desktop und allgemeine Informationen zu Technologievorschauen. Details über den Produktlebenszyklus finden Sie in https://www.suse.com/lifecycle.

Wenn Sie Anspruch auf Support haben, finden Sie Details zum Sammeln von Informationen für ein Support-Ticket unter https://documentation.suse.com/sles-15/html/SLES-all/cha-adm-support.html.

### 4.1 Erläuterung zum Support für SUSE Linux Enterprise Desktop #

Sie benötigen ein entsprechendes Abonnement bei SUSE, um Support zu erhalten. Gehen Sie zur Anzeige der für Sie verfügbaren spezifischen Support-Angebote zu https://www.suse.com/support/ und wählen Sie das betreffende Produkt aus.

Die Support-Level sind folgendermaßen definiert:

L1

  Problemermittlung: Technischer Support mit Informationen zur Kompatibilität, Nutzungs-Support, kontinuierliche Wartung, Informationssammlung und einfache Problembehandlung anhand der verfügbaren Dokumentation.

L2

  Problemisolierung: Technischer Support zur Datenanalyse, Reproduktion von Kundenproblemen, Isolierung eines Problembereichs und Lösung für Probleme, die in Stufe 1 nicht gelöst wurden, sowie Vorbereitung für Stufe 3.

L3

  Problembehebung: Technischer Support zur Lösung von Problemen durch technische Maßnahmen zur Behebung von Produktfehlern, die durch den Support der Stufe 2 erkannt wurden.

Vertragskunden und Partner erhalten SUSE Linux Enterprise Desktop mit L3-Support für alle Pakete, ausgenommen:

- Technologievorschauen

- Audio, Grafik, Schriftarten und Artwork

- Pakete, für die ein zusätzlicher Kundenvertrag erforderlich ist

- Pakete mit der Namensendung -devel (die Header-Dateien und ähnliche Entwicklerressourcen enthalten) werden nur zusammen mit den entsprechenden Hauptpaketen unterstützt.

SUSE unterstützt nur die Nutzung von Originalpaketen, also unveränderte und nicht kompilierte Pakete.

### 4.2 Technologievorschauen #

Mit Technologievorschauen sind Pakete, Stacks oder Funktionen gemeint, die SUSE bereitstellt, um einen kurzen Einblick in bevorstehende Innovationen zu geben. Durch Technologievorschauen haben Sie die Möglichkeit, neue Technologien in Ihrer Umgebung zu testen. Über Ihr Feedback würden wir uns sehr freuen. Wenn Sie eine Technologievorschau testen, kontaktieren Sie bitte Ihre Ansprechpartner bei SUSE und teilen Sie ihnen Ihre Erfahrungen und Anwendungsfälle mit. Ihr Input ist für zukünftige Entwicklungen sehr hilfreich.

Technologievorschauen weisen die folgenden Einschränkungen auf:

- Technologievorschauen befinden sich noch in Entwicklung. Daher sind die Funktionen möglicherweise unvollständig, instabil oder aus anderen Gründen nicht für die Produktionsnutzung geeignet.

- Technologievorschauen werden nicht unterstützt.

- Technologievorschauen sind möglicherweise nur für bestimmte Hardwarearchitekturen verfügbar.

- Details und Funktionen von Technologievorschauen sind Änderungen unterworfen. Upgrades auf Folgeversionen sind demnach nicht möglich und erfordern eine Neuinstallation.

- SUSE kann feststellen, dass eine Vorschau nicht den Kunden- oder Marktanforderungen entspricht oder nicht mit den Unternehmensstandards übereinstimmt. Technologievorschauen können jederzeit aus einem Produkt entfernt werden. SUSE ist nicht verpflichtet, eine unterstützte Version dieser Technologie in der Zukunft bereitzustellen.

Eine Übersicht der Technologievorschauen, die im Lieferumfang Ihres Produkts enthalten sind, finden Sie in den Versionshinweisen unter https://www.suse.com/releasenotes.

# 1 Lebenszyklus und Unterstützung #

In diesem Kapitel finden Sie Hintergrundinformationen zur Terminologie, zu den Lebenszyklen und Service-Pack-Versionen der SUSE-Produkte sowie zu den empfohlenen Upgraderichtlinien.

## 1.1 Terminologie #

In diesem Kapitel werden verschiedene Begriffe verwendet. Lesen Sie zum besseren Verständnis der Informationen die unten stehenden Definitionen:

Rückportierung

  Bei der Rückportierung werden bestimmte Änderungen aus einer neueren Software-Version auf eine ältere Version angewendet. Dies ist am häufigsten beim Beheben von Sicherheitslücken in älteren Software-Komponenten der Fall. In der Regel gehört dieser Vorgang auch zu einem Wartungsmodell, bei dem Verbesserungen oder (seltener) neue Funktionen bereitgestellt werden.

Delta-RPM

  Ein Delta-RPM besteht nur aus der binären diff zwischen zwei definierten Versionen eines Pakets und hat daher die kleinste Downloadgröße. Vor der Installation muss das vollständige RPM-Paket auf dem lokalen Rechner neu aufgebaut werden.

Downstream

  Bildlicher Ausdruck, wie Software in der Open-Source-Welt entwickelt wird (vgl. Upstream). Mit Downstream werden Personen oder Organisationen wie SUSE bezeichnet, die den Upstream-Quellcode in andere Software integrieren und so eine Distribution zusammenstellen, die dann von den Endbenutzern verwendet wird. So wandert die Software in Downstream-Richtung von den Entwicklern über die Integratoren bis hin zu den Endbenutzern.

Erweiterung, Add-on-Produkt

  Erweiterungen und Add-on-Produkte von Drittanbietern bieten zusätzliche Funktionen, die den Nutzwert von SUSE Linux Enterprise Desktop darstellen. Sie werden von SUSE und SUSE-Partnern bereitgestellt und werden zusätzlich zum Basisprodukt SUSE Linux Enterprise Desktop registriert und installiert.

Hauptversion, Version zur allgemeinen Verfügung (General Availability, GA)

  Die Hauptversion von SUSE Linux Enterprise (oder von einem beliebigen Softwareprodukt) ist eine neue Version mit neuen Funktionen und Tools. Sie setzt vorher veraltete Komponenten außer Kraft und führt Änderungen ein, die nicht rückwärtskompatibel sind. Hauptversionen sind beispielsweise SUSE Linux Enterprise 12 oder 15.

Migration

  Aktualisierung auf ein Service Pack (SP), bei der die erforderlichen Patches über die Online-Aktualisierungswerkzeuge oder ein Installationsmedium installiert werden. Dadurch werden alle Pakete des installierten Systems auf den neuesten Stand gebracht.

Migrationsziel

  Ein kompatibles Produkt, auf das ein System migriert werden kann (mit Produktversion, Erweiterungen und URL des Repositorys). Die Migrationsziele können sich im Lauf der Zeit ändern und sind abhängig von den installierten Erweiterungen. Es ist möglich, mehrere Migrationsziele auszuwählen.

Modul

  Module sind vollständig unterstützte Bestandteile von SUSE Linux Enterprise Desktop, die einen anderen Lebenszyklus aufweisen. Die Module besitzen einen klar definierten Umfang und werden ausschließlich über einen Online-Kanal bereitgestellt. Diese Kanäle können Sie nur dann abonnieren, wenn Sie sich beim SUSE Customer Center, beim RMT (Repository Mirroring Tool) oder beim SUSE Multi-Linux Manager registriert haben.

Paket

  Ein Paket ist eine komprimierte Datei im `rpm`-Format, die die Dateien für ein bestimmtes Programm enthält oder auch optionale Komponenten wie Konfigurationen, Beispiele und Dokumentation.

Patch

  Ein Patch enthält mindestens ein Paket und kann per Delta-RPMs angewendet werden. Unter Umständen werden auch Abhängigkeiten zu Paketen aufgebaut, die noch nicht installiert wurden.

Service Pack (SP)

  Ein Service Pack kombiniert mehrere Patches zu einem "Paket", das einfach zu installieren bzw. bereitzustellen ist. Service Packs sind nummeriert und enthalten üblicherweise Sicherheits-Fixes, Upgrades oder Programmerweiterungen.

Upstream

  Bildlicher Ausdruck, wie Software in der Open-Source-Welt entwickelt wird (vgl. Downstream). Mit Upstream wird das ursprüngliche Projekt, der Autor oder der Betreuer einer Software bezeichnet, die als Quellcode verteilt wird. Rückmeldungen, Patches, Funktionsoptimierungen und andere Verbesserungen wandern von den Endbenutzern oder Beteiligten zu den Upstream-Entwicklern. Diese entscheiden, ob die Anforderung integriert oder abgelehnt wird.

  Wenn die Projektmitglieder entscheiden, die Anforderung zu integrieren, wird diese in den neuen Versionen der Software auftreten. Eine akzeptierte Anforderung bietet Nutzen für alle Beteiligten.

  Falls eine Anforderung abgelehnt wird, kommen hierfür unterschiedliche Gründe in Betracht. Die Anforderung weist einen Status auf, der nicht den Richtlinien des Projekts entspricht, sie ist ungültig, wurde bereits integriert oder liegt nicht im Interesse oder im Gesamtplan des Projekts. Eine nicht akzeptierte Anforderung erschwert die Arbeit für die Upstream-Entwickler, da sie ihre Patches mit dem Upstream-Code synchron halten müssen. Diese Vorgehensweise wird daher weitestgehend vermieden, ist jedoch in einigen Fällen unumgänglich.

Aktualisieren Sie

  Installation einer neueren Unterversion eines Pakets, die in der Regel Sicherheitsverbesserungen oder Fehlerbehebungen enthält.

Aufrüsten

  Installation einer neueren Hauptversion eines Pakets oder einer Distribution, die neue Funktionen enthält. In Abschnitt 2.2, „Online- und Offline-Upgrade“. finden Sie Informationen zu den Unterschieden zwischen den Upgrade-Optionen.

## 1.2 Produktlebenszyklus #

Für SUSE-Produkte gelten die folgenden Produktlebenszyklen:

- Novell garantiert einen Lebenszyklus von 13 Jahren für SUSE Linux Enterprise Server: 10 Jahre allgemeine Unterstützung und drei Jahre erweiterter Support.

- SUSE Linux Enterprise Desktop hat einen Lebenszyklus von 10 Jahren: Sieben Jahre allgemeiner Support und drei Jahre erweiterter Support.

- Hauptversionen werden alle vier Jahre veröffentlicht. Service Packs werden alle 12 bis 14 Monate bereitgestellt.

SUSE unterstützt ältere Service Packs weitere sechs Monate nach Bereitstellung eines neueren Service Packs. Abbildung 1.1, „Hauptversionen und Service Packs“ zeigt einige der erwähnten Aspekte.

Abbildung 1.1: Hauptversionen und Service Packs #

Wenn Sie zusätzliche Zeit zum Gestalten, Validieren und Testen Ihrer Upgradepläne benötigen, können Sie Ihren Support mit dem Long Term Service Pack Support um weitere 12 bis 36 Monate (in Intervallen von 12 Monaten) verlängern. So erhalten Sie insgesamt 2 bis 5 Jahre Support für jedes Service Pack. Weitere Informationen finden Sie in Abbildung 1.2, „Langfristiger Service Pack-Support“.

Abbildung 1.2: Langfristiger Service Pack-Support #

Weitere Informationen hierzu finden Sie in https://www.suse.com/products/long-term-service-pack-support/.

Weitere Informationen zu Lebenszyklen, Veröffentlichungshäufigkeit sowie überlappender Unterstützung finden Sie in https://www.suse.com/lifecycle.

## 1.3 Abhängigkeiten und Lebenszyklen der Module #

In Article “Modules and Extensions Quick Start” finden Sie eine Liste der Module mit ihren Abhängigkeiten und Lebenszyklen.

## 1.4 Generieren eines regelmäßigen Lebenszyklusberichts #

SUSE Linux Enterprise Desktop kann regelmäßig nach Supportstatus-Aktualisierungen aller installierten Produkte suchen und bei Änderungen einen Bericht per E-Mail versenden. Installieren Sie zypper-lifecycle-plugin mit `zypper in zypper-lifecycle-plugin`, um den Bericht zu generieren.

Aktivieren Sie die Berichterzeugung auf dem System mit `systemctl`:

    > sudo systemctl enable lifecycle-report.timer

Der Empfänger und der Betreff der Bericht-E-Mail sowie das Intervall für die Berichterzeugung können mit einem beliebigen Texteditor in der Datei `/etc/sysconfig/lifecycle-report` konfiguriert werden. Die Einstellungen `MAIL_TO` und `MAIL_SUBJ` definieren den Empfänger und den Betreff der E-Mail und `DAYS` bezeichnet das Intervall, in dem die Berichte erzeugt werden sollen.

Änderungen des Supportstatus werden erst nach Eintreten einer Änderung im Bericht sichtbar, nicht schon im Voraus. Wird eine Änderung unmittelbar nach dem Erzeugen des letzten Berichts vorgenommen, kann es bis zu 14 Tage dauern, bis Sie über diese Änderung informiert werden. Berücksichtigen Sie diesen Punkt, wenn Sie die Option `DAYS` festlegen. Ändern Sie die folgenden Konfigurationseinträge gemäß Ihren Anforderungen:

    MAIL_TO='root@localhost'
    MAIL_SUBJ='Lifecycle report'
    DAYS=14

Der aktuelle Bericht befindet sich in der Datei `/var/lib/lifecycle/report`. Die Datei umfasst zwei Abschnitte. Im ersten Abschnitt finden Sie Informationen zum Supportende für die verwendeten Produkte. Der zweite Abschnitt listet Pakete mit dem zugehörigen Datum des Supportendes und der eventuellen Verfügbarkeit von Aktualisierungen auf.

## 1.5 Supportstufen #

Der Bereich für erweiterte Supportstufen beginnt in Jahr 10 und endet in Jahr 13. Sie umfassen fortlaufende L3-Diagnose auf technischer Ebene und rückwirkende Behebung kritischer Fehler. Mit diesen Supportstufen erhalten Sie Aktualisierungen für root-Sicherheitsanfälligkeiten im Kernel und andere root-Sicherheitsanfälligen als direkt ausführbare Datei, die ohne Eingreifen des Benutzers abgearbeitet wird. Darüber hinaus werden vorhandene Workloads, Softwarestapel und Hardware mit einer limitierten Paketausschlussliste unterstützt. Einen Überblick finden Sie in Tabelle 1.1, „Sicherheitsaktualisierungen und Fehlerbehebungen“.

Tabelle 1.1: Sicherheitsaktualisierungen und Fehlerbehebungen #

| Allgemeiner Support für den neuesten Service Pack (SP) | Allgemeiner Support für einen älteren SP, mit LTSS | Erweiterter Support mit LTSS
--- | --- | --- | ---
Funktion | Jahr 1 bis 5 | Jahr 6 bis 7 | Jahr 8 bis 10 | Jahr 4 bis 10 | Jahr 10 bis 13
Technischer Support | Ja | Ja | Ja | Ja | Ja
Zugriff auf Patches und Reparaturen | Ja | Ja | Ja | Ja | Ja
Zugriff auf Dokumentation und Wissensdatenbank | Ja | Ja | Ja | Ja | Ja
Support für vorhandene Stacks und Workloads | Ja | Ja | Ja | Ja | Ja
Support für neue Bereitstellungen | Ja | Ja | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Nein
Verbesserungsanfragen | Ja | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Nein | Nein
Hardwareaktivierung und -optimierung | Ja | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Nein | Nein
Treiberaktualisierungen über SUSE SolidDriver Program (früher PLDP) | Ja | Ja | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Nein
Rückportierung von Reparaturen aus einem früheren SP | Ja | Ja | Eingeschränkt (basierend auf Partner- und Kundenanforderungen) | Nicht zutreffend | Nicht zutreffend
Sicherheitsaktualisierungen1 | Alle | Alle | Alle | Nur kritische | Nur kritische
Fehlerhafte Auflösung | Ja | Ja | Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2) | Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2) | Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2)

1 Weitere Informationen zur SUSE Linux Enterprise-Aktualisierungsrichtlinie finden Sie in folgendem Artikel in der Wissendatenbank.

## 1.6 Registrieren von Computern und Aufheben der Registrierung mit SUSEConnect #

Beim Registrieren erhält das System verschiedene Repositorys aus dem SUSE Custom Center (siehe https://scc.suse.com/) oder von einem lokalen Registrierungs-Proxy wie SMT. Die Repository-Namen sind bestimmten URIs im Customer Center zugeordnet. Zum Auflisten aller verfügbaren Repositorys auf dem System geben Sie das folgende `zypper`-Kommando ein:

    # zypper repos -u

Hiermit erhalten Sie eine Liste aller verfügbaren Repositorys auf dem System. Für jedes Repository werden der Alias und der Name aufgeführt, und es ist angegeben, ob das Repository aktiviert ist und jeweils auf den neuesten Stand gebracht wird. Mit der Option `-u` erhalten Sie außerdem die URI, von der es stammt.

Zum Registrieren des Computers führen Sie SUSEConnect aus, beispielsweise:

    # SUSEConnect -r REGCODE

Über SUSEConnect können Sie die Registrierung des Computers auch wieder aufheben:

    # SUSEConnect --de-register

Mit dem folgenden Kommando können die lokal installierten Produkte und deren Status geprüft werden:

    # SUSEConnect -s

## 1.7 Ermitteln der SLE-Version #

Die Version einer SLE-Installation lässt sich anhand des Inhalts der Datei `/etc/os-release` ermitteln.

`zypper` bietet eine maschinenlesbare XML-Ausgabe:

    > zypper --no-remote --no-refresh --xmlout --non-interactive products -i
    <?xml version='1.0'?>
    <stream>
    <product-list>
    <product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
    </product-list>
    </stream>

# 2 Upgrade-Pfade und -Methoden #

SUSE® Linux Enterprise (SLE) ermöglicht das Upgrade eines bestehenden Systems auf eine neuere Version oder ein Service Pack. Es ist keine neue Installation erforderlich. Bestehende Daten wie Home- und Datenverzeichnisse sowie Systemkonfigurationen bleiben erhalten. Sie können die Aktualisierung von einem lokalen CD- oder DVD-Laufwerk oder von einer zentralen Netzwerkinstallationsquelle durchführen.

## 2.1 Upgrade im Vergleich zu Neuinstallation #

Upgrades zwischen zwei Hauptversionen von SUSE Linux Enterprise Desktop werden von SUSE unterstützt. Ob es besser ist, ein Upgrade durchzuführen oder eine Neuinstallation vorzunehmen, hängt von Ihrem spezifischen Szenario ab. Das Upgrade ist zwar mit weniger Aufwand verbunden, aber eine Neuinstallation stellt sicher, dass Sie von allen neuen Funktionen einer Version profitieren, wie z. B. Änderungen am Layout der Festplatte, speziellen Funktionen des Dateisystems und anderen Verbesserungen. Um Ihr System optimal nutzen zu können, empfiehlt SUSE daher in den meisten Szenarien eine Neuinstallation.

In beiden Fällen – sowohl beim Upgrade als auch bei der Neuinstallation – muss der Kunde prüfen, ob die Systemeinstellungen und Standardwerte noch ihren Anforderungen entsprechen.

Für ein Update von einem Service Pack einer bestimmten Version auf ein anderes Service Pack desselben Codestreams empfiehlt SUSE, dieses direkt vorzunehmen und keine Neuinstallation durchzuführen. Jedoch kann es in bestimmten Szenarien Gründe für eine Neuinstallation geben. Diese Entscheidung kann nur der Kunde treffen.

## 2.2 Online- und Offline-Upgrade #

SUSE unterstützt zwei verschiedene Upgrade- und Migrationsmethoden. Weitere Informationen zu diesen Begriffen finden Sie in Abschnitt 1.1, „Terminologie“. Die folgenden Methoden werden unterstützt:

Online

  Upgrades, die vom laufenden Betriebssystem selbst ausgeführt werden (System aktiv). Beispiele: Online-Aktualisierung mit Zypper oder YaST, verbunden über das SUSE Customer Center oder Repository Mirroring Tool (RMT), Salt Policy über SUSE Multi-Linux Manager.

  Weitere Informationen finden Sie in Kapitel 5, Online-Upgrade.

  Zur Migration auf andere Service Packs derselben Hauptversion wird Abschnitt 5.4, „Upgraden mit dem Werkzeug für die Online-Migration (YaST)“ oder Abschnitt 5.5, „Upgraden mit zypper“ empfohlen.

Offline

  Eine Offline-Aufrüstung impliziert, dass das aufzurüstende Betriebssystem nicht ausgeführt wird (System nicht aktiv). Stattdessen wird das Installationsprogramm für das Zielbetriebssystem gebootet (zum Beispiel von einem Installationsmedium, über das Netzwerk oder einen lokalen Bootloader) und führt das Upgrade durch.

  Weitere Informationen finden Sie in Kapitel 4, Offline-Upgrade.

Wichtig: SUSE Multi-Linux Manager-Clients

Wenn Ihr Rechner mit SUSE Multi-Linux Manager verwaltet wird, aktualisieren Sie das Programm entsprechend der Beschreibung in der Dokumentation zu SUSE Multi-Linux Manager. Das Verfahren zur Client Migration ist in SUSE Multi-Linux Manager Upgrade Guide beschrieben, das unter https://documentation.suse.com/multi-linux-manager/ verfügbar ist.

## 2.3 Unterstützte Upgrade- und Migrationspfade auf SLED 15 SP7 #

Vor der Migration beachten Sie Kapitel 3, Vorbereiten des Upgrades.

Wichtig: Architekturübergreifende Upgrades werden nicht unterstützt

Architekturübergreifende Upgrades wie von einer 32-Bit-Version von SUSE Linux Enterprise Desktop auf die 64-Bit-Version oder das Upgrade von Big Endian auf Little Endian werden nicht unterstützt.

Da SUSE Linux Enterprise 15 nur in der 64-Bit-Version verfügbar ist, werden Aufrüstungen von 32-Bit-Systemen von SUSE Linux Enterprise 11 auf SUSE Linux Enterprise 15 und höher nicht unterstützt.

Ist ein architekturübergreifendes Upgrade erforderlich, so muss eine Neuinstallation ausgeführt werden.

Anmerkung: Überspringen von Service Packs

Das Überspringen von Service Packs wird unter SUSE Linux Enterprise Desktop nicht unterstützt. Alle Service Packs müssen nacheinander installiert werden.

Abbildung 2.1: Überblick über die unterstützten Upgrade-Pfade #
Warnung: Upgrade von Datenbanken

Die hier beschriebenen Upgrade-Pfade gelten nur für SUSE Linux Enterprise als Betriebssystem eines Rechners, nicht für alle Anwendungen, die darauf ausgeführt werden. Bei Workloads wie PostgreSQL- oder MariaDB-Datenbanken können vorläufige Betriebssystem-Upgrades erforderlich sein, um Ihre Anwendungen zu aktualisieren.

Lesen Sie vor dem Upgrade des Betriebssystems die Versionshinweise für Informationen zu den Datenbankversionen. Wenn eine neue Hauptversion ausgeliefert wird, finden Sie die Anweisungen für ein Upgrade in Kapitel 3, Vorbereiten des Upgrades.

Unterstützte Upgrade-Pfade pro Version #

Upgrade von SUSE Linux Enterprise Desktop 12 GA/SP1/SP2

  Ein direktes Upgrade von SLED 12 SP2 oder älteren Service Packs wird nicht unterstützt. Sie benötigen mindestens SLED 12 SP3 oder SP4, bevor Sie mit SLED 15 GA oder SP1 fortfahren können. Installieren Sie dann nacheinander alle Service Packs bis zu SLED 15 SP7.

  Falls Sie keine Neuinstallation ausführen können, führen Sie zunächst ein Upgrade des installierten SLED 12-Service Packs auf SLED 12 SP3 oder SP4 durch. Dieser Upgrade-Vorgang wird unter SLED 12 SP4 Deployment Guide beschrieben.

Upgrade von SUSE Linux Enterprise Desktop 12 SP3/SP4

  Ein direktes Upgrade von SLED 12 SP4 oder älteren Service Packs wird nicht unterstützt. Sie müssen zunächst ein Upgrade auf SLED 15 GA oder SP1 durchführen, bevor Sie mit SLED 15 SP7 fortfahren können, indem Sie nacheinander alle Service Packs installieren.

  Falls Sie keine Neuinstallation ausführen können, führen Sie zunächst ein Upgrade des installierten SLED 12 SP3 oder SP4 auf SLED 15 GA oder SP1 durch. Dieser Upgrade-Vorgang wird unter SLED 12 SP4 Deployment Guide beschrieben.

Upgrade von SUSE Linux Enterprise Desktop 15 GA/SP1/SP2/SP3/SP4/SP5

  Ein Upgrade direkt von SLED 15 GA, SP1, SP2, SP3, SP4 oder SP5 wird nicht unterstützt. Sie benötigen mindestens SLED 15 SP6, bevor Sie mit SLED 15 SP7 fortfahren können.

Upgrade von SUSE Linux Enterprise Desktop 15 SP6

  Ein Upgrade von SLED 15 SP6 wird sowohl online als auch offline unterstützt. Weitere Informationen finden Sie in Abschnitt 2.2, „Online- und Offline-Upgrade“.

# 3 Vorbereiten des Upgrades #

Vor Beginn des Upgrades muss das System ordnungsgemäß vorbereitet werden. Zur Vorbereitung gehören unter anderem das Sichern der Daten und das Lesen der Versionshinweise. Im folgenden Kapitel werden Sie durch diese Schritte geführt.

## 3.1 Prüfen, ob das System auf dem neuesten Stand ist #

Ein Upgraden des Systems wird nur von der jeweils letzten Patch-Stufe aus unterstützt. Prüfen Sie, ob die neuesten Systemaktualisierungen installiert sind. Führen Sie hierzu entweder `zypper patch` aus oder starten Sie das YaST-Modul Online-Update.

Anmerkung: Neuer 4096-Bit-Signierschlüssel für SUSE Linux Enterprise 15

Mitte 2023 wurde die SUSE Linux Enterprise 15-Produktfamilie von einem RSA 2048-Bit-Signierschlüssel auf einen neuen RSA 4096-Bit-Schlüssel umgestellt. Diese Änderung betrifft RPM-Pakete, Paket-Repositorys und ISO-Signaturen. Alte Repositorys, die nicht mehr aktualisiert werden, und RPMs, die bis zum Zeitpunkt der Umstellung veröffentlicht wurden, bleiben mit dem alten 2048-Bit-Schlüssel signiert.

Wenn Sie Ihr System aktualisieren, wird der neue Schlüssel automatisch in den RPM-Schlüsselring aus dem suse-build-key-Paket auf SLE 15 SP 4 und SP5 sowie den LTSS-Versionen von SLE 15 SP1, SP2 und SP3 importiert.

Wenn der Schlüssel noch nicht importiert wurde, können Sie ihn manuell importieren mit:

    > sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

Wenn Sie eine ältere Version von SLE verwenden oder den neuen Schlüssel nicht importiert haben, werden Sie während des Upgrades aufgefordert, ihm zu vertrauen. Versichern Sie sich, dass der Fingerabdruck übereinstimmt:

    pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
    Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
    uid           SUSE Package Signing Key <build@suse.de>

Zusätzlich wurde ein 4096-Bit-RSA-Reserveschlüssel für Disaster Recovery-Zwecke importiert:

    pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
    Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
    uid           SUSE Package Signing Key (reserve key) <build@suse.de>

Dieser Schlüssel kann manuell importiert werden mit:

    > sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

Beide Schlüssel finden Sie auch auf dem Installationsmedium und auf der SUSE-Website unter https://www.suse.com/support/security/keys/.

## 3.2 Lesen Sie die Versionshinweise #

Eine Liste aller Änderungen, neuen Funktionen und bekannten Probleme finden Sie in den Versionshinweisen. Die Versionshinweise finden Sie auch auf den Installationsmedien im Verzeichnis `docu`.

Die Versionshinweise enthalten in der Regel nur die Änderungen zwischen zwei aufeinander folgenden Versionen. Falls Sie mindestens ein Service Pack überspringen, beachten Sie auch die Versionshinweise der übersprungenen Service Packs.

Lesen Sie die Versionshinweise, um zu prüfen, ob Folgendes zutrifft:

- Sind bei der Hardware besondere Überlegungen zu beachten?

- Wurden erhebliche Änderungen an den aktuell verwendeten Softwarepaketen vorgenommen?

- Erfordert Ihre Installation besondere Vorsichtsmaßnahmen?

## 3.3 Eine Sicherung erstellen #

Sichern Sie vor dem Upgrade Ihre Daten, indem Sie die vorhandenen Konfigurationsdateien auf ein separates Medium (z. B. Bandgerät, externe Festplatte usw.) kopieren. Dies gilt vor allem für Dateien, die in `/etc` gespeichert sind sowie einige Verzeichnisse und Dateien in `/var` und `/opt`. Zudem empfiehlt es sich, die Benutzerdaten in `/home` (den `HOME`-Verzeichnissen) auf ein Sicherungsmedium zu schreiben.

Melden Sie sich zur Sicherung dieser Daten als `root` an. Nur der Benutzer `root` verfügt über die Berechtigungen für alle lokalen Dateien.

Wenn Sie in YaST den Installationsmodus Vorhandenes System aktualisieren ausgewählt haben, können Sie später wahlweise eine (System-)Sicherung ausführen. Sie können alle geänderten Dateien und die Dateien aus dem Verzeichnis `/etc/sysconfig` einschließen. Dies ist allerdings keine vollständige Sicherung, da alle anderen wichtigen, oben genannten Verzeichnisse außer Acht gelassen werden. Die Sicherungskopie befindet sich im Verzeichnis `/var/adm/backup`.

## 3.4 Verfügbaren Speicherplatz prüfen #

Software weist normalerweise von Version zu Version mehr Umfang auf. Folglich sollten Sie vor dem Aktualisieren den verfügbaren Partitionsspeicher überprüfen. Wenn Sie befürchten, dass der Speicherplatz nicht ausreicht, sichern Sie Ihre Daten und erhöhen Sie dann den verfügbaren Speicherplatz, indem Sie beispielsweise die Größe von Partitionen ändern. Es gibt keine Faustregel hinsichtlich des Speicherplatzes einzelner Partitionen. Die Platzanforderungen hängen von Ihrem bestimmten Partitionsprofil und von der ausgewählten Software ab.

Anmerkung: Automatische Prüfung des verfügbaren Speicherplatzes in YaST

YaST prüft während des Aktualisierungsvorgangs den freien verfügbaren Speicherplatz und zeigt dem Benutzer eine Warnmeldung an, wenn die verfügbare Menge möglicherweise nicht für die Installation ausreicht. Wenn Sie die Aktualisierung in diesem Fall dennoch durchführen, kann das System unbrauchbar werden! Sie sollten die Warnmeldung nur dann ignorieren und mit der Aktualisierung fortfahren, wenn Sie genau wissen, was Sie tun (da Sie dies in einem Vorabtest abgeklärt haben).

### 3.4.1 Ermitteln des freien Speicherplatzes auf Nicht-Btrfs-Dateisystemen #

Listen Sie mit dem Kommando `df` den verfügbaren Speicherplatz auf. In Beispiel 3.1, „Über `df ‑h` angezeigte Liste“ ist beispielsweise `/dev/sda3` die root-Partition (eingehängt als `/`).

Beispiel 3.1: Über `df ‑h` angezeigte Liste #

    Filesystem     Size  Used Avail Use% Mounted on
         /dev/sda3       74G   22G   53G  29% /
         tmpfs          506M     0  506M   0% /dev/shm
         /dev/sda5      116G  5.8G  111G   5% /home
         /dev/sda1       39G  1.6G   37G   4% /windows/C
         /dev/sda2      4.6G  2.6G  2.1G  57% /windows/D

### 3.4.2 Ermitteln des freien Speicherplatzes auf Btrfs-root-Dateisystemen #

Bei einem Btrfs-Dateisystem kann die Ausgabe von `df` irreführend sein, da ein Btrfs-Dateisystem zusätzlich zu dem Speicherplatz, den die Rohdaten belegen, auch Speicherplatz für Metadaten zuweist und verwendet.

Folglich meldet ein Btrfs-Dateisystem womöglich, dass es keinen Speicherplatz mehr hat, obwohl anscheinend noch genügend vorhanden ist. In diesem Fall ist der gesamte Speicherplatz, der den Metadaten zugeordnet ist, belegt. Weitere Informationen finden Sie in `man 8 btrfs-filesystem` und https://btrfs.wiki.kernel.org/index.php/FAQ.

Wenn Sie Btrfs als root-Dateisysteme auf dem Rechner nutzen, muss ausreichend freier Speicherplatz zur Verfügung stehen. Prüfen Sie den verfügbaren Speicherplatz auf allen eingehängten Partitionen. Im schlimmsten Fall belegt ein Upgrade ebenso viel Speicherplatz wie das aktuelle root-Dateisystem (ohne `/.snapshot`) für einen neuen Snapshot.

Die folgenden Empfehlungen haben sich bewährt:

- Für alle Dateisysteme, einschließlich Btrfs, benötigen Sie genügend freien Speicherplatz, um große RPMs herunterzuladen und zu installieren. Der Speicherplatz der alten RPMs wird erst dann freigegeben, wenn die neuen RPMs installiert sind.

- Bei Btrfs mit Snapshots benötigen Sie mindestens so viel freien Speicherplatz, wie von der aktuellen Installation belegt wird. Es wird mindestens der doppelte freie Speicherplatz empfohlen, wie von der aktuellen Installation belegt wird.

  Falls nicht ausreichend freier Speicherplatz verfügbar ist, können Sie ältere Snapshots mit `snapper` löschen:

      # snapper list
            # snapper delete NUMBER

  Dies reicht jedoch nicht in allen Fällen aus. Vor der Migration belegen die meisten Snapshots nur wenig Platz.

## 3.5 Auflisten installierter Pakete und Repositorys #

Sie können eine Liste der installierten Pakete speichern; beispielsweise bei einer Neuinstallation einer neuen SLE-Hauptversion oder beim Zurücksetzen des Systems auf die bisherige Version.

Anmerkung

Denken Sie daran, dass nicht alle installierten Pakete oder verwendeten Repositorys in neueren Versionen von SUSE Linux Enterprise vorliegen. Einige Elemente wurden unter Umständen umbenannt, andere ersetzt. Außerdem könnten bestimmte Pakete weiterhin zu Legacy-Zwecken verfügbar sein, während standardmäßig ein anderes Paket herangezogen wird. Aus diesem Grund müssen die Dateien ggf. manuell bearbeitet werden. Dies können Sie mit einem beliebigen Texteditor durchführen.

1. Erstellen Sie die Datei `repositories.bak.repo` mit einer Liste aller verwendeten Repositorys.

       # zypper lr -e repositories.bak

2. Erstellen Sie außerdem die Datei `installed-software.bak` mit einer Liste aller installierten Pakete:

       # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

3. Erstellen Sie Sicherungskopien beider Dateien. Die Repositorys und die installierten Pakete können mit den folgenden Befehlen wiederhergestellt werden:

       # zypper ar repositories.bak.repo
       # zypper install $(cat installed-software.bak)

   Anmerkung: Bei einer Aktualisierung auf eine neue Hauptversion erhöht sich die Anzahl der Pakete

   Ein System, das auf eine neue Hauptversion upgegradet wurde (SLE X+1), enthält eventuell mehr Pakete als das ursprüngliche System (SLE X). Die Anzahl der Pakete ist außerdem höher als bei einer Neuinstallation von SLE X+1 mit derselben Schemaauswahl. Hierfür sind folgende Gründe zu nennen:

   - Die Pakete wurden aufgeteilt, sodass Sie die gewünschte Paketauswahl noch genauer festlegen können. Beispielsweise wurden 37 texlive-Pakete aus SLE 11 auf mehr als 3000 Pakete in SLE 15 aufgeteilt.

   - Wenn ein Paket aufgeteilt wurde, werden bei einem Upgrade alle neuen Pakete installiert, damit in jedem Fall derselbe Funktionsumfang wie in der früheren Version zur Verfügung steht. Bei einer Neuinstallation von SLE X+1 werden jedoch unter Umständen nicht mehr alle Pakete standardmäßig installiert.

   - Ältere Pakete aus SLE X werden ggf. aus Kompatibilitätsgründen beibehalten.

   - Die Paketabhängigkeiten und der Schemaumfang haben sich unter Umständen geändert.

## 3.6 LTSS-Erweiterung deaktivieren #

Wenn Sie ein SUSE Linux Enterprise Desktop-System mit LTSS (Long Term Service Pack Support) auf eine Version aktualisieren, die noch unter allgemeinem Support steht, schlägt das Upgrade mit dem Fehler `No migration available` fehl. Dies geschieht, weil `zypper migration` versucht, alle Repositorys zu migrieren, es aber noch kein LTSS-Repository für die neue Version gibt.

Deaktivieren Sie zur Behebung dieses Problems die LTSS-Erweiterung vor dem Upgrade.

1. Prüfen Sie, ob die LTSS-Erweiterung aktiviert ist:

       > sudo SUSEConnect --list-extensions | grep LTSS
       SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
       Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

2. Deaktivieren Sie die LTSS-Erweiterung mit dem Befehl aus der `SUSEConnect`-Ausgabe oben:

       > sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
       Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
       To server: https://scc.suse.com/

3. Prüfen Sie, ob das LTSS-Repository bei `zypper lr` nicht mehr vorhanden ist.

## 3.7 Erstellen von Nicht-MD5-Server-Zertifikaten für Java-Anwendungen #

Als Sicherheitsmaßnahme werden MD5-gestützte Zertifikate in Java nicht mehr unterstützt. Wenn Sie über als MD5 erstellte Zertifikate verfügen, erstellen Sie diese mit folgenden Schritten neu:

1. Öffnen Sie ein Terminal und melden Sie sich als `root` an.

2. Erstellen Sie einen privaten Schlüssel:

       # openssl genrsa -out server.key 1024

   Wenn Sie einen Schlüssel mit höherer Sicherheit wünschen, ersetzen Sie `1024` durch eine höhere Zahl, z. B. `4096`.

3. Erstellen Sie einen Zertifizierungsantrag (CSR):

       # openssl req -new -key server.key -out server.csr

4. Führen Sie eine Eigensignierung des Zertifikats durch:

       # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

5. Erstellen Sie die PEM-Datei:

       # cat server.key server.crt > server.pem

6. Legen Sie die Dateien `server.crt`, `server.csr`, `server.key` und `server.pem` in den jeweiligen Verzeichnissen mit den Schlüsseln ab. Für Tomcat beispielsweise lautet das Verzeichnis `/etc/tomcat/ssl/`.

## 3.8 Herunterfahren von VM-Gästen #

Wenn Ihr Rechner als VM-Hostserver für KVM oder Xen fungiert, müssen Sie vor der Aktualisierung alle aktiven VM-Gäste ordnungsgemäß herunterfahren. Andernfalls können Sie nach der Aktualisierung wahrscheinlich nicht mehr auf die Gäste zugreifen.

## 3.9 Einrichtung Ihres SMT-Clients anpassen #

Beachten Sie Folgendes, wenn der Rechner, für den ein Upgrade durchgeführt werden soll, als Client bei einem SMT-Server registriert ist:

Prüfen Sie, ob die Version des `clientSetup4SMT.sh`-Skripts auf Ihrem Host aktuell ist. Das Skript `clientSetup4SMT.sh` aus älteren SMT-Versionen kann keine SMT 12-Clients verwalten. Wenn Sie auf Ihrem SMT-Server regelmäßig Software-Patches anwenden, finden Sie die neueste Version von `clientSetup4SMT.sh` immer unter `<SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh`.

Falls das Upgrade Ihres Rechners auf eine höhere Version von SUSE Linux Enterprise Desktop fehlschlägt, heben Sie die Registrierung des Rechners beim SMT-Server wie in Prozedur 3.1 beschrieben auf. Starten Sie danach den Upgradevorgang neu.

Vorgehen 3.1: Aufheben einer Registrierung von SUSE Linux Enterprise Client bei einem SMT-Server #

1. Melden Sie sich beim Client-Rechner an.

2. Der folgende Schritt hängt vom aktuellen Betriebssystem des Client ab:

   - Für SUSE Linux Enterprise 11 führen Sie folgende Kommandos aus:

         > sudo suse_register -E
         > sudo rm -f /etc/SUSEConnect
         > sudo rm -rf /etc/zypp/credentials.d/*
         > sudo rm -rf /etc/zypp/repos.d/*
         > sudo rm -f /etc/zypp/services.d/*
         > sudo rm -f /var/cache/SuseRegister/*
         > sudo rm -f /etc/suseRegister*
         > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
         > sudo rm -f /etc/zmd/deviceid
         > sudo rm -f /etc/zmd/secret

   - Für SUSE Linux Enterprise 12 führen Sie folgende Kommandos aus:

         > sudo SUSEConnect --de-register
         > sudo SUSEConnect --cleanup
         > sudo rm -f /etc/SUSEConnect
         > sudo rm -rf /etc/zypp/credentials.d/*
         > sudo rm -rf /etc/zypp/repos.d/*
         > sudo rm -f /etc/zypp/services.d/*

3. Melden Sie sich beim SMT-Server an.

4. Prüfen Sie, ob die Registrierung des Client aufgehoben wurde, indem Sie alle Client-Registrierungen aufrufen:

       > sudo smt-list-registrations

5. Wird der Hostname des Client in der Ausgabe dieses Kommandos noch aufgelistet, rufen Sie die `Unique ID` des Client in der ersten Spalte ab. (Der Client ist möglicherweise mit mehreren IDs aufgeführt.)

6. Löschen Sie die Registrierung für diesen Client:

       > sudo smt-delete-registration -g UNIQUE_ID

7. Sollte der Client mit mehreren IDs aufgeführt sein, wiederholen Sie den obigen Schritt für jede einzelne ID.

8. Prüfen Sie danach, ob die Registrierung des Client nun aufgehoben wurde, indem Sie das folgende Kommando erneut ausführen:

       > sudo smt-list-registrations

## 3.10 Passen Sie den Boot-Parameter `resume` an #

Auf Systemen, die mit SUSE Linux Enterprise Desktop 12 oder älter installiert wurden, kann die Standard-Kernel-Kommandozeile in `/etc/default/grub` einen Parameter resume enthalten, der den Namen eines Geräteknotens wie `/dev/sda1` verwendet, um auf das Hibernation-Gerät (Suspend-to-Disk) zu verweisen. Da die Namen von Geräteknoten nicht beständig sind und sich zwischen Neustarts ändern können, ist es sehr empfehlenswert, dies zu korrigieren. Andernfalls kann das aufgerüstete System beim Neustart hängenbleiben.

1. Suchen Sie das Gerät für den Ruhezustand:

       > sudo grep resume /etc/default/grub
       GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"

   Das Gerät für den Ruhezustand ist `/dev/sda1`. Wenn das Kommando nichts zurückgibt, ist der Ruhezustand nicht konfiguriert.

2. Rufen Sie die UUID für `/dev/sda1` ab:

       > sudo blkid /dev/vda1
       /dev/vda1: UUID="a1d1f2e0-b0ee-4be2-83d5-78a98c585827" TYPE="swap" PARTUUID="000134b5-01"

   Die UUID für `/dev/sda1` lautet `a1d1f2e0-b0ee-4be2-83d5-78a98c585827`.

3. Bearbeiten Sie `/etc/default/grub` und passen Sie den Parameter resume an. Ersetzen Sie `/dev/sda1` durch `UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827`. Das Ergebnis sieht folgendermaßen aus:

       GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827 splash=silent quiet showopts"

4. Aktualisieren Sie die Konfiguration des Grub-Bootmanagers:

       > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Wenn das System den Ruhezustand nicht verwendet, können Sie den Parameter resume einfach entfernen und die Boot-Konfiguration aktualisieren.

# 4 Offline-Upgrade #

In diesem Kapitel finden Sie Anweisungen zum Upgraden einer vorhandenen SUSE Linux Enterprise-Installation mithilfe von YaST, das von einem Installationsmedium gebootet wird. Das YaST-Installationsprogramm kann beispielsweise von einer DVD oder über das Netzwerk bzw. auch von der Festplatte, auf der sich das System befindet, gestartet werden. In diesem Sinne bezieht sich „Offline-Upgrade“ nicht allein auf den Status der Netzwerkverbindung, sondern auch darauf, dass das reguläre Betriebssystem bzw. seine Services offline sind.

## 4.1 Konzeptübersicht #

Vor dem Upgrade des Systems lesen Sie bitte zunächst Kapitel 3, Vorbereiten des Upgrades.

Zum Upgraden des Systems booten Sie von einer Installationsquelle, ebenso wie bei einer Neuinstallation. Im Bootbildschirm wählen Sie dabei jedoch Upgrade (statt Installation). Das Upgrade kann wie folgt gestartet werden:

- Wechseldatenträger. Dies sind Medien wie CDs, DVDs oder USB-Massenspeichergeräte. Weitere Informationen finden Sie in Abschnitt 4.2, „Starten des Upgrades über ein Installationsmedium“.

- Netzwerkressource. Sie können wahlweise vom lokalen Medium booten und dann den entsprechenden Netzwerkinstallationstyp auswählen oder über PXE booten. Weitere Informationen finden Sie in Abschnitt 4.3, „Starten des Upgrades über eine Netzwerkquelle“.

## 4.2 Starten des Upgrades über ein Installationsmedium #

Im nachfolgenden Verfahren wird das Booten von DVD beschrieben. Sie können jedoch auch ein anderes lokales Installationsmedium verwenden, z. B. ein ISO-Image auf einem USB-Massenspeichergerät. Das Medium und die Bootmethode sind abhängig von der Systemarchitektur und von der Ausstattung des Systems (herkömmliches BIOS oder UEFI).

Vorgehen 4.1: Manuelles Upgraden auf SUSE Linux Enterprise Desktop 15 SP7 #

1. Wählen Sie ein Bootmedium aus und bereiten Sie es vor, siehe Book “Installationshandbuch”.

2. Legen Sie die Unified Installer-DVD für SUSE Linux Enterprise Desktop 15 SP7 ein und booten Sie Ihren Rechner. Ein Begrüßungsbildschirm wird geöffnet, gefolgt vom Bootbildschirm.

3. (Optional) Fügen Sie die Boot-Option `media_upgrade=1` hinzu, um zu erzwingen, dass das Installationsprogramm nur Pakete von der DVD installiert und nicht von Netzwerkressourcen.

4. Starten Sie das System und wählen Sie im Bootmenü die Option Upgrade.

5. Fahren Sie gemäß Abschnitt 4.4, „Upgraden von SUSE Linux Enterprise“ mit der Installation fort.

## 4.3 Starten des Upgrades über eine Netzwerkquelle #

Zum Upgraden über eine Netzwerkinstallationsquelle müssen die folgenden Anforderungen erfüllt sein:

Anforderungen für das Upgraden von einer Netzwerkinstallationsquelle #

Netzwerkinstallationsquelle

  Eine Netzwerkinstallationsquelle ist gemäß Book “Installationshandbuch”, Chapter 13 “Einrichten einer Netzwerkinstallationsquelle” eingerichtet.

Netzwerkverbindung und Netzwerkdienste

  Sowohl der Installationsserver als auch der Zielcomputer müssen eine funktionsfähige Netzwerkverbindung haben. Erforderliche Netzwerkdienste:

  - Domänennamen-Service

  - DHCP (nur beim Booten über PXE; IP-Adresse kann manuell bei der Einrichtung festgelegt werden)

  - OpenSLP (optional)

Bootmedium

  Eine bootfähige SUSE Linux Enterprise-DVD, ein ISO-Image oder eine funktionsfähige PXE-Einrichtung. Weitere Innovationen zum Booten über PXE finden Sie in Book “Installationshandbuch”, Chapter 14 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 14.4 “Vorbereiten des Zielsystems für PXE-Boot”. Detaillierte Informationen zum Starten des Upgrades von einem Remote-Server finden Sie in Book “Installationshandbuch”, Chapter 8 “Ferninstallation”.

### 4.3.1 Manuelles Upgraden von einer Netzwerkinstallationsquelle – Booten von DVD #

In diesem Verfahren wird das Booten von DVD als Beispiel beschrieben. Sie können jedoch auch ein anderes lokales Installationsmedium verwenden, z. B. ein ISO-Image auf einem USB-Massenspeichergerät. Das Verfahren zum Auswählen der Bootmethode und zum Starten des Systems vom Medium hängt von der Systemarchitektur und davon ab, ob der Computer mit einem herkömmlichen BIOS oder mit UEFI ausgestattet ist. Weitere Informationen finden Sie unter den nachfolgenden Links.

1. Legen Sie die Unified Installer-DVD für SUSE Linux Enterprise Desktop 15 SP7 ein und booten Sie Ihren Rechner. Ein Begrüßungsbildschirm wird geöffnet, gefolgt vom Bootbildschirm.

2. Wählen Sie die gewünschte Netzwerkinstallationsquelle aus (FTP, HTTP, NFS, SMB oder SLP). Diese Auswahl erhalten Sie in der Regel mit F4. Falls der Computer mit UEFI statt mit einem herkömmlichen BIOS ausgestattet ist, müssen Sie ggf. die Bootparameter manuell anpassen. Weitere Informationen hierzu finden Sie in Book “Installationshandbuch”, Chapter 4 “Boot-Parameter” und in Book “Installationshandbuch”, Chapter 5 “Installationsschritte”.

3. Fahren Sie gemäß Abschnitt 4.4, „Upgraden von SUSE Linux Enterprise“ mit der Installation fort.

### 4.3.2 Manuelles Upgraden von einer Netzwerkinstallationsquelle – Booten über PXE #

So führen Sie das Upgrade von einer Netzwerkinstallationsquelle mit dem PXE-Boot aus:

1. Passen Sie das Setup Ihres DHCP-Servers an, damit die für den PXE-Boot erforderlichen Adressinformationen angegeben werden. Weitere Informationen finden Sie in Book “Installationshandbuch”, Chapter 14 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 14.1.1 “Dynamische Adressenzuweisung”.

2. Richten Sie einen TFTP-Server ein, auf dem das Boot-Image für das Booten über PXE abgelegt wird. Verwenden Sie dazu die Installations-DVD für SUSE Linux Enterprise Desktop 15 SP7 oder befolgen Sie die Anweisungen im Book “Installationshandbuch”, Chapter 14 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 14.2 “Einrichten eines TFTP-Servers”.

3. Bereiten Sie den PXE-Boot und Wake-on-LAN auf dem Zielcomputer vor.

4. Starten Sie den Boot des Zielsystems und verwenden Sie VNC, um sich entfernt mit der auf diesem Computer ausgeführten Installationsroutine zu verbinden. Weitere Informationen finden Sie in Book “Installationshandbuch”, Chapter 8 “Ferninstallation”, Section 8.3 “Überwachen der Installation über VNC”.

5. Fahren Sie gemäß Abschnitt 4.4, „Upgraden von SUSE Linux Enterprise“ mit der Installation fort.

## 4.4 Upgraden von SUSE Linux Enterprise #

Vor dem Upgrade des Systems beachten Sie Kapitel 3, Vorbereiten des Upgrades Gehen Sie folgendermaßen vor, um eine automatische Migration auszuführen:

Anmerkung: SUSE Customer Center und Internetverbindung

Wenn das System, das aufgerüstet werden soll, im SUSE Customer Center registriert ist, muss für die folgende Vorgehensweise eine Internetverbindung bestehen.

1. Nach dem Booten (von einem Installationsmedium oder über das Netzwerk) wählen Sie im Bootbildschirm die Option Upgrade.

   Warnung: Möglicher Datenverlust durch falsche Auswahl

   Achten Sie darauf, zu diesem Zeitpunkt Upgrade auszuwählen. Falls Sie versehentlich Installation auswählen, wird Ihre Datenpartition mit einer Neuinstallation überschrieben.

   YaST startet das Installationssystem.

2. Wählen Sie in Begrüßungsbildschirm die Optionen Sprache und Tastatur. Fahren Sie mit Weiter fort.

   YaST sucht auf den Partitionen nach bereits installierten SUSE Linux Enterprise-Systemen.

3. Wählen Sie im Bildschirm Zum Upgraden auswählen die Partition zum Upgraden aus und klicken Sie auf Weiter.

4. YaST hängt die ausgewählte Partition ein und zeigt die Lizenzvereinbarung für das upgegradete Produkt an. Akzeptieren Sie die Lizenz, damit Sie den Vorgang fortsetzen können.

5. Passen Sie am Bildschirm Zuvor verwendete Repositorys den Status der Repositorys an. Standardmäßig werden alle Repositorys entfernt. Wenn Sie keine benutzerdefinierten Repositorys hinzugefügt haben, dürfen Sie die Einstellungen nicht ändern. Die Upgrade-Pakete werden von DVD installiert. Sie können optional im nächsten Schritt die standardmäßigen Online-Repositorys aktivieren.

   Bei benutzerdefinierten Repositorys haben Sie zwei Wahlmöglichkeiten:

   - Belassen Sie das Repository im Status „Entfernt“. Software, die von diesem Repository installiert wurde, wird beim Upgrade entfernt. Verwenden Sie diese Methode, wenn keine Version des Repositorys verfügbar ist, die der neuen Version entspricht.

   - Aktualisieren und aktivieren Sie das Repository, falls es der neuen Version entspricht. Ändern Sie deren URL durch Klicken auf das Repository in der Liste. Klicken Sie dann auf Ändern. Aktivieren Sie das Repository mit Status wechseln, bis der Status auf Aktivieren festgelegt ist.

   Behalten Sie keine Repositorys der vorigen Version bei, da das System dann möglicherweise instabil wird oder gar nicht mehr funktioniert. Klicken Sie danach zum Fortfahren auf Weiter.

6. Der nächste Schritt ist davon abhängig, ob das aufgerüstete System im SUSE Customer Center registriert wurde.

   1. Wenn das System nicht im SUSE Customer Center registriert ist, zeigt YaST eine Popup-Meldung an und schlägt ein zweites Installationsmedium vor, das Image SLE-15-SP7-Full-ARCH-GM-media1.iso.

      Sollte dieses Medium nicht zur Verfügung stehen, ist ein Upgrade des Systems ohne Registrierung nicht möglich.

   2. Wenn das System im SUSE Customer Center registriert ist, zeigt YaST die möglichen Migrationsziele und eine Zusammenfassung an.

      Wählen Sie ein Migrationsziel in der Liste aus und setzen Sie den Vorgang mit Weiter fort.

7. Im nächsten Dialogfeld können Sie optional ein zusätzliches Installationsmedium hinzufügen. Wenn Sie zusätzliche Installationsmedien besitzen, aktivieren Sie die Option Ich möchte ein zusätzliches Add-on-Produkt installieren und geben Sie den Medientyp an.

8. Prüfen Sie die Installationseinstellungen für das Upgrade.

9. Wenn die Einstellungen Ihren Anforderungen entsprechen, starten Sie den Installations- und Löschvorgang mit Aktualisieren.

   Tipp: Upgrade-Fehler auf SMT-Clients

   Handelt es sich bei dem Rechner, der upgegradet werden soll, um einen SMT-Client und das Upgrade wird nicht ausgeführt, schlagen Sie das Verfahren in Prozedur 3.1, „Aufheben einer Registrierung von SUSE Linux Enterprise Client bei einem SMT-Server“ nach und starten Sie den Upgradevorgang dann neu.

10. Führen Sie nach einem erfolgreichen Upgrade die Schritte nach dem Upgrade aus, die in Kapitel 6, Das Upgrade abschließen beschrieben sind.

## 4.5 Upgrade mit SUSE Multi-Linux Manager #

SUSE Multi-Linux Manager ist eine Serverlösung für die Bereitstellung von Aktualisierungen, Patches und Sicherheitsreparaturen für SUSE Linux Enterprise-Clients. Hier finden Sie eine Reihe von Werkzeugen und eine webgestützte Bedienoberfläche für Verwaltungsaufgaben. Weitere Informationen zu SUSE Multi-Linux Manager finden Sie unter https://www.suse.com/products/multi-linux-manager/.

Sie können ein Upgrade des Systems mit SUSE Multi-Linux Manager durchführen. Die AutoYaST-Technologie ermöglicht Upgrades von einer Hauptversion zur nächsten.

Wenn Ihr Rechner mit SUSE Multi-Linux Manager verwaltet wird, aktualisieren Sie das Programm entsprechend der Beschreibung in der Dokumentation zu SUSE Multi-Linux Manager. Das Verfahren zur Client Migration ist in SUSE Multi-Linux Manager Upgrade Guide beschrieben, das unter https://documentation.suse.com/multi-linux-manager/ verfügbar ist.

## 4.6 Aktualisieren des Registrierungsstatus nach einem Rollback #

Bei einem Service Pack-Upgrade muss die Konfiguration auf dem Registrierungsserver geändert werden, um den Zugriff auf die neuen Repositorys zu ermöglichen. Wenn ein Upgradevorgang unterbrochen oder (durch Wiederherstellung auf Basis einer Sicherung oder eines Snapshots) rückgängig gemacht wird, stimmen die Informationen auf dem Registrierungsserver nicht mehr mit dem Status des Systems überein. Dies kann dazu führen, dass Sie nicht auf die Aktualisierungs-Repositorys zugreifen können oder die falschen Repositorys auf dem Client verwendet werden.

Wenn über Snapper ein Rollback erfolgt, benachrichtigt das System den Registrierungsserver, um sicherzustellen, dass während des Bootvorgangs der Zugriff auf die richtigen Repositorys eingerichtet wird. Wenn das System mit einer anderen Methode wiederhergestellt wurde oder wenn bei der Kommunikation mit dem Registrierungsserver ein Fehler auftritt, lösen Sie das Rollback auf dem Client manuell aus. Ein Rollback muss beispielsweise manuell ausgelöst werden, wenn der Server aufgrund von Netzwerkproblemen nicht erreichbar war. Mit dem folgenden Befehl führen Sie ein Rollback aus:

    > sudo snapper rollback

Es wird empfohlen, grundsätzlich zu prüfen, ob die richtigen Repositorys auf dem System eingerichtet wurden. Dies gilt insbesondere nach der Aktualisierung des Service mit:

    > sudo zypper ref -s

Diese Funktionalität ist im Paket rollback-helper verfügbar.

## 4.7 Registrieren des Systems #

Falls das System vor dem Upgrade noch nicht registriert war, können Sie das System jederzeit mit dem Modul Produktregistrierung in YaST registrieren.

Die Registrierung der Systeme bietet die folgenden Vorteile:

- Recht für Support

- Bereitstellung von Sicherheitsaktualisierungen und Fehlerbehebungen

- Zugang zum SUSE Customer Center

1. Starten Sie YaST und wählen Sie Software › Produktregistrierung. Das Dialogfeld Registrierung wird geöffnet.

2. Geben Sie die E-Mail-Adresse für das SUSE-Konto ein, mit dem Sie oder Ihr Unternehmen die Abonnements verwalten. Falls Sie noch kein SUSE-Konto besitzen, wechseln Sie zur SUSE Customer Center-Startseite (https://scc.suse.com/), und erstellen Sie dort ein Konto.

3. Geben Sie den Registrierungscode ein, den Sie zusammen mit Ihrem Exemplar von SUSE Linux Enterprise Desktop erhalten haben.

4. Wenn ein oder mehrere lokale Registrierungsserver in Ihrem Netzwerk verfügbar sind, können Sie einen Server aus einer Liste auswählen.

5. Starten Sie die Registrierung mit Weiter.

   Nach erfolgter Registrierung zeigt YaST eine Liste der verfügbaren Erweiterungen, Add-ons und Module für Ihr System an. Zum Auswählen und Installieren eines Elements fahren Sie mit Book “Installationshandbuch”, Chapter 6 “Registrieren von SUSE Linux Enterprise und Verwalten von Modulen/Erweiterungen”, Section 6.3 “Verwalten von Modulen und Erweiterungen in einem laufenden System” fort.

# 5 Online-Upgrade #

Für das Upgrade eines laufenden Systems auf ein neues Service Pack bietet SUSE ein intuitives grafisches Werkzeug und ein Befehlszeilenwerkzeug. Diese Funktionen unterstützen das „Rollback“ von Service Packs und vieles mehr. Dieses Kapitel beschreibt Schritt für Schritt, wie Sie Service Pack-Upgrades mit diesen Werkzeugen durchführen.

## 5.1 Konzeptübersicht #

SUSE veröffentlicht in regelmäßigen Abständen neue Service Packs für die SUSE Linux Enterprise-Produktfamilie. Um den Kunden die Migration auf ein neues Service Pack zu erleichtern und die Ausfallzeiten so kurz wie möglich zu halten, unterstützt SUSE eine Online-Migration bei laufendem System.

Ab SLE 12 werden anstelle von YaST-Wagon die YaST-Migration (GUI) und die Zypper-Migration (Befehlszeile) verwendet. Das hat folgende Vorteile:

- Das System befindet sich bis zur Aktualisierung des ersten RPM stets in einem definierten Status.

- Der Vorgang kann bis zur Aktualisierung des ersten RPM jederzeit abgebrochen werden.

- Unkomplizierte Wiederherstellung bei einem Fehler.

- Es ist möglich, anhand von Systemwerkzeugen ein „Rollback“ durchzuführen, was eine Sicherung und Wiederherstellung überflüssig macht.

- Verwendung aller aktiven Repositorys.

- Möglichkeit zum Überspringen eines Service Packs

Warnung: Keine Unterstützung der Online-Migration für Hauptversionen

Die Online-Migration wird ausschließlich bei der Migration auf ein anderes Service Pack unterstützt. Beim Upgraden auf neue Hauptversionen wird die Online-Migration nicht unterstützt. Weitere Informationen finden Sie in Kapitel 2, Upgrade-Pfade und -Methoden.

Upgraden Sie per Offline-Migration auf eine neue Hauptversion. Weitere Informationen finden Sie in Kapitel 4, Offline-Upgrade.

Wichtig: Upgrade von SUSE Multi-Linux Manager-Clients

Ein SUSE Multi-Linux Manager-Client kann weder per YaST-Online-Migration noch per `zypper migration` aufgerüstet werden. Verwenden Sie stattdessen das Verfahren zur Client Migration. Eine Beschreibung hierzu finden Sie in SUSE Multi-Linux Manager Upgrade Guide.

## 5.2 Workflow der Service Pack-Migration #

Eine Service Pack-Migration kann mit YaST, `zypper` oder AutoYAST ausgeführt werden.

Vor dem Start einer Service Pack-Migration muss das System beim SUSE Customer Center oder bei einem lokalen RMT-Server registriert werden. Auch SUSE Multi-Linux Manager kann verwendet werden.

Unabhängig von der Methode besteht eine Service Pack-Migration jedoch immer aus den folgenden Schritten:

1. Suchen von möglichen Migrationszielen auf den registrierten Systemen

2. Auswahl eines Migrationsziels

3. Anfordern und Aktivieren neuer Repositorys

4. Führen Sie die Migration aus.

Die Liste der Migrationsziele ist abhängig von den installierten und registrierten Produkten. Falls Sie eine Erweiterung installiert haben, für die das neue Service Pack noch nicht zur Verfügung steht, wird Ihnen unter Umständen gar kein Migrationsziel angeboten.

Die Liste der Migrationsziele, die für Ihren Host verfügbar sind, wird immer aus dem SUSE Customer Center abgerufen und hängt von den installierten Produkten oder Erweiterungen ab.

## 5.3 Abbrechen einer Service Pack-Migration #

Während des Migrationsvorgangs kann eine Service Pack-Migration nur in ganz bestimmten Phasen abgebrochen werden:

1. Bis zum Beginn des Paketupgrades erfolgen auf dem System nur minimale Änderungen, beispielsweise Änderungen an Services und Repositorys. Stellen Sie `/etc/zypp/repos.d/*` wieder her, um zum vorherigen Zustand zurückzukehren.

2. Nach Beginn des Paketupgrades können Sie mithilfe eines Snapper-Snapshots zum vorherigen Zustand zurückkehren (siehe Book “Verwaltungshandbuch”, Chapter 10 “Systemwiederherstellung und Snapshot-Verwaltung mit Snapper”).

3. Nach der Auswahl des Migrationsziels ändert das SUSE Customer Center die Repository-Daten. Wenn Sie diesen Zustand manuell zurücksetzen möchten, verwenden Sie `SUSEConnect` `--rollback`.

## 5.4 Upgraden mit dem Werkzeug für die Online-Migration (YaST) #

Für eine Service Pack-Migration mit YaST verwenden Sie das Tool für die Online-Migration. YaST installiert standardmäßig keine Pakete aus Repositorys von Drittanbietern. Wurde ein Paket aus einem Repository eines Drittanbieters installiert, verhindert YaST, dass das Paket durch das gleiche Paket aus SUSE ersetzt wird.

Anmerkung: Reduzieren des Installationsumfangs

Bei der Service Pack-Migration installiert YaST alle empfohlenen Pakete. Vor allem bei benutzerdefinierten Minimalinstallationen kann dies den Installationsumfang auf dem System beträchtlich erhöhen.

Möchten Sie dieses Standardverhalten ändern und nur erforderliche Pakete erlauben, passen Sie die Option `solver.onlyRequires` in`/etc/zypp/zypp.conf` an.

    solver.onlyRequires = true

Bearbeiten Sie zudem die Datei `/etc/zypp/zypper.conf` und ändern Sie dort die Option `installRecommends`.

    installRecommends=false

Dadurch ändert sich das Verhalten sämtlicher Paketvorgänge, z. B. Installationen von Patches oder neuen Paketen. Mit dem Parameter `--no-recommends` können Sie das Verhalten von Zypper für einen einzelnen Aufruf ändern.

Gehen Sie wie folgt vor, um die Service Pack-Migration zu starten:

1. Deaktivieren Sie alle nicht verwendeten Erweiterungen des Registrierungsservers, damit künftig keine Abhängigkeitskonflikte auftreten. Falls Sie eine Erweiterung übersehen, erkennt YaST später die nicht verwendeten Erweiterungs-Repositorys, die dann automatisch deaktiviert werden.

2. Wenn Sie bei einer GNOME-Sitzung auf dem zu aktualisierenden Computer angemeldet sind, wechseln Sie zu einer Textkonsole. Die Aktualisierung aus einer GNOME-Sitzung heraus wird nicht empfohlen. Dies gilt nicht, wenn Sie über einen Remote-Computer angemeldet sind (es sei denn, Sie führen eine VNC-Sitzung mit GNOME aus).

3. Führen Sie die YaST-Online-Aktualisierung aus, um die neuesten Paketaktualisierungen für Ihr System zu erhalten.

4. Installieren Sie das Paket yast2-migration und seine abhängigen Komponenten (in YaST unter Software › Software installieren oder löschen).

5. Starten Sie YaST neu, damit das neu installierte Modul im Kontrollzentrum angezeigt wird.

6. Wählen Sie in YaST die Option Online-Migration. (Je nach der upzugradenden Version von SUSE Linux Enterprise Desktop befindet sich dieses Modul unter System oder Software.) YaST zeigt die möglichen Migrationsziele und eine Zusammenfassung an. Falls für Ihr System mehrere Migrationsziele verfügbar sind, wählen Sie eines davon in der Liste aus.

7. Wählen Sie ein Migrationsziel in der Liste aus und setzen Sie den Vorgang mit Weiter fort.

8. Falls das Migrationstool Aktualisierungs-Repositorys anbietet, sollten Sie mit Ja fortfahren.

9. Falls das Tool für die Online-Migration alte Repositorys von DVD oder einem lokalen Server findet, empfiehlt es sich dringend, diese zu deaktivieren. Veraltete Repositorys beziehen sich auf ein früheres Service Pack. Alte Repositorys vom SUSE Customer Center oder aus RMT werden automatisch entfernt.

   Wenn der Registrierungsserver keine Migrationen für ein Modul oder eine Erweiterung anbietet, bleibt seine Repository-Konfiguration unverändert. Dies geschieht in der Regel bei Repositorys von Drittanbietern wie dem NVIDIA Compute Module, die nicht an eine Produktversion oder ein Service Pack gebunden sind. Falls erforderlich, können Sie die Repository-Konfiguration nach der Migration manuell überprüfen.

10. Prüfen Sie die Zusammenfassung und klicken Sie dann auf Weiter, um mit der Migration fortzufahren. Bestätigen Sie die Migration mit Aktualisierung starten.

11. Starten Sie Ihr System nach einer erfolgreichen Migration neu.

## 5.5 Upgraden mit zypper #

Für eine Service Pack-Migration mit Zypper verwenden Sie das Kommandozeilenwerkzeug `zypper` `migration` aus dem Paket zypper-migration-plugin.

Anmerkung: Reduzieren des Installationsumfangs

Bei der Service Pack-Migration installiert YaST alle empfohlenen Pakete. Vor allem bei benutzerdefinierten Minimalinstallationen kann dies den Installationsumfang auf dem System beträchtlich erhöhen.

Möchten Sie dieses Standardverhalten ändern und nur erforderliche Pakete erlauben, passen Sie die Option `solver.onlyRequires` in`/etc/zypp/zypp.conf` an.

    solver.onlyRequires = true

Bearbeiten Sie zudem die Datei `/etc/zypp/zypper.conf` und ändern Sie dort die Option `installRecommends`.

    installRecommends=false

Dadurch ändert sich das Verhalten sämtlicher Paketvorgänge, z. B. Installationen von Patches oder neuen Paketen. Mit dem Parameter `--no-recommends` können Sie das Verhalten von Zypper für einen einzelnen Aufruf ändern.

Gehen Sie wie folgt vor, um die Service Pack-Migration zu starten:

1. Wenn Sie bei einer GNOME-Sitzung auf dem zu aktualisierenden Computer angemeldet sind, wechseln Sie zu einer Textkonsole. Die Aktualisierung aus einer GNOME-Sitzung heraus wird nicht empfohlen. Dies gilt nicht, wenn Sie über einen Remote-Computer angemeldet sind (es sei denn, Sie führen eine VNC-Sitzung mit GNOME aus).

2. Falls noch nicht erfolgt, registrieren Sie Ihren SUSE Linux Enterprise-Rechner:

       > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE

3. Migration starten:

       > sudo zypper migration

   Beachten Sie folgende Hinweise zum Migrationsvorgang:

   - Falls für Ihr System mehrere Migrationsziele verfügbar sind, können Sie in Zypper einen SP in der Liste auswählen. Dies entspricht dem Überspringen eines oder mehrerer SPs. Denken Sie daran, dass die Online-Migration für Basisprodukte (SLES, SLED) nur zwischen den SPs einer Hauptversion verfügbar ist.

   - Zypper verwendet standardmäßig die Option `--no-allow-vendor-change`, die an `zypper` `dup` weitergeleitet wird. Wurde ein Paket aus einem Repository eines Drittanbieters installiert, verhindert diese Option, dass das Paket durch das gleiche Paket aus SUSE ersetzt wird.

   - Falls Zypper alte Repositorys von DVD oder einem lokalen Server findet, empfiehlt es sich dringend, diese zu deaktivieren. Alte SUSE Customer Center- oder RMT-Repository werden automatisch entfernt.

4. Prüfen Sie alle Änderungen, insbesondere die Pakete, die entfernt werden. Geben Sie `y` ein, um fortzufahren (die Anzahl der Pakete, die aktualisiert werden können, ist von System zu System unterschiedlich):

       266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch.
       Overall download size: 285.1 MiB. Already cached: 0 B  After the operation, additional 139.8 MiB will be used.
       Continue? [y/n/? shows all options] (y):

   Verwenden Sie zum Blättern in Ihrer Shell die Tasten Umschalttaste–Bild ↑ oder Umschalttaste–Bild ↓.

5. Starten Sie Ihr System nach einer erfolgreichen Migration neu.

## 5.6 Upgraden mit einfachem Zypper #

Falls Ihr System nicht registriert ist, weil Sie keinen Zugriff auf das Internet oder einen Registrierungsserver haben, ist die Migration zu einem neuen Service Pack mit YaST Migration oder `zypper migration` nicht möglich. In diesem Fall können Sie mit Zypper und einigen manuellen Interaktionen trotzdem zu einem neuen Service Pack migrieren.

Wichtig: Nur für nicht registrierte Systeme

Dieser Migrationspfad zu einem neuen Service Pack wird nur für nicht registrierte Systeme unterstützt, die keinen Zugriff auf das Internet oder einen Registrierungsserver haben. Dies ist möglicherweise bei Rechnern in einem speziell geschützten Netzwerk der Fall. Ein registriertes System können Sie mit YaST oder Zypper migrieren.

Wichtig: Installationsquellen

Dieser Migrationspfad setzt voraus, dass das System, das Sie migrieren möchten, Zugriff auf die Installationsquellen hat. Dies kann beispielsweise durch die Einrichtung eines RMT-Servers oder eines SLP-Servers geschehen.

Das System muss zudem Zugriff auf ein aktuelles Aktualisierungs-Repository für die installierte Produktversion haben.

1. Wenn Sie bei einer Grafiksitzung auf dem zu migrierenden Rechner angemeldet sind, müssen Sie sich von dieser Sitzung abmelden und zu einer Textkonsole wechseln. Von der Aktualisierung aus einer Grafiksitzung heraus wird abgeraten. Dies gilt nicht, wenn Sie über einen Remote-Computer angemeldet sind (es sei denn, Sie führen eine VNC-Sitzung mit X aus).

2. Aktualisieren Sie die Paketverwaltungstools:

       > sudo zypper patch --updatestack-only

3. Stellen Sie sicher, dass alle Repository-Konfigurationsdateien für SUSE Linux Enterprise Desktop in `/etc/zypp/repos.d/` die Variable `$releasever` verwenden:

       > grep baseurl /etc/zypp/repos.d/*.repo
       /etc/zypp/repos.d/rmt.repo:baseurl=https://rmt.example.com/repo/SUSE/Products/SLE-15-SP5-Product-SLES/x86_64/product/
       /etc/zypp/repos.d/updates.repo:baseurl=https://updates.suse.com/SUSE/Products/SLE-Product-SLES/$releasever/x86_64/product[...]

   In diesem Beispiel wird in der Datei `updates.repo` die Variable verwendet, während in `rmt.repo` die Versionszeichenfolge `15-SP5` hartcodiert ist. Um alle Vorkommen von `15-SP5` in allen Repository-Konfigurationsdateien durch `$releasever` zu ersetzen, führen Sie Folgendes aus:

       > sudo sed -i 's/15-SP5/${releasever}/g' /etc/zypp/repos.d/*.repo

   Wiederholen Sie diesen Befehl ggf. mit anderen Versionszeichenfolgen, um sicherzustellen, dass alle Repository-Konfigurationsdateien aktualisiert werden.

4. Prüfen Sie, ob alle Repositorys korrekt konfiguriert sind:

       > sudo zypper --releasever=15-SP7 repos -u

   Die URLs der Repositorys sollten nun die Angabe `15-SP7` enthalten. Beachten Sie, dass bei Drittanbieter-Repositorys möglicherweise keine Version angegeben ist. Es wird davon ausgegangen, dass sie bei allen Versionen von SUSE Linux Enterprise Desktop funktionieren.

5. Schalten Sie alle Repositorys auf 15 SP7 um:

       > sudo zypper --releasever=15-SP7 refresh -f -s

   Falls ein Repository nicht aktualisiert werden kann, prüfen Sie nach, ob Sie die falsche URL eingegeben haben. Wenn das Problem nicht behoben werden kann, empfiehlt es sich, das fehlerhafte Repository zu deaktivieren.

6. Testen Sie die Migration:

       > sudo zypper --releasever=15-SP7 dup -D --no-allow-vendor-change --no-recommends

   Mit dem Parameter `-D` wird ein Probelauf durchgeführt, der die Migration simuliert, ohne das System tatsächlich zu ändern. Falls Probleme auftreten, sollten sie behoben werden, bevor Sie fortfahren.

   Die Option `-no-allow-vendor-change` verhindert, dass RPM-Pakete aus dem Basissystem durch Drittanbieter-Pakete ersetzt werden. Durch die Option `--no-recommends` wird sichergestellt, dass Pakete, die während der Erstinstallation abgewählt wurden, nicht erneut hinzugefügt werden.

7. Führen Sie das vollständige Distributionsupgrade aus:

       > sudo zypper --releasever=15-SP7 dup --no-allow-vendor-change --no-recommends

   Mit dem obigen Befehl lädt Zypper alle Pakete vorab herunter. Dies ist für den Fall, dass Ihre Internetverbindung ausfällt, zuverlässiger. Führen Sie Folgendes aus, um Pakete in Heaps herunterzuladen und zu installieren:

       > sudo zypper zypper --releasever=15-SP7 dup --no-allow-vendor-change --no-recommends --download-in-heaps

   Nach Abschluss des Distributionsupgrades setzt SUSE Linux Enterprise Desktop die Variable `$releasever` auf die neue Version. Sie müssen sie dann nicht mehr mit der Option `--releasever` angeben.

8. Starten Sie Ihr System nach der erfolgreichen Migration neu.

## 5.7 Rollback eines Service Packs #

Falls ein Service Pack nicht ordnungsgemäß ausgeführt wurde, unterstützt SUSE Linux Enterprise die Zurücksetzung des Systems auf den Zustand vor Beginn der Service Pack-Migration. Voraussetzung hierfür ist eine Btrfs-root-Partition mit aktivierten Snapshots (Standard seit SLES 12). Ausführliche Informationen finden Sie in Book “Verwaltungshandbuch”, Chapter 10 “Systemwiederherstellung und Snapshot-Verwaltung mit Snapper”.

1. Rufen Sie eine Liste sämtlicher Snapper-Snapshots ab:

       > sudo snapper list

   Suchen Sie in der Ausgabe nach dem Snapshot, der unmittelbar vor Beginn der Service Pack-Migration gestartet wurde. Die Spalte Beschreibung enthält eine Erläuterung und der Snapshot wird in der Spalte Benutzerdaten als `important` gekennzeichnet. Notieren Sie die Snapshot-Nummer in der Spalte Nr. und das entsprechende Datum in der Spalte Datum.

2. Booten Sie das System neu. Wählen Sie im Bootmenü die Option Bootloader von einem schreibgeschützten Snapshot starten und wählen Sie den Snapshot mit dem notierten Datum und der Nummer aus dem vorangegangenen Schritt aus. Ein zweites Bootmenü (das Bootmenü aus dem Snapshot) wird geladen. Wählen Sie den Eintrag aus, der mit SLES 15 SP7 beginnt, und booten Sie ihn.

3. Das System bootet im vorherigen Zustand, wobei die Systempartition schreibgeschützt eingehängt ist. Melden Sie sich als `root` an und prüfen Sie, ob Sie den richtigen Snapshot ausgewählt haben. Prüfen Sie außerdem, ob alle Vorgänge wie erwartet ablaufen. Beachten Sie, dass der Funktionsumfang ggf. eingeschränkt ist, da das root-Dateisystem schreibgeschützt eingehängt wurde.

   Falls Probleme auftreten oder Sie den falschen Snapshot gebootet haben, booten Sie das System neu und wählen Sie einen anderen Snapshot zum Booten aus. Bis zu diesem Zeitpunkt wurden noch keine permanenten Änderungen vorgenommen. Falls der richtige Snapshot ausgewählt wurde und dieser Snapshot einwandfrei arbeitet, lassen Sie die Änderungen mit dem folgenden Befehl dauerhaft in Kraft treten:

       > sudo snapper rollback

   Den Computer neu booten. Wählen Sie im Bootbildschirm den Standard-Booteintrag. Das neu eingesetzte System wird erneut gebootet.

4. Prüfen Sie, ob die Repository-Konfiguration ordnungsgemäß zurückgesetzt wurde. Prüfen Sie außerdem, ob alle Produkte fehlerfrei registriert wurden. Falls eine dieser Bedingungen nicht erfüllt ist, kann das System später eventuell nicht mehr aktualisiert werden oder das System wird mit den falschen Paket-Repositorys aktualisiert.

   Prüfen Sie vor Beginn dieses Verfahrens, ob das System auf das Internet zugreifen kann.

   1. Aktualisieren Sie die Dienste und Repositorys mit

          > sudo zypper ref -fs

   2. Erstellen Sie eine Liste der aktiven Repositorys mit

          > sudo zypper lr

      Prüfen Sie die Ausgabe dieses Befehls sorgfältig. Es sollten keine Dienste und Repositorys aufgelistet werden, die für die Aktualisierung eingefügt wurden. Bei einem Rollback von SLES 15 SP7 auf SLES15 GA muss die Liste beispielsweise die `SLES15-GA`-Repositorys enthalten, also nicht die `SLES15-SP7`-Repositorys.

      Falls falsche Repositorys aufgelistet werden, löschen Sie diese Repositorys und ersetzen Sie sie ggf. durch die richtigen Versionen für die Produkt- oder Service Pack-Version. Eine Liste der Repositorys für die unterstützten Migrationspfade finden Sie unter Abschnitt 1.3, „Abhängigkeiten und Lebenszyklen der Module“. (Beachten Sie, dass kein manuelles Eingreifen erforderlich sein sollte, da die Repositorys automatisch aktualisiert werden sollten. Als bewährte Vorgehensweise sollten sie jedoch überprüft und notwendige Korrekturen vorgenommen werden.)

   3. Prüfen Sie abschließend den Registrierungsstatus aller installierten Produkte mit

          > sudo SUSEConnect --status

      Alle Produkte sollten als `Registered` aufgeführt werden. Ist dies nicht der Fall, reparieren Sie die Registrierung mit

          > sudo SUSEConnect --rollback

Damit haben Sie das System wieder auf den Zustand zurückgesetzt, der vor Beginn der Service Pack-Migration vorlag.

## 5.8 Upgrade mit SUSE Multi-Linux Manager #

SUSE Multi-Linux Manager ist eine Serverlösung für die Bereitstellung von Aktualisierungen, Patches und Sicherheitsreparaturen für SUSE Linux Enterprise-Clients. Hier finden Sie eine Reihe von Werkzeugen und eine webgestützte Bedienoberfläche für Verwaltungsaufgaben. Weitere Informationen zu SUSE Multi-Linux Manager finden Sie unter https://www.suse.com/products/multi-linux-manager/.

Bei der SP-Migration können Sie von einem bestimmten Service Pack (SP) auf ein anderes in derselben Hauptversion migrieren (z. B. von SLES 15 GA auf SLES 15 SP7).

Wenn Ihr Rechner mit SUSE Multi-Linux Manager verwaltet wird, aktualisieren Sie das Programm entsprechend der Beschreibung in der Dokumentation zu SUSE Multi-Linux Manager. Das Verfahren zur Client Migration ist in SUSE Multi-Linux Manager Upgrade Guide beschrieben, das unter https://documentation.suse.com/multi-linux-manager/ verfügbar ist.

# 6 Das Upgrade abschließen #

Nach dem Upgrade müssen Sie einige zusätzliche Aufgaben durchführen. Im folgenden Kapitel werden Sie durch diese Schritte geführt.

## 6.1 Prüfen auf alte Pakete #

Prüfen Sie mit `zypper packages` auf verwaiste und nicht benötigte Pakete.

Verwaiste Pakete sind in keinem der konfigurierten Repositorys mehr verfügbar. Sie können nicht mehr aktualisiert werden und werden nicht mehr unterstützt.

Eine Liste der verwaisten Pakete erhalten Sie durch Ausführen von:

    > zypper packages --orphaned

Nicht benötigte Pakete sind Abhängigkeiten von Paketen, die entweder explizit vom Benutzer oder implizit als Teil eines Schemas oder Produkts installiert wurden und die in der Zwischenzeit entfernt wurden. Sie werden in der Regel nicht mehr benötigt und sollten ebenfalls entfernt werden.

Eine Liste der nicht benötigten Pakete erhalten Sie durch Ausführen von:

    > zypper packages --unneeded

Tipp

Um nicht benötigte Pakete zu vermeiden, verwenden Sie `zypper rm` mit der Option `‑‑clean-deps` oder YaST mit Optionen › Beim Löschen von Paketen bereinigen.

Sie können beide Listen in einer kombinieren:

    > zypper packages --orphaned --unneeded

Ermitteln Sie anhand dieser Listen, welche Pakete noch benötigt werden und welche Pakete sicher entfernt werden können.

Warnung: Entfernen Sie keine Pakete, die Sie benötigen

Wenn Pakete umbenannt oder aus einem Schema oder Produkt entfernt werden, kann es sein, dass `zypper` sie nicht mehr als explizit installiert betrachtet und sie als nicht mehr benötigt markiert, obwohl sie für Ihre Installation immer noch wichtig sind.

Prüfen Sie sorgfältig die Liste der Pakete, die Sie entfernen.

Wenn Sie alle verwaisten und nicht mehr benötigten Pakete mit einem einzigen Befehl entfernen möchten, führen Sie folgendes Kommando aus:

    > sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5)

Schließen Sie ein einzelnes Paket oder Schema von der Deinstallation aus:

    > sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v PACKAGE_TO_EXCLUDE)

Schließen Sie mehrere in einer Textdatei definierte Pakete aus, getrennt durch einen Zeilenumbruch:

    > sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v -f /PACKAGES/TO/KEEP.txt)

## 6.2 Überprüfen der Konfigurationsdateien #

Suchen Sie nach `*.rpmnew`- und `*.rpmsave`-Dateien. Wenn ein Upgrade Änderungen an einer Standardkonfigurationsdatei enthält, die nach der Paketinstallation geändert wurde, wird einer dieser Dateitypen erstellt, anstatt die Datei zu überschreiben. Die Datei `*.rpmnew` enthält die neue Standardkonfiguration und lässt Ihre geänderte Datei unverändert. `*.rpmsave` ist eine Kopie der geänderten Konfiguration, die durch die neue Standarddatei ersetzt wurde.

Wenn Sie eine dieser Dateien finden, prüfen Sie deren Inhalt und führen Sie die gewünschten Änderungen zusammen. Sie müssen nicht das gesamte Dateisystem durchsuchen, sondern nur das Verzeichnis `/etc`. Verwenden Sie den folgenden Befehl:

    > find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

## 6.3 Das `Python 3`-Modul aktivieren #

SUSE Linux Enterprise Desktop 15 verwendet standardmäßig Python 3.6. Python 3.9 wurde in SLED 15 SP3 als neuere Alternative hinzugefügt. Diese Version wird ab SLED 15 SP4 nicht mehr unterstützt. Stattdessen sind aktuelle Python-Versionen mit wichtigen Updates und Sicherheitsupdates über das Modul `Python 3` verfügbar.

Wenn Sie Python 3.9 unter SUSE Linux Enterprise Desktop 15 SP installiert haben, aktivieren Sie das `Python 3`-Modul mit:

    > sudo SUSEConnect -p sle-module-python3/15.7/x86_64.

Alternativ können Sie zur Standard-Python-Version zurückkehren, indem Sie bei `zypper remove -u python39` entfernen.

## 6.4 XFS v4-Geräte neu formatieren #

SUSE Linux Enterprise Desktop unterstützt das „On-Disk-Format“ (v5) des XFS-Dateisystems. Die wesentlichen Vorteile dieses Formats sind automatische Prüfsummen aller XFS-Metadaten, die Unterstützung von Dateitypen und die Unterstützung einer größeren Anzahl von Zugriffssteuerungslisten für eine Datei.

Beachten Sie, dass dieses Format von SUSE Linux Enterprise-Kerneln älter als Version 3.12, von `xfsprogs` älter als Version 3.2.0 und von GRUB 2-Versionen veröffentlicht vor SUSE Linux Enterprise 12 nicht unterstützt wird.

Wichtig: V4 wird außer Kraft gesetzt

XFS setzt Dateisysteme mit dem V4-Format außer Kraft. Dieses Dateisystemformat wurde mit folgendem Befehl erstellt:

    > sudo mkfs.xfs -m crc=0 DEVICE

Das Format wurde in SLE 11 und älteren Versionen verwendet und erzeugt derzeit eine von`dmesg` ausgegebene Warnmeldung:

    Deprecated V4 format (crc=0) will not be supported after September 2030

Wenn Sie die obige Meldung in der Ausgabe des `dmesg`-Befehls sehen, sollten Sie für Ihr Dateisystem eine Aktualisierung auf das V5-Format vornehmen:

1. Sichern Sie Ihre Daten auf einem anderen Gerät.

2. Erstellen Sie das Dateisystem auf dem Gerät.

       > sudo mkfs.xfs -m crc=1 DEVICE

3. Stellen Sie die Daten aus der Sicherung auf dem aktualisierten Gerät wieder her.

# 7 Rückportierungen des Quellcodes #

SUSE verwendet häufig Rückportierungen, z. B. für die Migration aktueller Softwarereparaturen und -funktionen in veröffentlichte SUSE Linux Enterprise-Pakete. In diesem Kapitel wird erläutert, weshalb es irreführend sein kann, Versionsnummern zu vergleichen, um die Fähigkeiten und die Sicherheit von SUSE Linux Enterprise-Softwarepaketen zu beurteilen. Darüber hinaus wird in diesem Kapitel erläutert, wie SUSE die Systemsoftware sicher und aktuell hält und dabei die Kompatibilität für Ihre Anwendungssoftware beibehält, die Sie zusätzlich zu den SUSE Linux Enterprise-Produkten ausführen. Sie erfahren außerdem, wie Sie überprüfen können, welche öffentlichen Sicherheitsprobleme in Ihrer SUSE Linux Enterprise-Systemsoftware berücksichtigt wurden, und wie Sie den aktuellen Status Ihrer Software ermitteln.

## 7.1 Argumente für die Rückportierung #

Upstream-Entwickler befassen sich hauptsächlich damit, die Software weiterzuentwickeln. In vielen Fällen beheben sie Fehler, während sie gleichzeitig neue Funktionen einbauen, die noch nicht eingehend getestet wurden und daher ihrerseits neue Fehler verursachen.

Distributionsentwickler müssen daher zwischen Folgendem unterscheiden:

- Fehlerbehebungen mit begrenztem Risiko von Funktionsstörungen und

- Änderungen, die die bestehenden Funktionen stören.

In den meisten Fällen beachten Distributionsentwickler nicht alle Upstream-Änderungen, sobald ein Paket in eine veröffentlichte Distribution eingebunden ist. Häufig bleiben sie bei der Upstream-Version, die sie ursprünglich veröffentlicht hatten, und sie erstellen auf Patches auf der Grundlage der Upstream-Änderungen, mit denen dann Fehler behoben werden sollen. Dies wird als Rückportierung bezeichnet.

Im Allgemeinen stellen Distributionsentwickler nur in zwei Fällen eine neuere Software-Version bereit:

- wenn die Änderungen zwischen ihren Paketen und den Upstream-Versionen so groß geworden sind, dass eine Rückportierung nicht mehr praktikabel ist, oder

- für Software, die schon an sich rasch veraltet, beispielsweise Anti-Malware-Software.

Bei SUSE wird die Rückportierung umfassend genutzt, damit die verschiedenen Anforderungen an Unternehmenssoftware in ein gesundes Gleichgewicht gebracht werden können. Beispiele für die wichtigsten Punkte:

- Es sollen stabile Schnittstellen (APIs) erzielt werden, auf die die Software-Hersteller sich verlassen können, wenn sie Produkte für die gemeinsame Verwendung mit den Unternehmensprodukten von SUSE bauen.

- Die Pakete, die in den Unternehmensprodukten von SUSE zum Einsatz kommen, sollen die höchstmögliche Qualität aufweisen und gründlich getestet werden, und das nicht nur in sich selbst, sondern auch als Bestandteil des gesamten Unternehmensprodukts.

- Die Zertifizierungen der Unternehmensprodukte von SUSE durch andere Hersteller, z. B. Zertifizierungen für Oracle- oder SAP-Produkte, sollen aufrechterhalten werden.

- So können sich die SUSE-Entwickler voll und ganz auf die nächste Produktversion konzentrieren, müssen also nicht unzählige Versionen im Auge behalten.

- Es soll klar ersichtlich sein, was in einer bestimmten Unternehmensversion vorhanden ist, damit unser Kundendienst genaue und zeitnahe Informationen dazu bereitstellen kann.

## 7.2 Argumente gegen die Rückportierung #

Es gilt die allgemeine Richtlinie, dass keine neuen Upstream-Versionen eines Pakets in unsere Unternehmensprodukte eingeführt werden. Diese Regel ist allerdings nicht ohne Ausnahmen. Bei bestimmten Arten von Paketen, insbesondere bei Antiviren-Software, wiegen die Sicherheitsaspekte schwerer als die konservative Vorgehensweise, die mit Blick auf die Qualitätssicherung aus einzuhalten wäre. Für Pakete in dieser Klasse werden gelegentlich neuere Versionen in eine veröffentliche Version einer Unternehmensproduktlinie eingeführt.

Gelegentlich wird auch bei anderen Arten von Paketen entschieden, eine neue Version einzuführen, statt eine Rückportierung vorzunehmen. Dies ist dann der Fall, wenn eine Rückportierung wirtschaftlich nicht praktikabel ist oder wenn äußerst relevante technische Argumente für die Einführung der neueren Version sprechen.

## 7.3 Auswirkungen der Rückportierungen auf die Interpretation der Versionsnummern #

Aufgrund der verbreiteten Praxis der Rückportierungen ist es nicht möglich, aus einem einfachen Vergleich der Versionsnummern festzustellen, ob ein SUSE-Paket eine Korrektur für ein bestimmtes Problem enthält oder eine bestimmte Funktion in dieses Paket eingefügt wurde. Durch die Rückportierung gibt der Upstream-Teil der Versionsnummer eines SUSE-Pakets lediglich an, auf welcher Upstream-Version das SUSE-Paket basiert. Das Paket enthält unter Umständen Fehlerkorrekturen und Funktionen, die in der zugehörigen Upstream-Version fehlen, jedoch in das SUSE-Paket rückportiert wurden.

Diese eingeschränkte Aussagefähigkeit der Versionsnummern durch die Rückportierung macht sich insbesondere bei Sicherheitssuchwerkzeugen negativ bemerkbar. Einige Werkzeuge für die Suche nach Sicherheitslücken (oder bestimmte Tests in diesen Werkzeugen) beruhen ausschließlich auf den Versionsinformationen. Wenn Rückportierungen zum Einsatz kommen, liefern diese Tools und Tests daher häufig „falsch-positive“ Ergebnisse (eine Software wird irrtümlich als anfällig eingestuft). Achten Sie daher in allen Berichten von Sicherheits-Scan-Tools darauf, ob ein Eintrag auf der Grundlage einer Versionsnummer entstanden ist oder nach einem tatsächlichen Test auf Schwachstellen.

## 7.4 Prüfen auf behobene Fehler sowie auf Funktionen nach einer Rückportierung #

Informationen zu zurückportierten Fehlerbehebungen und Funktionen werden an mehreren Orten gespeichert:

- Changelog des Pakets:

      > rpm -q --changelog name-of-installed-package
      > rpm -qp --changelog packagefile.rpmpackagefile.rpm

  Die Ausgabe dokumentiert den Änderungsverlauf des Pakets in Kurzform.

- Das Changelog des Pakets kann beispielsweise Einträge wie `bsc#1234` („BugzillaSuse. Com“) enthalten, die sich auf Fehler im Bugzilla-Fehlerverfolgungssystem beziehen oder mit anderen Fehlerüberwachungssystemen verknüpft sind. Aus Vertraulichkeitsgründen sind nicht alle Informationen frei für alle Benutzer zugänglich.

- Ein Paket kann eine Datei `/usr/share/doc/PACKAGENAME /README.SUSE` umfassen, in der Sie allgemeine Informationen zum betreffenden SUSE-Paket finden.

- Das RPM-Quellpaket enthält die Patches, die während der regulären binären RPMs als separate Dateien angewendet werden können. Wenn Sie das Lesen des Quellcodes beherrschen, können Sie diese Dateien interpretieren. In Book “Verwaltungshandbuch”, Chapter 9 “Verwalten von Software mit Befehlszeilenwerkzeugen”, Section 9.1.3.5 “Installieren oder Herunterladen von Quellpaketen” finden Sie die Installationsquellen für die SUSE Linux Enterprise-Software. In Book “Verwaltungshandbuch”, Chapter 9 “Verwalten von Software mit Befehlszeilenwerkzeugen”, Section 9.2.5 “Installieren und Kompilieren von Quellpaketen” finden Sie Informationen zum Erstellen von Paketen unter SUSE Linux Enterprise. Weitere Informationen zu den Softwarepaket-Builds für SUSE Linux Enterprise finden Sie in Handbuch Maximum RPM.

- In den SUSE-Sicherheitsmitteilungen finden Sie Korrekturen zu Sicherheitsfehlern. Die Fehler werden häufig mit standardisierten Kennungen wie `CAN-2005-2495` bezeichnet, die im Rahmen des CVE-Projekts (Common Vulnerabilities and Exposures, häufige Sicherheitslücken und Gefährdungen) vergeben werden.

# A GNU licenses #

Versionsgeschichte: Upgradehandbuch

This appendix contains the GNU Free Documentation License version 1.2.

## GNU Free Documentation License #

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

##### 0. PREAMBLE #

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

##### 1. APPLICABILITY AND DEFINITIONS #

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

##### 2. VERBATIM COPYING #

You may copy and distribute the Document in any medium, either commercially or non-commercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

##### 3. COPYING IN QUANTITY #

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

##### 4. MODIFICATIONS #

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

4. Preserve all the copyright notices of the Document.

5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

8. Include an unaltered copy of this License.

9. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

11. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

13. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

14. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

15. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

##### 5. COMBINING DOCUMENTS #

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

##### 6. COLLECTIONS OF DOCUMENTS #

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

##### 7. AGGREGATION WITH INDEPENDENT WORKS #

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

##### 8. TRANSLATION #

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

##### 9. TERMINATION #

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

##### 10. FUTURE REVISIONS OF THIS LICENSE #

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

##### ADDENDUM: How to use this License for your documents #

    Copyright (c) YEAR YOUR NAME.
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.2
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled “GNU
    Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:

    with the Invariant Sections being LIST THEIR TITLES, with the
    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.