SLES Migration: Solving Virtual Machine Issues for a Smooth Transition

Updated: 23 Sep, 2025 • 0 • min read

Table of Contents

Migrating SUSE Linux Enterprise Server (SLES) can be a complex process, often leading to unexpected virtual machine (VM) issues that can halt a smooth transition. This comprehensive guide outlines common problems encountered during SLES migrations and provides detailed, actionable solutions to ensure your upgrade proceeds without major hitches. Understanding these scenarios and their respective fixes is crucial for maintaining system stability and achieving a successful migration.

Prerequisites for a Smooth SLES Migration¶

Before initiating any SLES migration activity, careful preparation is essential. Adhering to these prerequisites can significantly reduce the likelihood of encountering unexpected issues and ensure a more predictable outcome for your Azure VM.

Key Preparatory Steps:

Consult SUSE Documentation: While this article provides specific troubleshooting for Azure VMs, it’s vital to refer to the official SUSE Distribution Migration System (DMS) guide for general guidance on upgrading SLES versions. This ensures you are following the vendor’s best practices. SUSE also provides valuable resources on upgrading SLES in public clouds and their product lifecycle.
Plan for Downtime: SLES migration typically requires the VM to restart at various stages. Therefore, schedule the migration during an approved downtime window to minimize disruption to operations. Communicate this downtime to all affected stakeholders in advance.
Perform Full Backup or Snapshot: Before undertaking any major system change like an OS migration, always create a complete backup or a snapshot of your VM. This acts as a critical recovery point, allowing you to revert the VM to its previous state if the migration process fails or introduces unforeseen problems.
Check VM Generation: Identifying whether your VM is Generation 1 (V1) or Generation 2 (V2) is a critical step, as certain migration behaviors and boot issues are specific to VM generations.

Checking the VM Generation Version¶

The generation version of your VM can influence how it behaves during and after migration. You can ascertain this information using two primary methods, ensuring you have the correct context for potential troubleshooting.

Method 1: Using the SLES Terminal

You can determine the VM’s generation by executing a specific command within the SLES terminal. This command queries the system’s DMI (Desktop Management Interface) data for Hyper-V specific information.

Run the following command in your SLES terminal:

sudo dmidecode | grep -i hyper

If your VM is a Generation 1 (V1) machine, this command will produce no output. This indicates the absence of UEFI-related Hyper-V entries.
If your VM is a Generation 2 (V2) machine, you will see output similar to the following, indicating UEFI firmware information:

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

Method 2: Through the Azure Portal

Alternatively, you can quickly check the VM generation directly from the Azure portal. This graphical interface provides a straightforward way to view your VM’s properties without needing to access the operating system.

Navigate to your VM’s Properties section within the Azure portal. Look for the VM generation field, which explicitly states whether the VM is Generation 1 or Generation 2. This visual confirmation is often the quickest method.

Scenario 1: Migration from SLES 12 to SLES 15 Succeeds, but Upgrade from SLES 15 SP1 to SP2 Fails¶

During a staged migration, you might successfully upgrade from SLES 12 to SLES 15, but then encounter failures when attempting to move from SLES 15 SP1 to SP2. This issue typically manifests when running the sudo zypper migration command, leading to error messages indicating product activation problems. The system reports that requested products are not activated or that there is an invalid combination of registered products.

When running sudo zypper migration, you might observe output similar to this:

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

Or, alternatively:

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

These errors can also be logged in system files such as /var/log/messages or /var/log/distro-migration.log, providing further details on the failure.

Cause¶

The root cause of this migration failure lies in a significant architectural change between SLES 12 and SLES 15. In SLES 15, the High-Performance Computing (HPC) module was reclassified and became a standalone product. Consequently, this module is no longer inherently available to systems that are simply registered as standard SLES instances. This change in product registration prevents the migration process from properly identifying a valid target state, thus causing the migration to fail.

Resolution¶

To rectify this issue, the HPC module must be explicitly removed from the system before proceeding with the migration. This ensures that the migration process doesn’t look for a module that is no longer part of the standard SLES product definition.

Execute the following command to remove the HPC module packages:

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

After successfully removing these packages, retry the sudo zypper migration command. The system should now be able to find a valid migration path without the conflict caused by the HPC module.

Workaround¶

If direct removal of the HPC module packages presents challenges or if you prefer a less intrusive approach, a workaround involves temporarily relocating the HPC product definition file. This allows the migration tool to bypass the HPC module check during its operation.

Navigate to the products definition directory:

cd /etc/products.d

Then, move the HPC product definition file to a temporary location, effectively making it invisible to the zypper migration command:

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

After moving the file, attempt the migration once more:

sudo zypper migration

This workaround enables the migration to proceed by circumventing the HPC module validation. Once the migration is complete, you can decide whether to restore the sle-module-hpc.prod file from /tmp/ if it’s still needed, though it’s generally recommended to stick to the module structure of the new SLES version. For further context, SUSE documentation on major distro upgrades in the public cloud and specific zypper migration failures in Azure provides additional insights.

Scenario 2: Installing the “suse-migration-sles15-activation” Package Fails¶

A common stumbling block during SLES migration involves the failure to install the suse-migration-sles15-activation package. This package is crucial for preparing the system for the SLES 15 migration path. When this installation fails, the migration process cannot proceed, leaving your system in its current state.

You might encounter an error message similar to the following when attempting to install the package:

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

These messages also frequently appear in /var/log/messages or /var/log/distro-migration.log, providing a record of the failure. The inability to locate or provide this package indicates a problem with the system’s module registration or repository configuration.

Cause¶

The primary reason for this failure is that the SLES 12 Public Cloud module is not enabled by default. The suse-migration-sles15-activation package relies on repositories provided by this module. Without the Public Cloud module being active, the system cannot find the necessary package, leading to the “not found” error.

Resolution¶

Resolving this issue involves a multi-step process that ensures the correct modules are enabled and the system’s registration and repository caches are clean. Proper registration is fundamental for zypper to locate and manage packages effectively.

Enable the Public Cloud Module:
First, explicitly enable the Public Cloud module for SLES 12. This action registers the necessary repositories that contain the migration activation package.
```
sudo SUSEConnect -p sle-module-public-cloud/12/x86_64
```
After enabling the module, attempt to install the suse-migration-sles15-activation package again. This step alone often resolves the immediate error.

Note: For SLES for SAP instances, ensure that sle-ha-release and sle-ha-release-POOL packages are removed before beginning the distribution migration. These high-availability packages can interfere with the migration process. Run sudo zypper remove sle-ha-release sle-ha-release-POOL if they are present.
Perform System Cleanup and Re-registration:
To ensure a fresh and accurate registration state, it’s beneficial to perform a thorough cleanup of existing registration data and repository caches. This eliminates any potentially corrupted or outdated information.
```
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
```
These commands consecutively clean up existing SUSEConnect credentials, remove repository definitions, clear the zypper cache, erase cloud registration data, and then force a new cloud guest registration.
Verify VM Registration Status:
After the cleanup and re-registration, verify that your VM is correctly registered and that all expected modules are active. This command provides a summary of the system’s registered products and modules.
```
sudo SUSEConnect --status
```
Confirm that the output shows an active and correct registration status for your SLES instance.
Proceed with Migration:
With the Public Cloud module enabled, the system cleaned, and registration verified, you should now be able to proceed with the SLES migration successfully.
```
sudo zypper migration
```
This systematic approach ensures that all dependencies are met and the system is properly configured for the migration. More information regarding major distro upgrades in the Public Cloud can be found in SUSE’s official documentation.

Scenario 3: After Upgrading from SLES 15 SP1 to SLES 15 SP2, Generation 2 VMs Don’t Restart After Being Stopped¶

A critical issue can arise for Generation 2 (V2) VMs after an upgrade from SLES 15 SP1 to SLES 15 SP2. These VMs might fail to restart once they have been stopped, either through the Azure portal or by using standard shutdown commands like init 0 or shutdown -h. This problem typically manifests as boot errors in the serial console or boot.log file, indicating a failure to load the Linux kernel or initial ramdisk due to missing GRUB symbols.

The serial console log or /var/log/boot.log might display error messages similar to these:

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.

Alternatively, you might see:

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...

These errors indicate a problem with the GRUB bootloader’s ability to locate and load essential components, preventing the system from initializing correctly.

Cause¶

This issue is specific to Generation 2 VMs running in the Azure environment. After a Generation 2 VM is restarted, stopped, or deallocated, the Hyper-V hypervisor in Azure does not consistently preserve its startup entries. This behavior can lead to a state where the SUSE Linux VM, post-upgrade, loses critical bootloader information, preventing it from starting successfully. The GRUB bootloader, in this scenario, fails to find required symbols, making the system unbootable.

Resolution¶

To resolve this boot failure for Generation 2 VMs, the GRUB bootloader needs to be reinstalled and properly configured. This typically requires accessing the VM’s disk from a rescue environment to perform the necessary repairs.

Set up the Chroot Environment:
You must first set up a chroot environment using the affected VM’s OS snapshot disk on a separate rescue VM. This process involves attaching the problematic disk to a working VM, mounting its file systems, and then using chroot to effectively operate within the problematic system’s environment. This allows you to perform maintenance tasks as if you were booted into the original VM. Detailed steps for setting up a chroot environment in a Linux rescue VM are available in specific troubleshooting guides.
Reinstall the GRUB Bootloader:
Once you are successfully within the chroot environment of your problematic VM’s disk, you can reinstall the GRUB bootloader. The shim-install command is used for this purpose, configuring the bootloader to properly recognize the system and its kernel.
```
sudo /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg
```
This command reinstalls the shim bootloader, which is crucial for UEFI-based systems, ensuring it points to the correct GRUB configuration file. This step effectively rebuilds the boot entries that might have been lost or corrupted.
Swap the Snapshot Disk:
After reinstalling the GRUB bootloader within the chroot environment, detach the repaired OS disk from the rescue VM. Then, swap this snapshot disk back into the original problematic VM. Detailed instructions for swapping a disk on a Linux rescue VM are typically covered in related Azure troubleshooting documentation.

Once the disk is reattached and the VM is powered on, it should now boot successfully, as the GRUB bootloader has been correctly reconfigured. For more detailed information on GRUB2 errors and similar boot issues, refer to SUSE support knowledge base articles.

Scenario 4: Migration from SLES 15 to SLES 15 SP3 Fails¶

Attempting to migrate from SLES 15 to SLES 15 SP3 can sometimes result in a failure, particularly if the migration process was previously interrupted. This scenario typically produces an error message indicating that a variety of products and modules are “not activated on the system.” This suggests an incomplete or inconsistent state of product registration.

When the migration fails, you might see output similar to this:

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

These error entries are often also found in /var/log/messages or /var/log/distro-migration.log, providing diagnostic information. The long list of seemingly unactivated modules points to a fundamental problem with the system’s package state.

Cause¶

This specific error usually occurs when a prior SLES migration, particularly from SLES 15 to a later service pack, was interrupted, forcibly stopped, or accidentally terminated. Such an abrupt cessation of the upgrade process can leave the system in an inconsistent state, with partial package updates or mixed versions of modules. This inconsistency then confuses zypper migration, making it unable to determine a valid target state because the system’s product activations appear fragmented or incomplete to the SUSEConnect server.

Resolution¶

To resolve this issue, the system needs to be brought back to a consistent state that is fully compatible with SLES 15. This involves rolling back any incomplete package updates to their SLES 15 versions and then retrying the migration from a clean base.

Check for Duplicate Packages:
First, use zypper dup to check for any duplicate packages. This command is primarily for distribution upgrades, but in this context, it can help identify packages that are in an inconsistent state or that have conflicting versions due to the interrupted migration.
```
sudo zypper dup
```
While you might not proceed with a full dup at this stage, the output will highlight package conflicts.
Roll Back Changes:
After identifying potential inconsistencies, the crucial step is to roll back any pending or partial changes that resulted from the interrupted migration. zypper rollback attempts to revert the system’s package state to a previously stable point or resolve conflicts by downgrading packages if necessary.
```
sudo zypper rollback
```
This command is designed to undo recent package actions, aiming to restore the system to a clean and stable SLES 15 state.
Retry Migration:
Once the system has been rolled back and is in a more consistent SLES 15 state, you can attempt the migration again. The zypper migration command should now be able to accurately assess the system’s state and find a valid upgrade path to SLES 15 SP3.
```
sudo zypper migration
```
By systematically cleaning up and resetting the package state, you provide the migration tool with a clear and consistent environment to work with, significantly increasing the chances of a successful upgrade.

Scenario 6: After Migration, SUSE Doesn’t Start by Using the Latest Kernel, and Registration Fails¶

A troubling outcome after a SUSE migration is a system that fails to boot with its newly installed kernel. Compounding this, repositories might cease to function, and you could receive error messages indicating that no repositories are defined. This situation leaves the system updated but effectively crippled, unable to receive further updates or access package management functionalities.

Symptoms include:
* The VM boots using an older kernel, not the one installed by the migration.
* zypper commands fail with messages like “No repositories defined.”
* Attempts to refresh or interact with repositories result in errors.

Cause¶

The root cause of these issues often lies in incorrect permissions or corrupted content within the /etc/credentials.d directory. This directory stores sensitive registration credentials and service information crucial for SUSEConnect to authenticate with SUSE’s update servers and manage repositories. If these files are inaccessible or malformed, the system cannot properly register or recognize its modules and repositories, leading to both boot and package management failures.

Resolution¶

Rectifying this situation involves cleaning up the corrupted registration data and forcing a complete re-registration of the system. This ensures that new, valid credentials and repository configurations are established, allowing the system to boot correctly and access updates.

Clean Up Registration:
Begin by removing old or corrupted registration caches and credential files. This step ensures that the system starts with a clean slate for registration.
```
sudo rm /var/cache/cloudregister/
sudo rm /etc/zypp/credentials.d/
sudo chmod 0755 /etc/zypp/credentials.d*
sudo registercloudguest --force-new
```
These commands consecutively remove the cloud registration cache, the credentials.d directory (which might contain old, problematic credential files), sets appropriate permissions on credentials.d (if it was recreated), and then forces a complete new registration with the cloud guest agent. The chmod 0755 command ensures the directory has correct read, write, and execute permissions for the owner, and read and execute for group and others, which is standard for such directories.
Update and Restart VM:
After a successful re-registration, the system should now have access to its repositories. It’s crucial to perform a full system update to ensure all packages are consistent with the newly registered environment, especially kernel packages. Following the update, a reboot is necessary to load the latest kernel and fully apply all changes.
```
sudo zypper update
sudo reboot
```
This sequence ensures that the system is fully synchronized with its registered products and modules, allowing it to boot with the latest kernel and function as expected.

Scenario 7: Migration from SLES 12 SP5 to SLES 15 SP1 Fails Because of the regionService Directory Issue¶

Migration attempts from SLES 12 SP5 to SLES 15 SP1 can fail with errors indicating problems retrieving metadata for various modules, such as HPC, Legacy, and Public Cloud. The errors typically state “Not ready to read within timeout” or “Skipping repository… because of the above error.” This suggests a fundamental issue with how the system accesses repository metadata during the migration process.

Error messages in /var/log/messages or /var/log/distro-migration.log often look like this:

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

The repeated timeouts and metadata retrieval errors across multiple modules point to a systemic configuration problem affecting repository access.

Cause¶

This specific issue arises because the regionService directory, which contains essential certificate files (certs) for secure communication with SUSE update servers, moved its default location between SLES versions. In SLES 15, regionService moved from /var/lib to /usr/lib. However, the Distribution Migration System (DMS) scripting, especially during the ISO runtime environment setup, still expects to find the certs directory specifically under /var/lib. This mismatch prevents the migration tool from establishing secure connections to retrieve metadata, leading to timeouts and failures.

Resolution¶

To resolve this, you need to recreate the old directory structure and copy the certificate files to the expected location. This allows the DMS scripting to find the necessary certificates and proceed with the migration.

Create the Old Directory Structure:
First, create the certs directory within the previously expected path, /var/lib/regionService/. This provides the location that the DMS scripting is looking for.
```
sudo mkdir -p /var/lib/regionService/certs
```
The -p flag ensures that parent directories are created if they don’t already exist.
Copy Certificate Files:
Next, copy all certificate files from their new location (/usr/lib/regionService/certs/) to the newly created old path (/var/lib/regionService/certs/). This makes the certificates accessible to the DMS scripts.
```
sudo cp -a /usr/lib/regionService/certs/* /var/lib/regionService/certs/
```
The -a flag ensures that files are copied archivally, preserving their attributes and permissions.
Modify the Configuration File:
Now, modify the certLocation parameter in the /etc/regionserverclnt.cfg file to explicitly point to the old, expected path.
```
sudo vi /etc/regionserverclnt.cfg
```
Inside the vi editor, change the line related to certLocation.

Check the Modified File:
Verify that the certLocation parameter in /etc/regionserverclnt.cfg has been correctly updated to the old path.

sudo cat /etc/regionserverclnt.cfg

The output should reflect the change, similar to this:

[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

Note the uncommented certLocation pointing to /var/lib/regionService/certs.

Install the Latest SLES15-Migration Package:
Ensure you have the latest SLES15-Migration package installed. This package provides the necessary tools and scripts for the migration.
```
sudo zypper in SLES15-Migration
```
Retry Migration:
With the certificates correctly positioned and the configuration updated, you can now retry the SLES migration. The DMS scripts should successfully locate the certificates and proceed with fetching repository metadata.
```
sudo zypper migration
```
This sequence addresses the specific path dependency issue, allowing the migration to progress. For more information, SUSE support knowledge base articles, such as those detailing DMS failures from SLES 12 SP5, can provide further context.

Scenario 8: Migration Fails Because of an Unknown Folder in the /etc/pki/trust/anchors Directory¶

A migration from SLES 12 SP5 to SLES 15 SP1 can unexpectedly fail if an unusual directory is present within the /etc/pki/trust/anchors path. This directory is typically reserved for trusted certificate authority (CA) certificates, and the presence of an unexpected folder can cause validation or processing errors during the migration preparation phase. The suse-migration-prepare service, which is crucial for initiating the migration, will report an IsADirectoryError.

Error entries in the /var/log/distro_migration.log file will typically look like this:

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'.

The error clearly indicates that the presence of a directory named temp in the trust/anchors path is causing the migration preparation service to fail.

Resolution¶

The solution to this problem is straightforward: remove or relocate the unexpected directory from the /etc/pki/trust/anchors path. This allows the suse-migration-prepare service to operate correctly without encountering the directory where it expects a file.

Move the temp Folder:
Relocate the problematic temp folder from /etc/pki/trust/anchors to a different, temporary location. This effectively removes it from the path where the migration script is checking.
```
sudo mv /etc/pki/trust/anchors/temp /backuplocation/temp
```
Replace /backuplocation/ with a suitable temporary directory on your system where you can safely move the folder, for example, /tmp/ or your home directory.
Install the Migration Package:
After moving the interfering directory, install the suse-migration-sle15-activation package. This step ensures that all necessary components for the SLES 15 migration are properly installed.
```
sudo zypper install suse-migration-sle15-activation
```
Retry Migration:
With the temp directory no longer present in the trust/anchors path and the migration package installed, you can now attempt the SLES migration again. The suse-migration-prepare service should now be able to start and complete its tasks without the IsADirectoryError.
```
sudo zypper migration
```
This resolution directly addresses the file system conflict, enabling the migration process to proceed smoothly.

Scenario 9: SUSE Registration and Repositories Don’t Work After Migration¶

After a successful OS migration, for example, from SLES 15 SP3 to SLES 15 SP4, you might encounter issues when attempting further migrations (e.g., to SLES 15 SP5). The migration and updates might not function as expected, often leading to messages indicating that available products are “not available” or that no migration is available. This implies a problem with how the system recognizes and accesses its registered modules and products after the initial migration.

The output from zypper migration might show a list of installed products, but then display numerous modules as “not available” for a target service pack:

         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

This output suggests that although some modules are listed as installed, the system cannot find a valid target for the desired migration. This is typically due to an inconsistent state of active and inactive modules after a prior migration.

Resolution¶

This issue is often caused by an incorrect set of activated or deactivated modules that are required for the target SLES service pack. The resolution involves explicitly activating and deactivating specific modules to align the system’s registration with the requirements of the intended migration path, followed by a thorough cleanup and re-registration.

Activate and Deactivate Specific Modules:
Before attempting the next migration, ensure that the correct set of modules is active and inactive. This might involve activating modules that are now required and deactivating those that could cause conflicts or are no longer applicable. The specific modules to activate or deactivate will depend on your system’s role and the target SLES version.
- Activate the following modules: These modules are often essential for cloud environments and general server functionality.
```
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
```
- Deactivate the following modules: These modules might be deprecated or cause conflicts in newer SLES versions, or they might not be part of the desired target state.
```
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
```
Perform System Cleanup and Re-registration:
After adjusting the module activations, perform a comprehensive cleanup of the system’s registration data and repository caches. This ensures that the system registers fresh with the SUSEConnect server, reflecting the new module configuration.
```
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
```
These commands systematically remove old registration artifacts, clear repository definitions, and force a new, clean cloud guest registration.
Verify VM Registration Status:
Finally, confirm that your VM is now correctly registered and that all expected products and modules are active according to your configuration.
```
sudo SUSEConnect --status
```
This output should now show a consistent and correct registration status, allowing zypper migration to find the appropriate upgrade path.

Scenario 10: SLES 15 Migration from SP3 to SP4 Fails with Invalid Credentials and Repository Errors Occur¶

When attempting to migrate SLES 15 from SP3 to SP4, you might encounter critical failures related to invalid system credentials and an inability to access repositories. This situation typically presents error messages from SUSEConnect regarding invalid credentials, often suggesting a deletion of the registered system in the SUSE Customer Center. Concurrently, zypper migration will report “No repositories defined” and that repository refresh failed.

Running sudo SUSEConnect -S might yield:

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.

Subsequent attempts to run sudo zypper migration will result in:

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

These errors indicate a breakdown in the system’s ability to authenticate with SUSE and access its package repositories, effectively blocking the migration.

Cause¶

This specific migration failure is frequently attributed to the presence and active state of the certification module. While seemingly benign, the certification module can sometimes interfere with the SUSEConnect process or repository configuration during a service pack migration. Its presence can lead to conflicts or an inconsistent state that SUSEConnect interprets as invalid credentials or a lack of defined repositories, thereby preventing the migration from progressing.

Resolution¶

To resolve this issue, the certification module needs to be explicitly disabled before initiating the migration. Disabling this module removes a potential point of conflict, allowing SUSEConnect and zypper to correctly manage system registration and access repositories.

Run the following command to disable the certification module before attempting the update:

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

After successfully disabling the certification module, retry the migration using sudo zypper migration. The system should now be able to validate its credentials and refresh repositories, allowing the upgrade from SLES 15 SP3 to SP4 to proceed.

It’s important to note that other issues can also occur during VM migration, such as the VM stopping responding, boot failures, or prolonged processes at zypper module repositories.

Cause¶

These general issues can often be traced back to two common culprits:

Security Tools Interference: Aggressive security tools, including antivirus software, intrusion detection systems, or compliance agents, can inadvertently disrupt the migration process. They might block critical operations, quarantine legitimate system files, or modify system files in a way that causes instability and conflicts with the migration tools.
Third-Party Repository Conflicts: Introducing third-party repositories to a SLES system can be convenient, but these repositories might contain packages that conflict with official SUSE packages. During a system upgrade, these conflicts can lead to dependency resolution failures, package corruption, or an inability to update core system components, causing further complications.

Resolution¶

To ensure a smooth and stable migration, it is strongly recommended to minimize external factors that could interfere with the process.

Disable Third-Party Repositories and Security Tools:

Disable Third-Party Repositories: Before starting the SUSE migration, disable all third-party repositories on the system. This action helps to prevent dependency conflicts, maintain consistency with official SUSE packages, and simplify troubleshooting by eliminating external variables. You can typically list and disable repositories using zypper lr and zypper modifyrepo -d <repo_name>.
Disable Security Tools: Temporarily disable any security tools, such as antivirus software or host-based firewalls, that might interfere with file system operations or network connections required by the migration. Remember to re-enable them after the migration is complete and the system is stable.

Taking these precautions helps to create a clean, controlled environment for the upgrade process. This reduces the risk of dependency conflicts, ensures system stability, and provides a smoother upgrade experience, making troubleshooting significantly easier if issues still arise.

Scenario 12: Successful Migration from SLES12 SP5 to SLES15 SP3, but SLES15 SP3 to SP6 Upgrade Fails with Error¶

You’ve successfully navigated the migration from SLES 12 SP5 to SLES 15 SP3, a significant achievement. However, when you attempt the subsequent upgrade from SLES 15 SP3 to SLES 15 SP6 using sudo zypper migration -v, the process fails. The error message points to a “Signature verification failed for repomd.xml” and “Can’t provide /repodata/repomd.xml” for the target SLES15-SP6-Updates repository, indicating a problem with repository metadata integrity and trust.

The detailed output during the zypper migration -v command might look like this, highlighting the signature verification failure:

[SUSE_Linux_Enterprise_Server_x86_64:SLE-Product-SLES15-SP6-Updates|plugin:/susecloud?credentials=SUSE_Linux_Enterprise_Server_x86_64&amp;amp;path=/repo/SUSE/Updates/SLE-Product-SLES/15-SP6/x86_64/update/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
- Can&amp;apos;t provide /repodata/repomd.xml


<message type="warning">Skipping repository &apos;SLE-Product-SLES15-SP6-Updates&apos; because of the above error.</message>
<message type="error">Some of the repositories have not been refreshed because of an error.</message>
<message type="info">Loading repository data...</message>
<message type="info">Reading installed packages...</message>

<search-result version="0.0">
<solvable-list>
<solvable status="installed" name="sle-module-basesystem" kind="product" edition="15.3-0" arch="x86_64" repository="(System Packages)"/>
</solvable-list>
</search-result>
</stream>

**Migration failed.**

Performing repository rollback...
Starting to sync system product activations to the server. This can take some time...
Rollback successful.
'/usr/lib/zypper/commands/zypper-migration' exited with status 1

This error clearly shows that the system is unable to trust the repository metadata due to a signature mismatch, preventing any further package operations. These details are also captured in /var/log/messages or /var/log/distro-migration.log.

Cause¶

This issue stems from a significant change implemented by SUSE midway through 2023. SUSE updated the GPG signing key for all SUSE Linux Enterprise 15 products, as well as products based on them (such as SUSE Enterprise Storage, SUSE Manager, and SUSE CaaSP). The new key is an RSA 4096-bit key. If your system has not been updated with this new signing key, it will fail to verify the signatures of the latest repository metadata, resulting in the “Signature verification failed” error and halting the migration.

Resolution¶

To resolve this, you need to import the new SUSE GPG public key into your system’s RPM database. This will allow your system to correctly verify the authenticity and integrity of the repository metadata, enabling the migration to proceed.

Verify the Existing Keys:
First, check which GPG public keys are currently installed on your system. This helps confirm whether the new key is indeed missing.
```
sudo rpm -q gpg-pubkey
```
You might see output similar to this, showing older keys:
```
gpg-pubkey-39db7c82-66c5d91a
gpg-pubkey-50a3dd1c-50f35137
```
Create a Repository Signing Key File:
Create a new file named repo-signing-key-sle-15.txt in your home directory (or any other convenient location) using a text editor like vi. This file will contain the new SUSE GPG public key.
```
sudo vi repo-signing-key-sle-15.txt
```

Add Key Contents and Save:
Paste the entire GPG public key block into the repo-signing-key-sle-15.txt file and save it. Ensure no characters are missed or altered.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.15 (GNU/Linux)

mQINBGPJSBwBEAC+sp2UJHVei0aAkvnEeeuRrIbzyWotRYuDgdWzS4V01alxFl97
ZPA6syyyZpITGP6fLP0AG0KipXABcYdaF7iFGKnhm6v5ExQ+Aft9SNaJmGqxwPng
2jHGo0ovbcOrvpix1INwPlxyxAaKfCtdH6kE9ZBzZXKHhDwTuBAyIJmvz5P4djxs
RFxryZ2wq2IbhT/eu5b+3QRdeOHhbP/K2ZA+jd4Ct6uSyEAV0n9D5rVrtKhYqzp7
zXPYntFW9IgEC/HisQ3TcDhKqK0xfxsQAYjsrvrbhc2O1sHWfhDEqV7W8yPrEbH2
NTWmQxiSf4ZEJsKOZa6TI4fOS89OPRRIC0Ec+mFWHHSfhGaiK0g59TSuBECke7jV
hgwLKa0WGzxhYaZ/dPxjke9MfHPIlCrwfH4tKsEY5Cy+GQWwt8s7J9lK1gEGz0c2
nLA4PBDCPqKB/+GEHkF+hyN1GHlhoY78iJ+c/QHyTv/DYOvS3jr5RaJYwKkBHS+0
5pBUGW6PANT6yoDGOGLaq7hJLdeAwW+qLSfFSxBOnjBrtBV4Pqj1kbzCKFBGgazF
UPhWOSRms9erkr4ltGtUPDJxna16uoTZaYkjn7fZ/3iTqVgnSC/sOJM9KpA1kFrg
5R1OdTzymu7OwH7cmPSn0Yyg1BlU3K8EYFRFfhKptcNzuwERIAdcY39QnQARAQAB
tChTVVNFIFBhY2thZ2UgU2lnbmluZyBLZXkgPGJ1aWxkQHN1c2UuZGU+iQI+BBMB
AgAoBQJjyUgcAhsDBQkHhM4ABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRD3
Twm8P6HWzozMD/9xq1D3I+YWyrKJJRhyX8O1x3oYwayo1Si8VaqHUHMx5vL4VGub
cCGieg6+9cwbGVVqh4f0wozrrllTgwXuepzivvwlQnZ/cfdjYwV961MTl2/+0JD3
Hv39ef78DSU7iq8Pa22MPbXiliRvm3YJEsBnPRxDnGdGKDvLXlwugmHwHQXUTUvm
XpipD19xgJ+FUKxbsHudiFBHAfvzmvckn2wsz6pIasAH8PoWFyyoYbGbffDBx17v
YHhkZODadeD9N5lyo/mNkjFjTgHSTDYuhsor2AkSe4ptyY6EWONGg8ezqLLqJgWj
KcI3o0dOf1dpIIubkbrnshul/tT5DHQrKqqPDu6zuloKOSdKBWwh2zDPGYVGmii6
E/YKw8+lgTBs4Xuz4IxPhD/mSjLrADjuObhZhwQuM71SkQlScX4NhEeWoWfBg1k2
2V7zU6lGodEx5QtmeMe3yhMsTUBn9ls9VR+Zr6N1rhcubDwDu5JLbbUyNBOiqDc9
yQbIOD9bBG+XTxzs2VsAFkKWuW8opSJIDQ1LDg9pKF10IjrSyb+ln4OuRwQK5LHy
mGllHiz1Feivf6//Tb63qgd3k8HtwdjeK5YuXM1LwnisIhfZuhKWm2gdzKCvdGsn
Y0bH1r5E/rCFhRii/iyCxZN/2KIg/dHo8BXoh5zvzJ1XZ/bgiDnWSkQvdA==
=umXA
-----END PGP PUBLIC KEY BLOCK-----

Import the Key:
Import the new GPG key from the created file into the RPM database. This action makes the key available for verifying package and repository signatures.
```
sudo rpm --import repo-signing-key-sle-15.txt
```
Determine if the Key is Imported:
Verify that the new GPG public key has been successfully imported by checking the installed keys again. You should now see an additional key in the output.
```
sudo rpm -q gpg-pubkey
```
The output should now include the new key, similar to:
```
gpg-pubkey-39db7c82-66c5d91a
gpg-pubkey-50a3dd1c-50f35137
gpg-pubkey-3fa1d6ce-63c9481c
```
The key gpg-pubkey-3fa1d6ce-63c9481c represents the newly imported SUSE Package Signing Key (build@suse.de).
Start the Migration:
With the new GPG key successfully imported, your system can now verify the integrity of the SUSE 15 SP6 repository metadata. Proceed to start the migration.
```
sudo zypper migration -v
```
The output should now indicate that all repositories have been refreshed successfully, and zypper will list the available migration paths, including to SLES 15 SP6. You can then select the desired migration.

The subsequent output will detail the migration process, including repository refreshes, package upgrades, and potential reboots, indicating a successful progression.
Verify Successful Migration:
After the migration process completes, you can verify its success by checking the exit status of the zypper migration command.
```
sudo echo $?
```
A return value of 0 indicates that the migration finished successfully. Any non-zero value signifies an issue. For detailed status and error messages, review /var/log/zypper.log.
```
0
```
Restart the VM:
Finally, restart the VM to apply all kernel and system-level changes.
```
sudo reboot
```
After this restart, your VM will be successfully migrated to SLES 15 SP6 and should function normally.

Next Steps¶

If, after following these detailed troubleshooting steps, your SLES migration issues persist, it is advisable to seek further assistance. Creating a support request with your cloud provider or SUSE support team is the next logical step. When submitting your request, ensure you attach a copy of the /var/log/distromigration.log file. This log contains invaluable diagnostic information that will help support engineers understand the precise nature of the failure and provide targeted solutions.

Third-Party Information Disclaimer: The third-party products discussed in this article are manufactured by companies independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

We hope this comprehensive guide has helped you navigate the challenges of SLES migration. Your feedback is valuable! If you’ve encountered specific SLES migration issues not covered here, or if you have alternative solutions, please share them in the comments below. Let’s learn and grow together as a community.

Computacionvinchi

SLES Migration: Solving Virtual Machine Issues for a Smooth Transition

Prerequisites for a Smooth SLES Migration¶

Checking the VM Generation Version¶

Scenario 1: Migration from SLES 12 to SLES 15 Succeeds, but Upgrade from SLES 15 SP1 to SP2 Fails¶

Cause¶

Resolution¶

Workaround¶

Scenario 2: Installing the “suse-migration-sles15-activation” Package Fails¶

Cause¶

Resolution¶

Scenario 3: After Upgrading from SLES 15 SP1 to SLES 15 SP2, Generation 2 VMs Don’t Restart After Being Stopped¶

Cause¶

Resolution¶

Scenario 4: Migration from SLES 15 to SLES 15 SP3 Fails¶

Cause¶

Resolution¶

Scenario 6: After Migration, SUSE Doesn’t Start by Using the Latest Kernel, and Registration Fails¶

Cause¶

Resolution¶

Scenario 7: Migration from SLES 12 SP5 to SLES 15 SP1 Fails Because of the regionService Directory Issue¶

Cause¶

Resolution¶

Scenario 8: Migration Fails Because of an Unknown Folder in the /etc/pki/trust/anchors Directory¶

Resolution¶

Scenario 9: SUSE Registration and Repositories Don’t Work After Migration¶

Resolution¶

Scenario 10: SLES 15 Migration from SP3 to SP4 Fails with Invalid Credentials and Repository Errors Occur¶

Cause¶

Resolution¶

Cause¶

Resolution¶

Scenario 12: Successful Migration from SLES12 SP5 to SLES15 SP3, but SLES15 SP3 to SP6 Upgrade Fails with Error¶

Cause¶

Resolution¶

Next Steps¶

Post a Comment