< back to search

gpp_maybe Recommended update for suse-migration-services
SUSE-SLE-Module-Basesystem-15-SP7-2026-1760

This update for suse-migration-services fixes the following issues: - Add explicit SLES15 migration target check Instead of falling back to the default with a misleading warning message, make sure to check for this target explicitly beforehand - Fix Zypper class command output handling The way zypper is called always redirects all output, stdout and stderr into the main log file. Because of that the variables self.output and self.error are always empty. This commit fixes the command call in a way that stdout and stderr are multiplexed such that the caller data can be captured by the python call and the data gets appended to the log file too. This commit also drops the unused and due to the redirection always empty self.error variable. For multiplexing the tee command gets used which impacts the returncode of the actual call. In order to get the correct exit code we use set -o pipefail. - Fix validation of zypper migration result Up to now the assumption was that any situation in which zypper migration cannot migrate the system returns with an error, meaning exit code != 0. However, this assumption is wrong. There are condition in which zypper migration only indicates a problem with a message saying 'No migration available' and the call return with a successful error code = 0. This causes big trouble for the DMS in a way that it continues running its services which all assumes the migration to the next major release was performed. It misleads readers of the log file into the wrong direction and the worst it causes modifications to the host system when it was not migrated. This commit makes sure that the migration stops and treats the above message as an error condition. - Add time info to backup directory So far only the date information was part of the backup directory. However, if multiple migration attempts happens on the same day, this would overwrite the data. - Fix migrate tool for container based migration The tool overwrites an eventually existing /etc/sle-migration-service.yml config file. This commit fixes it by using yq and inplace updates - Fix md device detection Fix detection of device mapper layered rootfs. Software raid disks are not found by findmnt if the actual rootfs is one or more layers down. This commit fixes the detection if we need to pass along the rd.auto cmdline option to let the boot process activate them. - Fix btrfs snapshot services Do not perform snapshot operations if the root filesystem is not btrfs based. - Fix lsm precheck Yet another test that doesn't restrict the scope of its runtime environment. - Fixed scope check for cpu_arch and check_ha The prechecks for cpu_arch and ha did not receive the value for the migration_system mode. As such these checks could not differentiate between being called on the host to upgrade or as part of the live migration system. This lead to unwanted check calls and invalid fail information as part of the migration log file - Fixed dataProvider setup in regionserverclnt.cfg In case of Azure the dataProvider information gets a device parameter added. This parameter must be added only once or not at all if it is already present. - Fixup import of certificates Only import if the file exists and is not a directory. We still assume that the file content of the pki trust directories matches certificates and not random non certificate files. - Fix consistency of regionserverclnt.cfg The DMS copies the contents of system-root/etc/regionserverclnt.cfg into the live migration system /etc/regionserverclnt.cfg. However, after the copy the update_regionsrv_setup() function modifies the contents of system-root/etc/regionserverclnt.cfg if the dataProvider is azuremetadata. This leads to different content of the file in system-root and the file in /. Whether or not this is causing a problem for the migration is unclear, but in any case having the file twice with different content during the DMS runtime is a bug. (bsc#1258710) - Fix setup of migration target for pre-check The check sending a request to the SCC offline migrations API requires a proper migration target name. This name is constructed from the installed migration live image package name which follows a strict naming policy. For SAP targets the code missed the detection path. This commit fixes it. (bsc#1258174) - Make sure to fallback to scc.suse.com Systems that are not providing /etc/SUSEConnect should fallback to the default registration server which is https://scc.suse.com - Switch reboot default In light of recent issues reported with soft reboot we are chaning the reboot method to a full reboot. This is intended to reduce the number of requests we receive to investigate boot issues. - Move default container to official devel project - Fixed disk device name passed to azuremetadata When setting the disk device name in the regionserverclnt.cfg for azure we used the unix device node, e.g /dev/sda. This is not a persistent device name and may change. This commit uses the by-id representation for the disk device from udev which is not expected to change. - Fix SLES SAP migration 12 - 15 in public clouds Workaround an issue in the SLE15 SP4 based live migration system used for SAP migrations only. The zypper version on SLE15 SP4 is too old and does not support --gpg-auto-import-keys. This workaround patches the DMS code to not use this option. As soon as the SAP migration live image can switch to a newer SP, this workaround can hopefully be removed again. - Fix python compatibility on latest zypper change Unfortunately the code has to comply with the oldest distribution migration that we support. This includes compatibility with the python 3.6 interpreter (SLE15). The latest change on the Zypper class introduced a TypeError and broke the migration. This commit fixes it. It should be safe to move the DMS code base to python 3.11 as the oldest migration live image is based on SLE15-SP4 which is the first target that has a python 3.11 stack. However, I hesitate to add this change now as we already have enough other problems with regards to the migration. As such it shouldn't be a problem to stay python 3.6 compatible for the moment.

  • Release Date
    May 8 2026
  • References
    Bugzilla: 1258710, 1258174
  • Type
    recommended
  • Severity
    important

cloud_download Downloads

Basesystem Module 15.7 aarch64
Basesystem Module 15.7 ppc64le
Basesystem Module 15.7 x86_64
Basesystem Module 15.7 s390x