DMS (Distribution Migration System) Migration failed
This document (000020634) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 12
Situation
zypper multiple kernel feature
One possible cause of migration failure is due to the zypper multiple kernel feature being enabled, which leaves multiple kernels on the system. Normally this is correct and acceptable, however, due to a kernel RPM script change in certain kernel packages, this is causing a conflict and the older kernels are unable to be removed. The DMS procedure may fail completely or partially, depending on where in the process the old/previous kernel is removed.
Look in the log "/var/log/distro_migration.log" for "Migration failed".
These types of errors are seen when the kernel is being removed:
( 928/1204) Removing kernel-default-4.12.14-122.106.1.x86_64 [....error] Removal of (24555)kernel-default-4.12.14-122.106.1.x86_64(@System) failed: Error: Subprocess failed. Error: RPM failed: /var/tmp/rpm-tmp.VECCEi: line 1: /usr/lib/module-init-tools/kernel-scriptlets/rpm-preun: No such file or directory error: %preun(kernel-default-4.12.14-122.106.1.x86_64) scriptlet failed, exit status 127 error: kernel-default-4.12.14-122.106.1.x86_64: erase failed Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans scripts skipped while aborting: coreutils-8.29-2.12.x86_64.rpm kernel-firmware-20200107-3.15.1.noarch.rpm systemd-presets-common-SUSE-15-6.10.noarch.rpm kmod-25-6.7.1.x86_64.rpm blog-2.18-4.11.x86_64.rpm systemd-presets-branding-SLE-15.1-20.5.1.noarch.rpm ca-certificates-mozilla-2.44-4.29.1.noarch.rpm kbd-2.0.4-8.3.1.x86_64.rpm dbus-1-1.12.2-8.3.1.x86_64.rpm udev-234-24.64.1.x86_64.rpm rpm-4.14.1-10.19.8.x86_64.rpm google-opensans-fonts-1.0-1.21.noarch.rpm dejavu-fonts-2.37-1.21.noarch.rpm dracut-044.2-18.70.1.x86_64.rpm python2-chardet-3.0.4-3.23.noarch.rpm yp-tools-4.2.2-3.16.x86_64.rpm libopenblas_pthreads0-0.2.20-11.11.x86_64.rpm sg3_utils-1.44~763+19.1ed0757-9.3.1.x86_64.rpm haveged-1.9.2-6.1.x86_64.rpm thin-provisioning-tools-0.7.5-1.24.x86_64.rpm python2-setuptools-40.5.0-6.3.1.noarch.rpm crash-kmp-default-7.2.1_k4.12.14_197.56-9.7.1.x86_64.rpm Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. Migration failed. The migration to the new service pack has failed. The system is most likely in an inconsistent state.
This may leave the system not migrated at all, or only partially migrated.
If most updates are installed, then a simple "zypper update" after a reboot should finalize the migration.
Incorrect product defined in /etc/sle-migration-service.yml
If for example the base product is SLES_SAP but one defined SLES in /etc/sle-migration-service.yml, for example this way:
migration_product: 'SLES/15.1/x86_64'
the migration will fail and one can see similar output in /var/log/distro_migration.log:
Calling: ['chroot', '/system-root', 'SUSEConnect', '--list-extensions'] command 'zypper --disable-repositories --xmlout --non-interactive products -i' failed Error: zypper returned (7) with '<?xml version='1.0'?> <stream> <message type="error">System management is locked by the application with pid 1781 (zypper).
SUSEConnect timeout
SUSEConnect failed to connect to scc.suse.com.
Calling: ['mount', '--bind', '/system-root/usr/lib/zypp/plugins/services', '/usr/lib/zypp/plugins/services'] Calling: ['chroot', '/system-root', 'SUSEConnect', '--list-extensions'] SUSEConnect error: Errno::ETIMEDOUT: Connection timed out - connect(2) for "scc.suse.com" port 443
When changing the server registration to use SCC, the server keeps partially reverting back to susecloud.net after a reboot
DMS fails
Resolution
zypper multiple kernel feature
Engineering is aware of this situation and is investigating a resolution.
Until then the workaround is to manually remove extra RPMs before starting the DMS migration.
If the system is still showing as SLES12-SP5, then all kernel RPMs except the current running kernel will need to be removed prior to running the DMS procedure again.
To do that, check for current installed kernels:
rpm -qa|grep kernel-default
Check the current running kernel:
uname -r
Then remove any kernels that are older.
Here is an example:
rpm -qa|grep kernel-default kernel-default-4.12.14-122.110.1.x86_64 kernel-default-4.12.14-122.83.1.x86_64 uname -r 4.12.14-122.110-default
The old kernel version is "kernel-default-4.12.14-122.83.1.x86_64".
Remove the old kernel:
zypper rm kernel-default-4.12.14-122.83.1
If in doubt, contact SUSE Support for further assistance.
https://www.suse.com/support/kb/doc/?id=000019452
Incorrect product defined in /etc/sle-migration-service.yml
Correcting the migration product should make the migration work as expected. The migration_product must be 'SLES/15.1/x86_64' for SLES migrations and 'SLES_SAP/15.1/x86_64' for SLES_SAP. Changing the product target from the 15-SP1 release is not officially supported.SUSEConnect timeout
The solution could vary depending on cause, but a known issue related to customer need to use HTTP proxy to connect to the internet.
Engineering is aware of incomplete handling of /etc/sysconfig/proxy inside DMS environment. The workaround is to create a shell wrapper for /usr/sbin/SUSEConnect which would explicitly define http_proxy environment variables later passed to original SUSEConnect script.
When changing the server registration to use SCC, the server keeps partially reverting back to susecloud.net after a reboot
Remove the cloudregister cache files and delete any 'susecloud.net' entries from /etc/hosts. Commenting the entry is not sufficient. The entries must be deleted.
# Remove cloudregister cache files rm -rf /var/cache/cloudregister/*
Cause
zypper multiple kernel feature
Due to a kernel RPM script change in certain kernel packages, this is causing a conflict and the older kernels are unable to be removed.
Incorrect product defined in /etc/sle-migration-service.yml
It is a misconfiguration since by default no 'migration_product' is set, and the migration will use that product as found in '/etc/products.d/baseproduct'.SUSEConnect timeout
As for proxy related issue, since SUSEConnect is called from a script started via a systemd unit, no shell proxy related environment values are available by default because the systemd unit does not use 'EnvironmentFile=-/etc/sysconfig/proxy' setting.When changing the server registration to use SCC, the server keeps partially reverting back to susecloud.net after a reboot
The cloudregister cache is still populatedAdditional Information
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000020634
- Creation Date: 05-Apr-2022
- Modified Date:25-Sep-2023
-
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Server for SAP Applications
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com