SUSE-RU-2026:1760-1: important: Recommended update for suse-migration-services
SLE-UPDATES
null at suse.de
Fri May 8 12:30:14 UTC 2026
# Recommended update for suse-migration-services
Announcement ID: SUSE-RU-2026:1760-1
Release Date: 2026-05-08T07:57:10Z
Rating: important
References:
* bsc#1258174
* bsc#1258710
Affected Products:
* Basesystem Module 15-SP7
* SUSE Linux Enterprise Desktop 15 SP7
* SUSE Linux Enterprise Real Time 15 SP7
* SUSE Linux Enterprise Server 15 SP7
* SUSE Linux Enterprise Server for SAP Applications 15 SP7
An update that has two fixes can now be installed.
## Description:
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.
## Patch Instructions:
To install this SUSE update use the SUSE recommended installation methods like
YaST online_update or "zypper patch".
Alternatively you can run the command listed for your product:
* Basesystem Module 15-SP7
zypper in -t patch SUSE-SLE-Module-Basesystem-15-SP7-2026-1760=1
## Package List:
* Basesystem Module 15-SP7 (noarch)
* python3-migration-2.1.34-150700.15.24.1
* suse-migration-scripts-2.1.34-150700.15.24.1
* suse-migration-pre-checks-2.1.34-150700.15.24.1
## References:
* https://bugzilla.suse.com/show_bug.cgi?id=1258174
* https://bugzilla.suse.com/show_bug.cgi?id=1258710
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.suse.com/pipermail/sle-updates/attachments/20260508/9a0b9b2f/attachment.htm>
More information about the sle-updates
mailing list