Behandeln von SLES-Migrationsproblemen auf virtuellen Azure Linux-Computern

Gilt für: ✔️ Linux-VMs

In diesem Artikel werden Probleme erläutert, die während DER SUSE Linux Enterprise Server(SLES)-Migrationen auftreten und ihnen Lösungen zur Verfügung stellen.

Achtung

Nach dem Prozess in diesem Artikel wird eine Trennung zwischen der Datenebene und der Kontrollebene des virtuellen Computers (VM) verursacht. Azure-Funktionen wie automatisches Gastpatching ,Automatische Betriebssystemimageupgrades ,Hotpatching undAzure Update Manager sind nicht verfügbar. Um diese Features zu nutzen, empfiehlt es sich, einen neuen virtuellen Computer mit Ihrem bevorzugten Betriebssystem zu erstellen, anstatt ein direktes Upgrade durchzuführen.

Voraussetzungen

• Dieses Handbuch für das Verteilungsmigrationssystem (DMS) enthält allgemeine Schritte zum Upgrade von SLES 12 auf SLES 15 für einen virtuellen Azure-Computer. Weitere Informationen finden Sie unter Upgrade von SUSE Linux Enterprise in der Public Cloud und SUSE Product Lifecycle.
• Da für die Migration der virtuelle Computer neu gestartet werden muss, planen Sie die Migrationsaktivität gemäß dem genehmigten Ausfallzeitfenster.
• Erstellen Sie eine vollständige Sicherung oder Momentaufnahme des virtuellen Computers, bevor Sie die Migration durchführen.
• Überprüfen Sie, ob es sich um eine VM der Generation V1 oder der Generation V2 handelt.

Überprüfen der Version einer VM

Sie können die Generierungsversion mit einer der folgenden Methoden überprüfen:

• Führen Sie den folgenden Befehl im SLES-Terminal aus:

  sudo dmidecode | grep -i hyper
  

  Wenn es sich um eine VM der Generation 1 handelt, wird keine Ausgabe zurückgegeben.

  Wenn es sich um eine VM der Generation 2 handelt, können Sie eine Ausgabe wie den folgenden Text sehen:

  Version: Hyper-V UEFI Release v4.1
  Version: Hyper-V UEFI Release v4.1
  Version: Hyper-V UEFI Release v4.1
  Version: Hyper-V UEFI Release v4.1
  

• Wechseln Sie in der Azure-Portal zu den VM-Eigenschaften, und überprüfen Sie dann das Feld der VM-Generierung wie gezeigt:

  

Szenario 1: Die Migration von SLES 12 zu SLES 15 ist erfolgreich, aber das Upgrade von SLES 15 SP1 auf SP2 schlägt fehl.

Während Sie den sudo zypper migration Befehl ausführen, schlägt die Migration fehl, und Sie erhalten die folgende Ausgabe:

Can't get available migrations from server: SUSE::Connect::ApiError: The requested products 'HPC Module 12 x86_64' are not activated on the system.

Oder

Can't get available migrations from server: SUSE::Connect::ApiError: Invalid combination of  products registered.

Sie können die Ausgabe auch in der /var/log/messages Datei /var/log/distro-migration.log finden.

Ursache

Eine wesentliche Änderung zwischen SLES 12 und SLES 15 besteht darin, dass High-Performance Computing (HPC) zu einem eigenständigen Produkt wird. Daher ist das HPC-Modul nicht mehr für Systeme verfügbar, die als SLES registriert sind. Diese Änderung bewirkt, dass das Migrationsziel kein Ziel findet und der Migrationsprozess fehlschlägt.

Lösung

Um dieses Problem zu beheben, entfernen Sie das HPC-Modul, bevor Sie die Migration starten, indem Sie den folgenden Befehl ausführen:

sudo zypper rm sle-module-hpc-release-POOL sle-module-hpc-release

Problemumgehung

Um dieses Problem zu umgehen, wechseln Sie sle-module-hpc.prod aus dem /etc/products.d/ Verzeichnis zu einem temporären Speicherort, und versuchen Sie die Migration erneut. Führen Sie hierzu die folgenden -Befehle aus:

cd /etc/products.d

sudo mv sle-module-hpc.prod /tmp/

sudo zypper migration

Weitere Informationen finden Sie unter Major distros in the Public Cloud and zypper migration fails in Azure.

Szenario 2: Fehler beim Installieren des Pakets "suse-migration-sles15-activation"

Während Sie das suse-migration-sles15-activation Paket installieren, schlägt die Migration fehl, und Sie erhalten die folgende Ausgabe:

'suse-migration-sle15-activation' not found in package names. Trying capabilities. No provider of 'suse-migration-sle15-activation' found.

Sie finden diese Ausgabe auch in der /var/log/messages Datei./var/log/distro-migration.log

Ursache

Das SLES 12 Public Cloud-Modul ist standardmäßig nicht aktiviert.

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Aktivieren Sie das Public Cloud-Modul, und versuchen Sie dann erneut, das Paket zu installieren:

   sudo SUSEConnect -p sle-module-public-cloud/12/x86_64
   

   Notiz

   Auf SLES für SAP-Instanzen sollten nie zwei Pakete vorhanden sein: sle-ha-release und sle-ha-release-POOL. Entfernen Sie in diesem Fall vor dem Starten der Verteilungsmigration diese Pakete, indem Sie den sudo zypper remove sle-ha-release sle-ha-release-POOL Befehl ausführen.

2. Führen Sie eine Bereinigung auf dem System durch, und registrieren Sie sie dann erneut:

   sudo SUSEConnect --cleanup
   

   sudo rm /etc/zypp/{credentials,services,repos}.d/*
   

   sudo rm --force --recursive /var/cache/zypp/*
   

   sudo rm /var/lib/cloudregister/*
   

   sudo registercloudguest --force-new
   

3. Überprüfen Sie den Status der VM-Registrierung:

   sudo SUSEConnect --status
   

4. Fahren Sie mit der Migration fort:

   sudo zypper migration
   

Weitere Informationen finden Sie unter Major Distros in the Public Cloud and Upgrade SUSE Linux Enterprise in the Public Cloud.

Szenario 3: Nach dem Upgrade von SLE 15 SP1 auf SLE 15 SP2 können VMs der Generation 2 nach dem Beenden nicht gestartet werden.

Nachdem der virtuelle Computer der Generation 2 von SLES 15 SP1 auf SLES 15 SP2 aktualisiert wurde, wird der virtuelle Computer nicht gestartet, nachdem er vom Azure-Portal beendet wurde oder den init 0 Befehl ausführtshutdown -h. Die folgende Ausgabe wird im seriellen Konsolenprotokoll oder boot.log unter dem /var/log/ Verzeichnis angezeigt:

Loading Linux 5.3.18-24.49-default ...  
error: symbol grub_file_filters' not found                                                 
Loading initial ramdisk ...  
error: symbol grub_file_filters' not found
Press any key to continue.

Oder

Loading Linux 5.3.18-24.49-default ...  
error: symbol grub_verify string' not found                                                 
Loading initial ramdisk ...  
error: symbol grub_verify string' not found
Press any key to continue...

Ursache

Nachdem die VM der Generation 2 neu gestartet, beendet oder abgeglichen wurde, behält Hyper-V in der Azure-Umgebung ihre Starteinträge nicht bei. In diesem Fall kann die SUSE Linux-VM nicht gestartet werden.

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Richten Sie die chroot-Umgebung von dem betroffenen VM-Snapshotdatenträger auf einem virtuellen Rettungscomputer ein, wie in der Chroot-Umgebung in einer Linux-Rettungs-VM beschrieben.

2. Installieren Sie das GRUB-Startladeprogramm neu:

   sudo /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg
   

3. Tauschen Sie den Snapshotdatenträger wie in der Chroot-Umgebung in einer Linux-Rettungs-VM beschrieben wieder auf den problematischen virtuellen Computer aus.

Weitere Informationen finden Sie unter grub2-Fehler: Das Symbol "grub_file_filters" wurde nicht gefunden.

Szenario 4: Fehler bei der Migration von SLES 15 zu SLES 15 SP3

Die Migration schlägt von SLES 15 zu SLES 15 SP3 fehl, und Sie erhalten die folgende Ausgabe:

Can't get available migrations from server: SUSE::Connect::ApiError: The requested products 'SUSE Linux Enterprise High Availability Extension 15 SP1 x86_64, Basesystem Module 15 SP1 x86_64, SUSE Cloud Application Platform Tools Module 15 SP1 x86_64, Containers Module 15 SP1 x86_64, Desktop Applications Module 15 SP1 x86_64, Development Tools Module 15 SP1 x86_64, Legacy Module 15 SP1 x86_64, Public Cloud Module 15 SP1 x86_64, Python 2 Module 15 SP1 x86_64, SAP Applications Module 15 SP1 x86_64, Server Applications Module 15 SP1 x86_64, Web and Scripting Module 15 SP1 x86_64, Transactional Server Module 15 SP1 x86_64' are not activated on the system.
/usr/lib/zypper/commands/zypper-migration' exited with status 1

Sie können sie auch in der Datei oder /var/log/distro-migration.log in der /var/log/messages Datei finden.

Ursache

Dieser Fehler tritt auf, da die SLES-Migration von SLES 15 zu einer späteren Version unterbrochen, beendet oder versehentlich beendet wird, was zu unvollständigen Paketupdates im System führt.

Lösung

Um dieses Problem zu beheben, führen Sie ein Rollback aller Pakete auf die mit SLES 15 kompatiblen Versionen durch, und versuchen Sie die Migration erneut:

1. Überprüfen Sie doppelte Pakete im System:

   sudo zypper dup
   

2. Zurücksetzen der Änderungen:

   sudo zypper rollback
   

3. Führen Sie die Migration erneut aus:

   sudo zypper migration
   

Szenario 6: Nach der Migration kann SUSE nicht mit dem neuesten Kernel gestartet werden, gefolgt von einem Registrierungsfehler

Nach der Migration kann der virtuelle Computer nicht mit dem neuesten Kernel gestartet werden. Darüber hinaus funktionieren Repositorys nicht, und Sie erhalten eine Fehlermeldung, die besagt, dass die Repositorys nicht definiert sind.

Ursache

Das /etc/credentials.d Verzeichnis verfügt über falsche Berechtigungen, oder der Inhalt einer Datei in diesem Verzeichnis ist falsch oder beschädigt.

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Bereinigen Sie die Registrierung:

   sudo rm /var/cache/cloudregister/
   

   sudo rm /etc/zypp/credentials.d/
   

   sudo chmod 0755 /etc/zypp/credentials.d*
   

   sudo registercloudguest --force-new
   

2. Nachdem die Registrierung erfolgreich abgeschlossen wurde, patchen Sie den virtuellen Computer, und starten Sie den virtuellen Computer neu:

   sudo zypper update
   
   

   sudo reboot
   

Szenario 7: Die Migration von SLES 12 SP5 zu SLES 15 SP1 schlägt aufgrund des RegionService-Verzeichnisproblems fehl.

Die Migration schlägt von SLES 12 SP5 zu SLES 15 SP1 fehl, und Sie erhalten die folgende Ausgabe:

Skipping repository 'SLE-Module-Containers12-Updates' because of the above error.
Error retrieving metadata for 'SLE-Module-HPC12-Pool':
Not ready to read within timeout.
Skipping repository 'SLE-Module-HPC12-Pool' because of the above error.
Error retrieving metadata for 'SLE-Module-HPC12-Updates' :
Not ready to read within timeout.
Skipping repository 'SLE-Module-HPC12-Updates' because of the above error.
Error retrieving metadata for 'SLE-Module-Legacy12-Pool' :
Not ready to read within timeout.
Skipping repository 'SLE-Module-Legacy12-Pool' because of the above err Error retrieving metadata for 'SLE-Module-Legacy12-Updates' :
Not ready to read within timeout.
Skipping repository 'SLE-Module-Legacy12-Updates' because of the above Error retrieving metadata for 'SLE-Module-Public-Cloud12-Pool' :
Not ready to read within timeout.
Skipping repository 'SLE-Module-Public-Cloud12-Pool' because of the abo Error retrieving metadata for 'SLE-Module-Public-Cloud12-Updates' :
Not ready to read within timeout.
Skipping repository 'SLE-Module-Public-Cloud12-Updates' because of the

Sie können die Ausgabe auch in der /var/log/messages Datei /var/log/distro-migration.log finden.

Ursache

Das regionService Verzeichnis wechselt von /var/lib zu /usr/lib, aber das DMS-Skript wird nur nach dem certs Verzeichnis gesucht, unter /var/lib dem die Bindungs-Bereitstellung in die ISO-Laufzeitumgebung eingerichtet wird.

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Erstellen Sie das zuvor verwendete Verzeichnis /var/lib/regionService/certs:

   sudo mkdir -p /var/lib/regionService/certs
   

2. Kopieren Sie die Zertifikatdateien in /var/lib/regionService/certs:

   sudo cp -a /usr/lib/regionService/certs/* /var/lib/regionService/certs/
   

3. Ändern Sie die /etc/regionserverclnt.cfg Datei, und legen Sie den certLocation Parameter auf den zuvor verwendeten Pfad /var/lib/regionService/certsfest:

   sudo vi /etc/regionserverclnt.cfg
   

4. Überprüfen Sie die geänderte Datei:

   sudo cat /etc/regionserverclnt.cfg
   

   [server]
   api = regionInfo
   #certLocation = /usr/lib/regionService/certs
   certLocation = /var/lib/regionService/certs
   regionsrv = 23.100.36.229,40.121.202.140,52.187.53.250,104.45.31.195,191.237.254.253
   [instance]
   dataProvider = /usr/bin/azuremetadata --api latest --subscriptionId --billingTag --attestedData --signature --xml
   instanceArgs = msftazure
   httpsOnly = true
   

5. Installieren Sie das neueste SLES15-Migration Paket:

   sudo zypper in SLES15-Migration
   

6. Führen Sie die Migration erneut aus:

   sudo zypper migration
   

Weitere Informationen finden Sie unter SLES 12 SP5 Distribution Migration System (DMS) fehlgeschlagen.

Szenario 8: Die Migration schlägt aufgrund eines unbekannten Ordners im Verzeichnis "/etc/pki/trust/anchors" fehl.

Die Migration von SLES 12 SP5 zu SLES 15 SP1 schlägt fehl, und die folgenden Fehlermeldungen werden in der /var/log/distro_migration.log Datei angezeigt:

Mar 11 13:39:15 localhost suse-migration-prepare[1510]: IsADirectoryError: [Errno 21] Is a directory: '/system-root/etc/pki/trust/anchors/temp'
Mar 11 13:39:15 localhost systemd[1]: suse-migration-prepare.service: Main process exited, code=exited, status=1/FAILURE
Mar 11 13:39:15 localhost systemd[1]: Failed to start Prepare For Migration.
Mar 11 13:39:15 localhost systemd[1]: suse-migration-prepare.service: Unit entered failed state.
Mar 11 13:39:15 localhost systemd[1]: suse-migration-prepare.service: Failed with result 'exit-code'.

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Verschieben Sie den temp Ordner im Verzeichnis in /etc/pki/trust/anchors das /backuplocation/ Verzeichnis:

   sudo mv /etc/pki/trust/anchors/temp /backuplocation/temp
   

2. Installieren Sie das Migrationspaket:

   sudo zypper install suse-migration-sle15-activation
   

3. Führen Sie die Migration erneut aus:

   sudo zypper migration
   

Szenario 9: SUSE-Registrierung und Repositorys funktionieren nach der Migration nicht

Während der Betriebssystemmigration von SLES 15 SP3 zu SLES 15 SP4 wird der Prozess erfolgreich abgeschlossen. Wenn Sie jedoch von SLES 15 SP4 zu SLES 15 SP5 migrieren, funktionieren die Migration und Updates nicht wie erwartet, und Sie erhalten die folgende Ausgabe:

         sle-module-desktop-applications/15.3/x86_64 Desktop Applications Module
         sle-module-development-tools/15.3/x86_64 Development Tools Module
         sle-ha/15.3/x86_64          SUSE Linux Enterprise High Availability Extension 15 SP3
         sle-module-sap-applications/15.3/x86 64  SAP Applications Module
         sle-module-live-patching/15.3/x86_64   SUSE Linux Enterprise Live Patching
         PackageHub/15.3/x86 64   SUSE Package Hub 15
         sle-module-certifications/15.3/x86_64   Certifications Module
 Unavailable migrations (product is not mirrored):
         SUSE Linux Enterprise Server for SAP Applications 15 SP6 x86_64 (not available) Basesystem Module 15 SP6 x86_64 (not available) Certifications Module 15 SP6 x86_64 (not available) Containers Module 15 SP6 x86_64 (not available)
         Desktop Applications Module 15 SP6 x86_64 (not available)
         Server Applications Module 15 SP6 x86_64 (not available)
         SUSE Linux Enterprise Live Patching 15 SP6 x86_64 (not available)
         SUSE Package Hub 15 SP6 x86_64 (not available)
         Development Tools Module 15 SP6 x86_64 (not available)
         Legacy Module 15 SP6 x86_64 (not available)
         Public Cloud Module 15 SP6 x86_64 (not available)
         SUSE Linux Enterprise High Availability Extension 15 SP6 x86 64 (not available) Web and Scripting Module 15 SP6 x86_64 (not available)
         SAP Applications Module 15 SP6 x86_64 (not available)
No migration available.
'/usr/lib/zypper/commands/zypper-migration' exited with status 1

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Aktivieren Und deaktivieren Sie vor der Migration die folgenden Module.

   1. Aktivieren Sie die folgenden Module:

      sudo SUSEConnect -p sle-module-web-scripting/15.3/x86_64
      sudo SUSEConnect -p sle-module-public-cloud/15.3/x86_64
      sudo SUSEConnect -p sle-module-containers/15.3/x86_64
      sudo SUSEConnect -p sle-module-live-patching/15.3/x86_64
      

   2. Deaktivieren Sie die folgenden Module:

      sudo SUSEConnect -d -p sle-module-legacy/15.3/x86_64
      sudo SUSEConnect -d -p sle-module-python2/15.3/x86_64
      sudo SUSEConnect -d -p PackageHub/15.3/x86_64
      

2. Führen Sie eine Bereinigung auf dem System durch, und registrieren Sie sie dann erneut:

   sudo SUSEConnect --cleanup
   

   sudo rm /etc/zypp/{credentials,services,repos}.d/*
   

   sudo rm --force --recursive /var/cache/zypp/*
   

   sudo rm /var/lib/cloudregister/*
   

   sudo registercloudguest --force-new
   

3. Überprüfen Sie den Status der VM-Registrierung:

   sudo SUSEConnect --status
   

Szenario 10: Fehler bei der SLES 15-Migration von SP3 zu SP4 mit ungültigen Anmeldeinformationen und Repositoryfehlern

Die SLES 15-Migration von SP3 zu SP4 schlägt fehl, und Sie erhalten die folgende Ausgabe:

sudo SUSEConnect -S

Error: Invalid system credentials, probably because the registered system was deleted in SUSE Customer Center. Check https://scc.suse.com whether your system appears there. If it does not, please call SUSEConnect --cleanup and re-register this system.

sudo zypper migration

Executing '/usr/bin/zypper patch-check-updatestack-only'
Loading repository data...
Warning: No repositories defined. Operating only with the installed resolvables. Nothing can be installed. Reading installed packages...
O patches needed (0 security patches)
Executing '/usr/bin/zypper ref'
Warning: There are no enabled repositories defined.
Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories.
repository refresh failed, exiting
'/usr/lib/zypper/commands/zypper-migration' exited with status 1

Sie können auch die Ausgaben in der Datei oder /var/log/distro-migration.log in der /var/log/messages Datei finden.

Ursache

Die Migration schlägt fehl, da das Zertifizierungsmodul vorhanden ist.

Lösung

Um dieses Problem zu beheben, führen Sie den folgenden Befehl aus, um das Zertifizierungsmodul vor dem Update zu deaktivieren, und versuchen Sie die Migration erneut:

sudo SUSEConnect -d -p sle-module-certifications/15.3/x86_64

Szenario 11: Migration schlägt aufgrund von Drittanbietermodulen und Sicherheitstools fehl

Einige Probleme treten während der VM-Migration auf, z. B. der virtuelle Computer, der in einen hängenden Zustand eintritt, Startfehler oder längere Prozesse bei Zypper-Modulrepositorys.

Ursache

• Sicherheitstools können die Migration stören, indem Vorgänge blockiert oder Systemdateien geändert werden, was zu Instabilität führt.
• Drittanbieterrepositorys können Pakete einführen, die mit offiziellen SUSE-Paketen in Konflikt treten, was möglicherweise zu weiteren Komplikationen während des Upgrades führt.

Lösung

Es wird empfohlen, alle Repositorys und Sicherheitstools von Drittanbietern auf dem System zu deaktivieren, bevor Sie mit der SUSE-Migration fortfahren. Die Deaktivierung während der Migration ist entscheidend, um Abhängigkeitskonflikte zu verhindern, die Systemstabilität sicherzustellen, die Konsistenz mit offiziellen Paketen aufrechtzuerhalten, die Problembehandlung zu vereinfachen und einen reibungsloseren Upgradeprozess zu ermöglichen.

Nächste Schritte

Wenn Ihr Problem nicht behoben ist, erstellen Sie eine Supportanfrage. Wenn Sie Ihre Anforderung übermitteln, fügen Sie eine Kopie der /var/log/distromigration.log Datei zur Problembehandlung an.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.