Installing Program Temporary Fixes (PTFs) from SUSEConnect repositories

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

Environment

SUSE Linux Enterprise Desktop 15 and later
SUSE Linux Enterprise Server 15 and later
SUSE Linux Enterprise Server 12 SP2 and later

Situation

SUSE Technical Services provides a set of packages to fix a given situation (so called PTF – Program Temporary Fix).
The installation and handling of this type of package is described in TID 000018572 – Best practice for applying Program Temporary Fixes and generally involves downloading the RPM packages from ptf.suse.com, distributing the files to the affected systems and installing them.

These PTFs can now be made available directly to the affected systems with the use of PTF repositories. These repositories are similar to the ones used do distribute software updates, with the difference being that PTF repositories are available only for a specific SUSE Customer Center (SCC) account and the software addresses only one specific defect.

This is currently available as a technology preview for systems connected directly to SCC or via RMT and currently does not replace the existing process for delivering PTFs.

Resolution

Discovering and enabling the repository

Once SUSE makes a software correction available to a specific SCC account and product, a new repository will be listed on systems registered with SUSEConnect or YaST. In order to register a system, see TID 000018564 – How to register SLES using the SUSEConnect command line tool.

First, zypper and the software update tools must be updated to the latest available patch:

demo:/ # zypper patch --updatestack-only

Then ensure the system has the latest list of repositories by refreshing the services:

demo:/ # zypper refresh-services -f
Refreshing service 'Basesystem_Module_15_SP3_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP3_x86_64'.
Refreshing service 'Server_Applications_Module_15_SP3_x86_64'.
All services have been refreshed.

The list of repositories should then look like:

demo:/ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias | Name | Enabled | GPG Check | Refresh
---+-------------------------------------------------------------------------------------------------+--------------------------------------------------------+---------+-----------+--------
1 | Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Debuginfo-Pool | SLE-Module-Basesystem15-SP3-Debuginfo-Pool | No | ---- | ----
2 | Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Debuginfo-Updates | SLE-Module-Basesystem15-SP3-Debuginfo-Updates | No | ---- | ----
3 | Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Pool | SLE-Module-Basesystem15-SP3-Pool | Yes | (r ) Yes | No
4 | Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Source-Pool | SLE-Module-Basesystem15-SP3-Source-Pool | No | ---- | ----
5 | Basesystem_Module_15_SP3_x86_64:SLE-Module-Basesystem15-SP3-Updates | SLE-Module-Basesystem15-SP3-Updates | Yes | (r ) Yes | Yes
6 | SLE_BCI | SLE_BCI | Yes | (r ) Yes | No
7 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64 | PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64 | No | ---- | ----
8 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:SLE-Product-SLES15-SP3-Debuginfo-Pool | SLE-Product-SLES15-SP3-Debuginfo-Pool | No | ---- | ----
9 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:SLE-Product-SLES15-SP3-Debuginfo-Updates | SLE-Product-SLES15-SP3-Debuginfo-Updates | No | ---- | ----
10 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:SLE-Product-SLES15-SP3-Pool | SLE-Product-SLES15-SP3-Pool | Yes | (r ) Yes | No
11 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:SLE-Product-SLES15-SP3-Source-Pool | SLE-Product-SLES15-SP3-Source-Pool | No | ---- | ----
12 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:SLE-Product-SLES15-SP3-Updates | SLE-Product-SLES15-SP3-Updates | Yes | (r ) Yes | Yes
13 | Server_Applications_Module_15_SP3_x86_64:SLE-Module-Server-Applications15-SP3-Debuginfo-Pool | SLE-Module-Server-Applications15-SP3-Debuginfo-Pool | No | ---- | ----
14 | Server_Applications_Module_15_SP3_x86_64:SLE-Module-Server-Applications15-SP3-Debuginfo-Updates | SLE-Module-Server-Applications15-SP3-Debuginfo-Updates | No | ---- | ----
15 | Server_Applications_Module_15_SP3_x86_64:SLE-Module-Server-Applications15-SP3-Pool | SLE-Module-Server-Applications15-SP3-Pool | Yes | (r ) Yes | No
16 | Server_Applications_Module_15_SP3_x86_64:SLE-Module-Server-Applications15-SP3-Source-Pool | SLE-Module-Server-Applications15-SP3-Source-Pool | No | ---- | ----
17 | Server_Applications_Module_15_SP3_x86_64:SLE-Module-Server-Applications15-SP3-Updates | SLE-Module-Server-Applications15-SP3-Updates | Yes | (r ) Yes | Yes

In this system, the PTFs repository is:

7 | SUSE_Linux_Enterprise_Server_15_SP3_x86_64:PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64 | PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64 | No | ---- | ----

PTF repositories come disabled by default, so they must be enabled on the systems that need the PTFs installed:

demo:/ # zypper modifyrepo --enable 7
Repository 'SUSE_Linux_Enterprise_Server_15_SP3_x86_64:PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64' has been successfully enabled.

After enabling, the SUSE PTF key (which for security reasons by default is not included) must be added to the RPM database and the repository must be refreshed:

demo:/ # rpm --import /usr/lib/rpm/gnupg/keys/suse_ptf_key.asc
demo:/ # zypper refresh 7
Retrieving repository 'PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64' metadata -------------------------------------------------------------------[\]
Retrieving repository 'PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64' metadata .................................................................[done]
Building repository 'PTFs for SUSE Linux Enterprise Server 15 SP3 x86_64' cache ......................................................................[done]
Specified repositories have been refreshed.
With the repository enabled and refreshed, it is then possible to inspect what fixes are available for the system. This can be done by searching for packages with the prefix ptf-:
# zypper search -r 7 ptf-
Loading repository data...
Reading installed packages...

S | Name | Summary | Type
--+-----------+---------------------------+-----------
  | ptf-22333 | PTF for salt-minion addressing bsc#8891133, case 0328392 | package
  | ptf-22333 | PTF for salt-minion addressing bsc#8891133, case 0328392 | srcpackage

Understanding PTF packages

PTF packages are installed via a proxy package and are named ptf-xxxxxx. They will depend on the correct version of the package that is known to include the correction in the software. This type of package

  • cannot be installed accidentally (ie. zypper update will never suggest installing them),
  • cannot be removed accidentally (ie. a newer package version will not replace the PTF one, unless the user makes it explicitly on the zypper command line),
  • is only updated when the newer version is known to address the specific issue addressed first by the PTF,
  • updates only packages already installed on the system (a software that is split in multiple packages will have only the packages currently installed on the system being replaced).

The correct ID of the package will be provided by SUSE Support during the course of the support case investigation, along with instruction on how to deploy/restart the affected services.

Installing the PTF

Once the PTF identifier is known (ptf-22333 in this example) , one can install it with zypper install :

demo:/ # zypper install ptf-22333
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
ptf-22333

The following 3 packages are going to be upgraded:
python3-salt salt salt-minion

The following 4 packages have no support information from their vendor:
ptf-22333 python3-salt salt salt-minion

3 packages to upgrade, 1 new.
Overall download size: 8.5 MiB. Already cached: 0 B. After the operation, additional 1.6 KiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving package ptf-22333-1-0.noarch (1/4), 9.7 KiB ( 1.6 KiB unpacked)
Retrieving: ptf-22333-1-0.noarch.rpm ..........................................................................................................................[done]
Retrieving package salt-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64 (2/4), 155.9 KiB ( 26.8 KiB unpacked)
Retrieving: salt-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64.rpm .....................................................................................................[done]
Retrieving package python3-salt-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64 (3/4), 8.2 MiB ( 44.7 MiB unpacked)
Retrieving: python3-salt-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64.rpm ..................................................................................[done (1.8 MiB/s)]
Retrieving package salt-minion-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64 (4/4), 156.2 KiB ( 40.3 KiB unpacked)
Retrieving: salt-minion-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64.rpm ..................................................................................[done (156.2 KiB/s)]

Checking for file conflicts: .....................................................................................................................................[done]
(1/4) Installing: ptf-22333-1-0.noarch ...........................................................................................................................[done]
(2/4) Installing: salt-3002.2-8.41.8.1.22333.0.PTF.1047068.x86_64 ......................................................................................................[done]

Notice above that ptf-22333 will then include the packages that actual carry the correction. In the example above it was python3-salt, salt and salt-minion.

After PTF installation

Once a PTF is confirmed to address the reported issue, the updated package will be tracked for inclusion into a future maintenance update before being widely distributed as an regular maintenance update in the update repositories.

When this regular update with the fix is released, an updated version of the PTF will also be released into the account-specific PTF repository. The updated PTF will remove the strict dependencies and allow updates to be installed again.

Running zypper patch will then automatically install the latest maintenance update:

# zypper patch
Reading installed packages...
Resolving package dependencies...

The following 4 packages are going to be upgraded:
  ptf-22333 python3-salt salt salt-minion

The following 4 NEW patches are going to be installed:
  SUSE-SLE-Module-Basesystem-15-SP3-2021-2668 SUSE-SLE-Module-Basesystem-15-SP3-2021-3161 SUSE-SLE-Module-Basesystem-15-SP3-2021-3557 SUSE-SLE-Module-Basesystem-15-SP3-2021-3922

The following package has no support information from its vendor:
  ptf-22333

4 packages to upgrade.
Overall download size: 8.7 MiB. Already cached: 0 B. After the operation, additional 38.6 KiB will be used.

    Note: Package manager restart required. (Run this command once again after the update stack got updated)
Continue? [y/n/v/...? shows all options] (y):

Understanding conflicts

A ptf-xxxxx package will trigger a conflict if zypper patch is run and a patch from a maintenance update also updates the same package. This is a different behavior than zypper update, as zypper patch strives to have all patches installed.
# zypper patch
Problem: the installed ptf-22333-1-0.noarch requires '(salt-minion = 3002.2-8.41.8.1.22333.1.PTF.1047068 if salt-minion)', but this requirement cannot be provided 
 Solution 1: Following actions will be done: 
  deinstallation of ptf-22333-1-0.noarch 
  downgrade of salt-3002.2-8.41.8.1.22333.1.PTF.1047068.x86_64 to salt-3002.2-8.41.8.1.x86_64 
 Solution 2: do not install salt-minion-3002.2-8.41.8.1.x86_64 
 Solution 3: break ptf-22333-1-0.noarch by ignoring some of its dependencies
This is intended, as it is left to the administrator the choice on whether the patch and its importance has a higher priority than the bug being addressed by the PTF. In this case the administrator has to choose in the prompt whether the PTF must be de-installed from the system or not.

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:000020596
  • Creation Date: 23-Mar-2022
  • Modified Date:23-Mar-2022
    • SUSE Linux Enterprise Desktop
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center