Hi Tobias. What is the salt version installed on the minion. It's better to check the output of: zypper se -s salt Regards, Victor On Mon, 2021-07-12 at 15:19 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi, after upgrading some SLES15 systems from SP1 to SP2 the service "salt-minion" of those systems don't work anymore although it still can get started. Uyuni release is 2020.11. The following channels are enabled - except the "perl channel" all channels are standard channels from SCC: 1 | SLES15-15-0 | No 2 | SLE-Module-Basesystem15-SP2-Pool for x86_64 | Yes 3 | SLE-Module-Basesystem15-SP2-Updates for x86_64 | Yes 4 | SLE-Module-Legacy15-SP2-Pool for x86_64 | Yes 5 | SLE-Module-Legacy15-SP2-Updates for x86_64 | Yes 6 | SLE-Module-Packagehub-Subpackages15-SP2-Pool for x86_64 | Yes 7 | SLE-Module-Packagehub-Subpackages15-SP2-Updates for x86_64 | Yes 8 | SLE-Module-Server-Applications15-SP2-Pool for x86_64 | Yes 9 | SLE-Module-Server-Applications15-SP2-Updates for x86_64 | Yes 10 | SLE-Module-Web-Scripting15-SP2-Pool for x86_64 | Yes 11 | SLE-Module-Web-Scripting15-SP2-Updates for x86_64 | Yes 12 | SLE-Product-SLES15-SP2-Pool for x86_64 | Yes 13 | SLE-Product-SLES15-SP2-Updates for x86_64 | Yes 14 | perl modules (SLE_15_SP2) | Yes 15 | SUSE-PackageHub-15-SP2-Backports-Pool for x86_64 | Yes 16 | SUSE-PackageHub-15-SP2-Pool for x86_64 | Yes /var/log/salt/minion shows multiple log entries like this one: ---------------------------------------------------------------------------- 2021-07-12 16:26:20,138 [salt.utils.decorators:714 ][WARNING ][7870] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-12 16:26:20,139 [salt.state :322 ][ERROR ][7870] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function ---------------------------------------------------------------------------- I played around with disabling several channels without any effect. Actually I have no clue which packets might be responsible for these exceptions. Maybe some Python experts have an idea about the reason of these exceptions. During update (by using Uyuni's "SP Migrate") there were some warnings: problem with installed package libyaml-0-2-0.2.5-27.1.x86_64 problem with installed package perl-gettext-1.07-322.1.x86_64 problem with installed package libyaml-0-2-0.2.5-27.1.x86_64 "Dry Run" runs successfully only if I mark "Allow Vendor Change". The real upgrade worked only with "zypper dup" at the client's CLI. Using "SP Migrate" for this task doesn't work - not even with "Allow Vendor Change". The upgrade is actually successful but without salt-minion Uyuni's WebGUI still show the old patch level. Any idea? Regards, Tobias Crefeld.