Packages can't be updated in a RES 6 or RES 7 server managed by SUSE Manager. Error: Protected multilib versions

This document (7023024) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Manager 3

SUSE Manager 3.1

Situation

Errors might differ depending on the exact version of RES 6 or RES 7 and the packages installed on them. The problem is because of installed i686 rpm's. Examples of those, in the cases customers faced, were libstdc++ in RES 6.9 and compat-libstdc++ in RES 7.4. Other releases might be affected as well.

Salt minion logs for RES 7.4:

Protected multilib versions: libstdc++-4.8.5-16.el7_4.2.x86_64 != libstdc++-4.8.5-16.el7_4.1.i686
      Error: Protected multilib versions: libgcc-4.8.5-16.el7_4.2.x86_64 != libgcc-4.8.5-16.el7_4.1.i686
      Error: Protected multilib versions: systemd-libs-219-42.el7_4.10.x86_64 != systemd-libs-219-42.el7_4.7.i686
      Error: Protected multilib versions: libselinux-2.5-12.el7.x86_64 != libselinux-2.5-11.el7.i686

Salt minion logs for RES 6.9:

Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem.

Resolution

Fix: Latest patches for SUSE Manager should be installed (specific patches for this issue included salt and spacewalk-java, but all patches should be applied) first in the salt master (SUSE Manager), then salt-master service needs to be restarted, then the same operation is to be performed in the minions (RES clients). In this case, affected salt-minion(s) service(s) should be restarted.

Once packages are installed, it is needed to schedule a "Package profile update" (Minion page -> Software -> Update Package List) in order to refresh the software profile with all the installed package versions, and then selecting all package for upgrade should work successfully.

Workaround 1: Deselecting i686 packages lets everything be updated (also the i686 packages).

Workaround 2: Even if it is not recommended/supported to use yum or zypper inside SUSE Manager clients, "yum update" will fix the problem.

Cause

Salt and SUSE Manager are not handling properly installed packages that have the exact same name but a different architecture. This problem is not observed on SUSE systems because different names are used for different architectures (e.g. glibc / glibc-32bit on SUSE while glibc.i686 / glibc.x86_64 on RES).

When two packages with the same name but different architecture are installed on a minion, the package profile that is gathered from salt contains only one of the installed versions of those packages, therefore SUSE Manager only targets one of them during the upgrade (without setting any arch) and this makes yum fail trying to solve what package it should choose.

A patch for this issue was released involving fixes on the salt side and also restructuring the package profile handled by the Java side in order to make SUSE Manager fully aware of multiple installed versions of the packages and avoid this situation.

Additional 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.