Troubleshooting Custom Channel with Conflicting Packages
When setting up a custom channel with conflicting packages features such as creating a bootstrap repository can result in undefined behavior and make registering clients fail.
For example, conflicting packages with higher version numbers could be
included into the bootstrap repository.
Such packages (for example, python3-zmq
or zeromq
) may corrupt the creation of the bootstrap repository or cause issues during bootstrap of the client.
When the custom channel (for example, an EPEL channel) is added below the parent vendor channel, issues with conflicting packages cannot be solved directly. The way how to solve this is to separate the custom channel from the vendor channel. The custom channel needs to be created in a separate tree. In case that the custom channel needs to be delivered as a child, such environemnt can be created using Content Lifecycle Management (CLM). Sources in a CLM project can be added there from different trees. Using such an approach, the custom channel stays below the parent within the built environment. However, the vendor channel tree stays without the custom channel and the bootstrap repository. Then registering clients works correctly.
When the custom channel with the conflicting packages (salt, zeromq, and so on) is created as a child channel, following steps can help to avoid the issue:
-
Remove the custom channel as a child channel from parent channel. For more information, see administration:custom-channels.adoc#_manage_custom_channels.
-
Create the custom channel in a separate tree. For more information, see administration:custom-channels.adoc#_creating_custom_channels_and_repositories.
-
To get the custom channel as a child channel within Content Lifecycle Management (CLM):
-
In the SUSE Manager Web UI, navigate to Content Lifecycle, and click Create Project. Enter
Name
andLabel
. -
Attach Source to the project. Use the needed vendor channels and the custom channel. (sharing example using CentOS8)
-
Add environment into the Project. For example, use CentOS8.
-
To build the environment click the Build button. This creates an environment with vendor and custom channels that can be associated with an activation key and used to bootstrap the client.
-
-
Important note: In the CLM project, it is recommend to add a filter, which excludes the problematic or conflicting packages. Otherwise the conflicting packages with higher version numbers would be installed during the update of the client. For more information about filtering, see administration:content-lifecycle-examples.adoc#exclude-higher-kernel-version.
-
To get the latest patches into the CLM environment (with vendor and custom channel), click the Build button in the project. This is needed to re-built the environment.
-
For more information about CLM, see Content Lifecycle Management.
-
Using the Extra Packages for Enterprise Linux (EPEL) directly on Red Hat Enterprise Linux clients (or compatible: SUSE Liberty Linux, CentOS, Oracle Linux, etc.) will install the Salt packages from EPEL, which miss some features available in the SUSE Manager-provided Salt packages. This is especially important because it will result in a bootstrap repository containing the non-SUSE Salt packages. Therefore, this is an unsupported scenario. If you need to enable the EPEL repository, make sure you filter out the Salt packages from EPEL in advance (for example, by removing the Salt packages in . |