Release Notes #

SUSE Linux Enterprise Server 15 introduces many innovative changes compared to SUSE Linux Enterprise Server 12. The most important changes are listed below.

SUSE Linux Enterprise Server 15 SP5 introduces changes compared to SUSE Linux Enterprise Server 15 SP4. The most important changes are listed below:

The full list of changed packages compared to 15 SP4 can be seen at this URL:

The full list of changed modules compared to 15 SP4 can be seen at this URL:

To learn about supported features and limitations, refer to the following sections in this document:

Certain software delivered as part of SUSE Linux Enterprise Server may require an external contract. Check the support status of individual packages using the RPM metadata that can be viewed with rpm, zypper, or YaST.

Major packages and groups of packages affected by this are:

SUSE Linux Enterprise Server 15 SP5 (and the SUSE Linux Enterprise modules) includes the following software that is shipped only under a GNU AGPL software license:

SUSE Linux Enterprise Server 15 SP5 (and the SUSE Linux Enterprise modules) includes the following software that is shipped under multiple licenses that include a GNU AGPL software license:

The set of media has changed with 15 SP2. There still are two different installation media, but the way they can be used has changed:

There is a known issue with using guided partitioning to install SUSE Linux Enterprise Server on PowerPC architecture. The root filesystem needs more storage that the listed minimum. It is recommended to allocate at least 20 gigabytes.

Before starting the installation using yast.ssh, it is neccessary to set the environmental variable QT_XCB_GL_INTEGRATION to xcb_egl:

export QT_XCB_GL_INTEGRATION=xcb_egl

Previously, it was possible for data loss to occur due to the system not hibernating correctly.

In 15 SP5, a sanity check was introduced to prevent this. It works by removing the kernel resume parameter if it points to a non-existent device. However, that means a system would not use the hibernation data. To fix it, do the following:

Upgrading the system is only supported from the most recent patch level. Make sure the latest system updates are installed by either running zypper patch or by starting the YaST module Online Update. An upgrade on a system that is not fully patched may fail.

Skipping service packs during an upgrade is only supported if you have a Long Term Service Pack Support contract. Otherwise, you need to first upgrade to SLE 15 SP4 before upgrading to SLE 15 SP5.

SLE 12 is the last codestream that SMT (Subscription Management Tool) is available for.

When upgrading your OS installation to SLE 15, we recommend also upgrading from SMT to its replacement RMT (Repository Mirroring Tool). RMT provides the following functionality:

Note that unlike SMT, RMT does not support installations of SLE 11 and earlier.

For more feature comparison between RMT and SMT, see https://github.com/SUSE/rmt/blob/master/docs/smt_and_rmt.md.

For more information about RMT, also see the new RMT Guide at https://documentation.suse.com/sles/15-SP3/html/SLES-all/book-rmt.html.

SLE 15 SP4 introduces a new Python 3 Module, which includes the alternatively available development Python interpreter, formerly included in the Basesystem Module. This new module will allow for more flexibility for the lifecycle of the packages provided within it and a clean separation between the system and development interpreter.

As the python39 package was part of the Basesystem Module on SLE 15 SP3, the introduction of this new module will require some changes when migrating to SLE 15 SP5. If you are using python39 and migrate from SLE 15 SP3, you will have to add the Python 3 module after migration via SUSEConnect to receive updates for this alternative interpreter. Otherwise the package will remain orphaned and without security updates.

Packages inside this module can have differing support level and support lifecycle. For more information, see documentation.

Podman 4.x is a major release with 60 new features and more than 50 bug fixes compared to Podman 3. It also includes a complete rewrite of the network stack.

Podman 4.x brings a new container network stack based on Netavark, the new container network stack and Aardvark DNS server in addition to the existing container network interface (CNI) stack used by Podman 3.x . The new stack brings 3 important improvement:

To ensure that nothing break with this major change, the old CNI stack will remain the default on existing installations, while new installs will use Netavark.

New installations can opt to use CNI by explicitly specifying it via the containers.conf configuration file, using the network_backend field.

If you have run Podman 3.x before upgrading to Podman 4, Podman will continue to use CNI plugins as it had before. There is a marker in Podman’s local storage that indicates this. In order to begin using Podman 4, you need to destroy that marker with podman system reset. This will destroy the marker, all of the images, all of the networks, and all of the containers.

Warning

Before testing Podman 4 and the new network stack, you will have to destroy all your current containers, images, and networks. You must export/save any import containers or images on a private registry, or make sure that your Dockerfiles are available for rebuilding and scripts/playbooks/states to reapply any settings, regenerate secrets, etc.

Last but not least CNI will be deprecated from upstream at a future date: https://github.com/containers/podman/tree/main/cni

For a complete overview of the changes, please check out the upstream 4.0.0 but also 4.1.1, 4.2.0 and 4.3.0 to be informed about all the new features and changes.

Starting with SUSE Linux Enterprise 15 SP3, the rpm package in the suse/sle15 container image no longer supports the BDB back-end (based on Berkeley DB) and switches to the NDB back-end. Tools for scanning, diffing, and building container image using the rpm binary of the host for introspection can fail or return incorrect results if the host’s version of rpm does not recognize the NDB format.

To use such tools, make sure that the host supports reading NDB databases, such as hosts with SUSE Linux Enterprise 15 SP2 and later.

The nouveau driver is still considered experimental for Nvidia Turing and Ampere GPUs. Therefore it has been disabled by default on systems with these GPUs.

Instead of using the nouveau driver we recommend using Nvidia’s new openGPU driver. Install this driver by installing these following packages:

Then uncomment the options nvidia line in the /etc/modprobe.d/50-nvidia-default.conf file so that it looks like the following afterwards:

### Enable support on *all* Turing/Ampere GPUs: Alpha Quality!
options nvidia NVreg_OpenRmEnableUnsupportedGpus=1

If you prefer using nouveau driver anyway, add nouveau.force_probe=1 to your kernel boot parameters, and do not install the above openGPU package.

SLE 15 SP4 introduces a new Python 3 Module, which includes the alternatively available development Python interpreter, formerly included in the Basesystem Module. This new module will allow for more flexibility for the lifecycle of the packages provided within it and a clean separation between the system and development interpreter.

As the python39 package was part of the Basesystem Module on SLE 15 SP3, the introduction of this new module will require some changes when migrating to SLE 15 SP5. If you are using python39 and migrate from SLE 15 SP3, you will have to add the Python 3 module after migration via SUSEConnect to receive updates for this alternative interpreter. Otherwise the package will remain orphaned and without security updates.

Packages inside this module can have differing support level and support lifecycle. For more information, see documentation.

The following Java implementations are available in SUSE Linux Enterprise Server 15 SP5:

This table summarizes the various limits which exist in our recent kernels and utilities (if related) for SUSE Linux Enterprise Server 15 SP5.

¹ By default, the user space memory limit on the POWER architecture is 128 TiB. However, you can explicitly request mmaps up to 512 TiB.

² The total number of all processes and all threads on a system may not be higher than the "maximum number of processes".

Previously in kernel 5.14, it was possible to disable compression by passing an empty string instead of explicitly mentioning none or no.

In SLES 15 SP5, this behavior is changed to the more expected one. From kernel 5.14 onwards, empty string will reset the default setting instead of disabling compression.

The cpuid package has been added. It provides detailed information about the CPU. For more information see http://etallen.com/cpuid.html.

The TLS 1.0 and 1.1 standards have been superseded by TLS 1.2 and TLS 1.3. TLS 1.2 has been available for considerable time now.

SUSE Linux Enterprise Server packages using OpenSSL, GnuTLS, or Mozilla NSS already support TLS 1.3. We recommend no longer using TLS 1.0 and TLS 1.1, as SUSE plans to disable these protocols in a future service pack. However, not all packages, for example, Python, are TLS 1.3-enabled yet as this is an ongoing process.

A new rage-encryption package has been added. The package provides the rage executable. rage is an implementation of the age file encryption format using Rust.

This replaces gpg as the preferred tool over gpg for file encryption. The main reasons are that gpg has a history of security issues, and is well known for its complexity. In comparison, rage focuses on usability and security. It especially tries to make key handling as simple as handling SSH keys (essentially short lines of text), which it also supports.

For more information, see:

The previously used by-path policy had the following shortcomings:

To avoid the above problems, the persistent policy of dracut is now set to by-uuid.

SUSE Linux Enterprise was the first enterprise Linux distribution to support journaling file systems and logical volume managers in 2000. Later, we introduced XFS to Linux, which allows for reliable large-scale file systems, systems with heavy load, and multiple parallel reading and writing operations. With SUSE Linux Enterprise 12, we started using the copy-on-write file system Btrfs as the default for the operating system, to support system snapshots and rollback.

The following table lists the file systems supported by SUSE Linux Enterprise.

Support status: + supported / ‒ unsupported

¹ OCFS 2 is fully supported as part of the SUSE Linux Enterprise High Availability Extension.

² Btrfs is a copy-on-write file system. Instead of journaling changes before writing them in-place, it writes them to a new location and then links the new location in. Until the last write, the changes are not "committed". Because of the nature of the file system, quotas are implemented based on subvolumes (qgroups).

³ To extend an OCFS 2 file system, the cluster must be online but the file system itself must be unmounted.

⁴ The block size default varies with different host architectures. 64 KiB is used on POWER, 4 KiB on other systems. The actual size used can be checked with the command getconf PAGE_SIZE.

Additional notes

Maximum file size above can be larger than the file system’s actual size because of the use of sparse blocks. All standard file systems on SUSE Linux Enterprise Server have LFS, which gives a maximum file size of 2⁶³ bytes in theory.

The numbers in the table above assume that the file systems are using a 4 KiB block size which is the most common standard. When using different block sizes, the results are different.

In this document:

See also http://physics.nist.gov/cuu/Units/binary.html.

Some file system features are available in SUSE Linux Enterprise Server 15 SP5 but are not supported by SUSE. By default, the file system drivers in SUSE Linux Enterprise Server 15 SP5 will refuse mounting file systems that use unsupported features (in particular, in read-write mode). To enable unsupported features, set the module parameter allow_unsupported=1 in /etc/modprobe.d or write the value 1 to /sys/module/MODULE_NAME/parameters/allow_unsupported. However, note that setting this option will render your kernel and thus your system unsupported.

The following table lists supported and unsupported Btrfs features across multiple SLES versions.

Support status: + supported / ‒ unsupported

Among others, the following packages have been added to SUSE Package Hub:

The log level of the deprecation warnings regarding killmode=None have been reduced. Instead of warning, they are now logged at the debug log level.

The yast2-iscsi-client package no longer automatically installs open-iscsi and iscsiuio. The two packages need to be installed manually before using yast2-iscsi-client.

In SLE 15 SP5 you can search for packages both within and outside of currently enabled SLE modules using the following command:

zypper search-packages -d SEARCH_TERM

This command contacts the SCC and searches all modules for matching packages. This functionality makes it easier for administrators and system architects to find the software packages needed.

We increase the support from 288 up 768 VCPU per virtual Machine.

Xen has been updated to version 4.17:

QEMU has been updated to version 7.1:

For more information see the following:

Note: Deprecation notice

In previous versions, if no explicit image format was provided, some QEMU tools tried to guess the format of the image, and then process it accordingly. Because this feature is a potential source of security issues, it has been deprecated and removed. It is now necessary to explicitly specify the image format. For more information, see https://qemu-project.gitlab.io/qemu/about/removed-features.html#qemu-img-backing-file-without-format-removed-in-6-1.

libvirt has been updated to version 9.0.0:

For more information see the following:

There were the following improvements:

There were the following improvements:

There were the following improvements:

The installation of NVMe Over Fabrics (NVMe-oF) does not work with Logical Volume Management when the root Volume Group utilizes a storage pool consisting of multiple NVMe-oF disks, which necessitates discovery beyond the boot disk.

Added a pseries-wdt driver that exposes these hypercall-based watchdog timers to userspace via the Linux watchdog API.

Changed the ibmveth driver to implement a more efficient way of giving packets to the hypervisor for transmit. Instead of DMA mapping and unmapping every outgoing data buffer, the buffer is copied into a reusable DMA mapped buffer. Also implemented multiple transmit queues for parallel packet processing.

CPUs after hotplug events (CPU or vnic device): irqbalance daemon provides --banmod option so that IRQ affinities will be preserved with driver settings. But the irqbalance --banmod option is not working with vnic IRQs and this feature fixes the bug in the irqbalance daemon code.

Make use of the new PCI Load/Store instructions in the rdma-core package for increased performance.

This new feature utilizes SIMD instructions to accelerate the zlib CRC32 implementation, resulting in significant performance improvements for applications that rely heavily on zlib.

If you want to use IBM Secure Execution see https://www.ibm.com/docs/en/linux-on-systems?topic=execution-prerequisites-restrictions

The openCryptoki p11sak tool has been extended to manage Dilithium and Kyber keys.

Recent kernel releases provide support for the chacha20 cipher and the goal of this feature is to use z System SIMD instruction to accelerate the chacha20 implementation on IBM Z and LinuxONE.

Ensuring that all APQNs used by an openCryptoki ep11 token are configured with the same master key, if not print an error message and fail initialization.

zcrypt DD: exploitation support of new IBM Z crypto hardware by recognizing and supporting the CEX8 adapters.

Provides a tool to display CPACF usage counters from the IBM z16 and LinuxONE 4 Processor Activity Instrumentation Facility.

The openCryptoki EP11 token supports new vendor specific mechanisms for quantum safe ciphers (Dilithium and Kyber) supported by the CEX8S crypto adapter.

Support of a new function from EP11 7.2 by the openCryptoki EP11 token. Comprises the support of vendor-specific mechanisms for a key derivation function used with cryptocurrencies and Schnorr signatures.

Support for a new configuration option to restrict cryptographic functions/mechanisms.

For the EP11 and CCA tokens allow to configure expected master key verification pattern (MKVPs) configured in the crypto adapter(s) and upon generation of a new secure keys ensures that the MKVP of the generated key is equal to an expected MKVP.

Adds new -k parameter to icastats to display detailed counters to reflect security measures (key size/curve/hash size).

Eliminates implementations of SW fallback functions for RSA in libica.

Improves access control to crypto resources via device nodes, for example, for Docker containers by allowing to assign control domains to a device node created by zcryptctl.

In openCryptoki, support the new attribute CKA_DERIVE_TEMPLATE introduced with PKCS #11 v3.1.

Adds support for IBM-specific attributes and mechanisms to the PKCS11 client-server implementation of p11-kit.

Update of libica to fulfill FIPS 140-3 requirements.

Enables user of Linux on Z to use DASD volumes in a PPRC (Peer-to-Peer Remote Copy) relation like a normal DASD volume thereby enabling platform support along with improving user experience.

Enables a Linux on Z admin to prepare a Linux root/boot volume so that it can be started on a different system (site) or with different device IDs and parameters without manually changing the configuration.

Enables zipl to use an ECKD DASD for Secure Boot IPL and Dump.

Enables a Linux on Z admin to create a zipl configuration file that enables different kernel parameters depending on the IPL site.

Improves reliability and reduces downtime by using cooperative recovery strategies that allow the drivers to recover from error scenarios automatically (without intervention from userspace), and without going through a complete tear-down and subsequent re-init.

This feature enables zLinux running in an LPAR to use the Phisical Function (PF) that corresponds to the second oprt of a ConnectX-5/6 card even if the PF that corresponds to the first port is assigned to a different LPAR.

GISA (Guest Interruption State Area) is now supported for Secure Execution Guests. This allows the direct injection of interrupts into running VMs, which results in reduced processing overhead.

For improving performance, the interpretive execution of the PCI store and PCI load instructions are enabled. Further improvement is achieved by enabling the Adapter-Event-Notification Interpretation which enables customers to run PCI I/O intensive workloads in KVM guests. This feature also allows KVM guests to use the Shared Memory Communications - Direct (SMC-D) protocol.

This feature adds hotplug support, which allows to dynamically assign and remove crypto adapters to or from a running KVM guest. This additionally provides a tool to persistently define the configuration of crypto adapters and domains that are allowed for passthrough usage as well as the configuration of the matrix/vfio-ap devices to be passed through to avoid that customers have to reconfigure after every IPL.

These features implements dumps created in a way that can only be decrypted by the owner of the guest image and be used for problem determination hence mitigating the outcomes of situations where kdump hypervisor-initiated dumps are not helpful.

Provides attestation support, for example, for external frameworks, specific deployment models or potentially regulatory requirements.

This feature allows to specify a virtual CPU topology which can help to configure the guest for better performance.

This feature allows Secure Execution guests to use larger command lines.

Updated driverctl to version newer than 0.111 because the previous version did not allow to list persisted override definitions.

Displaying the original CCW device numbers for` vfio-ap` devices improves the usability of vfio-ccw device passthrough to KVM guests.

Supports the HW roadmap, full exploitation of NVMe on the IBM Z platform.

Support for the Crypto Compliance feature of the IBM z16 and LinuxONE 4 Processor-Activity-Instrumentation Facility.

Added new CPU-MF Counters for IBM z16 and LinuxONE 4.

Support for a new set of crypto performance counters of the IBM z16 and LinuxONE 4.

Includes distribution, release number, and detailed kernel version in CPI data to be displayed on the HMC.

kdump now has a configuration option called KDUMP_AUTO_RESIZE. This option makes the boot-time init script call kdumptool-calibrate --shrink. This performs the same reservation size estimate that kdumptool calibrate normally does and shrinks the memory reservation to the calculated value by writing to /sys/kernel/kexec_crash_size.

YaST now has an option to turn this run-time auto-detection on. The result will be a very large crashkernel= value (around half the RAM) passed to the kernel and the reservation is reduced during boot using the KDUMP_AUTO_RESIZE option.

The installer now supports PCI-attached networking devices.

Removed the ESCON entry from the menu because it is no longer supported by the YaST module for network configuration.