<div class="container">
<h1>Recommended update for suse-migration-services</h1>
<table class="table table-striped table-bordered">
<tbody>
<tr>
<th>Announcement ID:</th>
<td>SUSE-RU-2026:1760-1</td>
</tr>
<tr>
<th>Release Date:</th>
<td>2026-05-08T07:57:10Z</td>
</tr>
<tr>
<th>Rating:</th>
<td>important</td>
</tr>
<tr>
<th>References:</th>
<td>
<ul>
<li style="display: inline;">
<a href="https://bugzilla.suse.com/show_bug.cgi?id=1258174">bsc#1258174</a>
</li>
<li style="display: inline;">
<a href="https://bugzilla.suse.com/show_bug.cgi?id=1258710">bsc#1258710</a>
</li>
</ul>
</td>
</tr>
<tr>
<th>Affected Products:</th>
<td>
<ul class="list-group">
<li class="list-group-item">Basesystem Module 15-SP7</li>
<li class="list-group-item">SUSE Linux Enterprise Desktop 15 SP7</li>
<li class="list-group-item">SUSE Linux Enterprise Real Time 15 SP7</li>
<li class="list-group-item">SUSE Linux Enterprise Server 15 SP7</li>
<li class="list-group-item">SUSE Linux Enterprise Server for SAP Applications 15 SP7</li>
</ul>
</td>
</tr>
</tbody>
</table>
<p>An update that has two fixes can now be installed.</p>
<h2>Description:</h2>
<p>This update for suse-migration-services fixes the following issues:</p>
<ul>
<li>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</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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</li>
<li>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.</li>
<li>Fix btrfs snapshot services
Do not perform snapshot operations if the root filesystem is
not btrfs based.</li>
<li>Fix lsm precheck
Yet another test that doesn't restrict the scope of its
runtime environment.</li>
<li>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</li>
<li>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.</li>
<li>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.</li>
<li>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)</li>
<li>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)</li>
<li>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</li>
<li>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.</li>
<li>Move default container to official devel project</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<h2>Patch Instructions:</h2>
<p>
To install this SUSE update use the SUSE recommended
installation methods like YaST online_update or "zypper patch".<br/>
Alternatively you can run the command listed for your product:
</p>
<ul class="list-group">
<li class="list-group-item">
Basesystem Module 15-SP7
<br/>
<code>zypper in -t patch SUSE-SLE-Module-Basesystem-15-SP7-2026-1760=1</code>
</li>
</ul>
<h2>Package List:</h2>
<ul>
<li>
Basesystem Module 15-SP7 (noarch)
<ul>
<li>python3-migration-2.1.34-150700.15.24.1</li>
<li>suse-migration-scripts-2.1.34-150700.15.24.1</li>
<li>suse-migration-pre-checks-2.1.34-150700.15.24.1</li>
</ul>
</li>
</ul>
<h2>References:</h2>
<ul>
<li>
<a href="https://bugzilla.suse.com/show_bug.cgi?id=1258174">https://bugzilla.suse.com/show_bug.cgi?id=1258174</a>
</li>
<li>
<a href="https://bugzilla.suse.com/show_bug.cgi?id=1258710">https://bugzilla.suse.com/show_bug.cgi?id=1258710</a>
</li>
</ul>
</div>