Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / SUSE Linux Enterprise Server-Dokumentation / Einführung zum Upgrade / Vorbereiten des Upgrades
Gilt für SUSE Linux Enterprise Server 15 SP5

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.

3.2 Lesen Sie die Versionshinweise

 

Eine Liste aller Änderungen, neuen Funktionen und bekannten Probleme finden Sie in den release notes. 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 hauptsächlich für die in /etc gespeicherten Dateien sowie für bestimmte 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
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       44G    4G   40G   9% /data

3.4.2 Ermitteln des freien Speicherplatzes auf Btrfs-root-Dateisystemen

 

In einem Btrfs-Dateisystem kann die Ausgabe von df irreführend sein, weil ein Btrfs-Dateisystem zusätzlich zum Speicherplatz, den die Rohdaten zuordnen, auch Speicherplatz für Metadaten zuordnet 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. Details zur Überprüfung des belegten und verfügbaren Speicherplatzes auf einem Btrfs-Dateisystem finden Sie im Section 1.2.2.3, “Checking for free space”. Weitere Informationen finden Sie unter 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:

  • Bei allen Dateisystemen (auch Btrfs) benötigen Sie ausreichend freien Speicherplatz, damit Sie große RPMs herunterladen und installieren können. 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
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
    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 Server-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 Migration der PostgreSQL-Datenbank

 

Im Lieferumfang von SUSE Linux Enterprise Server 15 SP5 sind die PostgreSQL-Datenbankversionen 13 und 14 enthalten. Version 14 ist die Standardversion. Version 13 wird weiterhin über das Legacy-Modul für Upgrades von früheren Versionen von SUSE Linux Enterprise Server bereitgestellt.

Aufgrund der erforderlichen Migrationsschritte für die Datenbank ist kein automatischer Upgradevorgang verfügbar. Die Umstellung auf die neue Version muss daher manuell erfolgen.

Der Migrationsvorgang wird mit dem Kommando pg_upgrade ausgeführt. Dieses Kommando ist eine alternative Methode zur bewährten Methode eines Dumps und Neuladens. Im Vergleich zu „Dump und Neuladen“ ist die Migration mit pg_upgrade weniger zeitaufwändig.

Die Programmdateien aller PostgreSQL-Versionen werden in unterschiedlichen, versionsabhängigen Verzeichnissen abgelegt. Beispielsweise in /usr/lib/postgresql96/ für Version 9.6, in /usr/lib/postgresql10/ für Version 10 und in /usr/lib/postgres13/ für Version 13. Beachten Sie, dass sich die Versionsrichtlinien von PostgreSQL zwischen den Hauptversionen 9.6 und 10 geändert haben. Weitere Informationen finden Sie im https://www.postgresql.org/support/versioning/.

Wichtig
Wichtig: Aufrüstung von SLE 11

Wenn Sie von SLE 11 aufrüsten, wird postgresql94 nicht deinstalliert und kann nicht für die Datenbankmigration zu einer höheren PostgreSQL-Version verwendet werden. Stellen Sie in diesem Fall also sicher, dass Sie die PostgreSQL-Datenbank vor dem Upgrade des Systems migrieren.

Im unten geschilderten Verfahren finden Sie die Schritte für die Datenbankmigration von Version 12 zu Version 13. Werden als Ausgangspunkt oder Ziel andere Versionen verwendet, ersetzen Sie die Versionsnummern entsprechend.

So führen Sie die Datenbankmigration aus:

  1. Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:

    • Upgraden Sie alle Pakete der alten PostgreSQL-Version per Wartungsaktualisierung auf die aktuelle Version, sofern Sie dies noch nicht erledigt haben.

    • Erstellen Sie eine Sicherung der vorhandenen Datenbank.

    • Installieren Sie die Pakete der neuen PostgreSQL-Hauptversion. Für SLE 15 SP5 bedeutet dies die Installation von postgresql13-server und aller Pakete, von denen diese PostgreSQL-Version abhängt.

    • Installieren Sie das Paket postgresql13-contrib, das das Kommando pg_upgrade enthält.

    • Prüfen Sie, ob ausreichend freier Speicherplatz im PostgreSQL-Datenbereich verfügbar ist (standardmäßig /var/lib/pgsql/data). Falls der Speicherplatz nicht ausreicht, versuchen Sie, die einzelnen Datenbanken mit dem folgenden SQL-Kommando zu verkleinern (kann sehr lange dauern): 

      VACUUM FULL

  2. Halten Sie den PostgreSQL-Server mit einer der folgenden Optionen an: 

    # /usr/sbin/rcpostgresql stop

    oder 

    # systemctl stop postgresql.service

    (abhängig von der SLE-Version, die Sie als Ausgangsversion des Upgrades nutzen).

  3. Benennen Sie das alte Datenverzeichnis um: 

    # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

  4. Initialisieren Sie die neue Datenbankinstanz manuell mit initdb oder starten und stoppen Sie PostgreSQL, wodurch die Instanz automatisch initialisiert wird: 

    # /usr/sbin/rcpostgresql start
# /usr/sbin/rcpostgresql stop

    oder 

    # systemctl start postgresql.service
# systemctl stop postgresql.service

    (abhängig von der SLE-Version, die Sie als Ausgangsversion des Upgrades nutzen).

  5. Sollten Sie in der alten Version die Konfigurationsdateien bearbeitet haben, ziehen Sie in Betracht, diese Änderungen in die neuen Konfigurationsdateien zu übernehmen. Dieser Umstand könnte sich auf die Dateien postgresql.auto.conf, postgresql.conf, pg_hba.conf und pg_ident.conf auswirken. Die alten Versionen dieser Dateien befinden sich in /var/lib/pgsql/data.old/, die neuen Versionen in /var/lib/pgsql/data.

    Beachten Sie, dass wir nicht empfehlen, die alten Konfigurationsdateien zu kopieren, da so möglicherweise neue Optionen, neue Standardeinstellungen und geänderte Kommentare überschrieben werden.

  6. Beginnen Sie als Benutzer postgres mit der Migration: 

    # su - postgres
postgres > pg_upgrade \
 --old-datadir "/var/lib/pgsql/data.old" \
 --new-datadir "/var/lib/pgsql/data" \
 --old-bindir "/usr/lib/postgresql12/bin/" \
 --new-bindir "/usr/lib/postgresql13/bin/"

  7. Starten Sie Ihre neue Datenbank über eine der folgenden Optionen: 

    # /usr/sbin/rcpostgresql start

    oder 

    # systemctl start postgresql.service

    (abhängig von der SLE-Version, die Sie als Ausgangsversion des Upgrades nutzen).

  8. Überprüfen Sie, ob die Migration erfolgreich war. Der Testumfang hängt von Ihrem Anwendungsfall ab. Zur Automatisierung dieses Schritts steht kein allgemeines Tool zur Verfügung.

  9. Entfernen Sie alle alten PostgreSQL-Pakete und das alte Datenverzeichnis: 

    # zypper search -s postgresql12| xargs zypper rm -u
# rm -rf /var/lib/pgsql/data.old

Weitere Informationen zum Upgrade von Datenbanken oder zur Verwendung alternativer Methoden wie der logischen Reproduktion finden Sie in der offiziellen PostgreSQL-Dokumentation unter https://www.postgresql.org/docs/13/upgrading.html.

3.8 Migration der MySQL- oder MariaDB-Datenbank

 

Ab SUSE Linux Enterprise 12 hat SUSE von MySQL auf MariaDB umgestellt. Bevor Sie das Upgrade starten, wird dringend empfohlen, die Datenbank zu sichern.

So führen Sie die Datenbankmigration aus:

  1. Erstellen Sie eine Dump-Datei: 

    # mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql

    Standardmäßig wird die Datenbank mysqldump oder INFORMATION_SCHEMA nicht im Speicherauszug mit performance_schema berücksichtigt. Weitere Informationen finden Sie unter https://mariadb.com/kb/en/mariadb-dumpmysqldump/.

  2. Speichern Sie Ihre Dump-Datei, die Konfigurationsdatei /etc/my.cnf sowie das Verzeichnis /etc/mysql/ an einem sicheren Speicherort, um sie später als Referenz (nicht zur Installation) zu verwenden.

  3. Führen Sie das Upgrade von SUSE Linux Enterprise Server durch. Nach dem Upgrade ist die bisherige Konfigurationsdatei /etc/my.cnf unverändert. Die neue Konfiguration finden Sie in der Datei /etc/my.cnf.rpmnew.

  4. Konfigurieren Sie die MariaDB-Datenbank je nach Bedarf. Bearbeiten Sie dabei nicht die bisherige Konfigurationsdatei und das frühere Verzeichnis, sondern nutzen Sie diese nur als Vorlage, und passen Sie die Einstellungen entsprechend an.

  5. Starten Sie den MariaDB-Server: 

    # systemctl start mariadb

    Soll der MariaDB-Server bei jedem Booten gestartet werden, aktivieren Sie den Dienst: 

    # systemctl enable mariadb

  6. Prüfen Sie, ob MariaDB ordnungsgemäß ausgeführt wird. Stellen Sie hierzu eine Verbindung zur Datenbank her: 

    # mariadb -u root -p

3.9 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 ab, in denen die Schlüssel gefunden werden können. Für Tomcat beispielsweise lautet das Verzeichnis /etc/tomcat/ssl/.

3.10 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.11 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 Skripts clientSetup4SMT.sh auf Ihrem Host aktuell ist. clientSetup4SMT.sh aus älteren Versionen von SMT kann nicht zum Verwalten von SMT 12-Clients verwendet werden. 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 Server nicht ausgeführt werden kann, 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.12 Änderungen der AutoYaST-Profile von SLE 12 bis 15

 

Informationen zur Migration von AutoYaST-Profilen finden Sie im Appendix D, Differences between AutoYaST profiles in SLE 12 and 15.

3.13 Upgraden eines Subscription Management Tool-(SMT-)Servers

 

Für einen Server mit SMT ist ein besonderes Upgradeverfahren erforderlich. Weitere Informationen hierzu finden Sie unter Chapter 3, Migrate from SMT to RMT im Repository Mirroring Tool Guide.

3.14 Vorübergehende Deaktivierung der Unterstützung mehrerer Kernel-Versionen

 

SUSE Linux Enterprise Server ermöglicht die Installation mehrerer Kernel-Versionen. Hierfür müssen die entsprechenden Einstellungen in /etc/zypp/zypp.conf aktiviert werden. Für das Upgrade auf ein Service Pack muss diese Funktion vorübergehend deaktiviert werden. Sobald die Aktualisierung erfolgreich abgeschlossen wurde, kann die Unterstützung mehrerer Versionen wieder aktiviert werden. Zur Deaktivierung der Unterstützung mehrerer Versionen müssen die entsprechenden Zeilen in /etc/zypp/zypp.conf kommentiert werden. Das Ergebnis sollte wie folgt aussehen: 

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Wenn Sie diese Funktion nach einer erfolgreichen Aktualisierung wieder aktivieren möchten, entfernen Sie die Kommentarzeichen. Weitere Informationen zur Unterstützung mehrerer Versionen finden Sie im Abschnitt 27.1, „Aktivieren und Konfigurieren der Multiversions-Unterstützung“.

3.15 Upgraden auf IBM Z

 

Für das einer SUSE Linux Enterprise-Installation auf IBM Z muss der Kernel-Parameter Upgrade=1Upgrade= angegeben werden, z. B. in der parmfile. Weitere Informationen hierzu finden Sie im Abschnitt 5.5, „Die Parmfile – Automatisierte Systemkonfiguration“.

3.16 IBM POWER: Starten eines X-Servers

 

Unter SLES 12 für IBM POWER ist der Anzeige-Manager so konfiguriert, dass ein lokaler X-Server nicht standardmäßig gestartet wird. Diese Einstellung wurde in SLES 12 SP1 rückgängig gemacht, sodass der Anzeige-Manager jetzt einen X-Server startet.

Die SUSE Linux Enterprise Server-Einstellung wird nicht automatisch geändert, damit keine Probleme im Rahmen des Upgrades auftreten. Wenn der Anzeige-Manager nach dem Upgrade einen X-Server starten soll, ändern Sie die Einstellung von DISPLAYMANAGER_STARTS_XSERVER in /etc/sysconfig/displaymanager wie folgt: 

DISPLAYMANAGER_STARTS_XSERVER="yes"