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:

Because the release of version 4.4 of SUSE Manager was dropped, there is no SUSE Manager Server 4.4 option available under the Available Extensions and Modules section during installation. See https://www.suse.com/releasenotes/x86_64/SUSE-MANAGER/4.3/index.html#_important_note for more information.

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 comes with a complete stack of Python 3.6 (interpreter, setuptools, wheel, pip plus hundreds of modules). Python 3.6 is fully supported by SUSE throught the complete lifecycle of SLE 15.

However, there are very few pip installable modules that are still compatible with 3.6 or older. Therefore, starting with SLE 15 SP4, SUSE introduced a new Python 3 Module. It includes additional modern Python interpreter (plus setuptool, wheel, pip and pypi support, but no additional modules). This new allows more flexibility in providing a fully supported more recent Python interpreter in SLE.

Packages within the Python 3 module can be installed alongside existing Python packages and they can coexist within the same system without impacting any ongoing Python 3.6 workloads.

In SLE 15 SP5 the Python 3 Module ships with Python 3.11.

In SLE 15 SP4, which originally shipped with Python 3.10, Python 3.11 packages have been added in addition to the existing Python 3.10 packages. If you are using Python 3.10 in SLE 15 SP4 make sure to update the packages from the Python 3 Module to version 3.11 before upgrading to SLE SP5.

SLE 15 SP3 was shipped with the alternative Python version 3.9 included in Basesystem Module.

Python 3.11 is compatible with versions 3.10 and 3.9. Code written in 3.9 or 3.10 should run without or with only minimal changes in 3.11.

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 comes with a complete stack of Python 3.6 (interpreter, setuptools, wheel, pip plus hundreds of modules). Python 3.6 is fully supported by SUSE throught the complete lifecycle of SLE 15.

However, there are very few pip installable modules that are still compatible with 3.6 or older. Therefore, starting with SLE 15 SP4, SUSE introduced a new Python 3 Module. It includes additional modern Python interpreter (plus setuptool, wheel, pip and pypi support, but no additional modules). This new allows more flexibility in providing a fully supported more recent Python interpreter in SLE.

Packages within the Python 3 module can be installed alongside existing Python packages and they can coexist within the same system without impacting any ongoing Python 3.6 workloads.

In SLE 15 SP5 the Python 3 Module ships with Python 3.11.

In SLE 15 SP4, which originally shipped with Python 3.10, Python 3.11 packages have been added in addition to the existing Python 3.10 packages. If you are using Python 3.10 in SLE 15 SP4 make sure to update the packages from the Python 3 Module to version 3.11 before upgrading to SLE SP5.

SLE 15 SP3 was shipped with the alternative Python version 3.9 included in Basesystem Module.

Python 3.11 is compatible with versions 3.10 and 3.9. Code written in 3.9 or 3.10 should run without or with only minimal changes in 3.11.

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.

SUSE Linux Enterprise Server for Arm 15 SP5 adds initial enablement for the NVIDIA Orin* SoC (T234), which is found on Jetson* AGX Orin, Jetson Orin NX and Jetson Orin Nano System-on-Modules (SoM).

Drivers for the integrated, NVIDIA Ampere microarchitecture-based Graphics Processor Unit (GPU) are not included (Section 8.4.2, “No graphics drivers on NVIDIA Jetson”).

A SUSE Linux Enterprise Server for Arm 15 SP4 maintenance update added partial enablement for the NVIDIA Grace* SoC (T241).

SUSE Linux Enterprise Server for Arm 15 SP5 adds further enablement for the NVIDIA Grace SoC.

This also covers the NVIDIA Grace Hopper* SoC with an integrated, Hopper microarchitecture-based Graphics Processor Unit (GPU). Drivers for this integrated GPU are not included (Section 8.4.1, “No graphics drivers on NVIDIA Grace Hopper”).

NVIDIA recommend to use kernel-64kb on NVIDIA Grace and Grace Hopper SoCs (Section 8.3, “64K page size kernel flavor is supported”).

The NVIDIA Grace Hopper* System-on-Chip contains an integrated, Hopper microarchitecture-based Graphics Processor Unit (GPU).

SUSE Linux Enterprise Server for Arm 15 SP5 maintenance updates currently provide packages nvidia-open-driver-G06-signed-kmp-default and kernel-firmware-nvidia-gspx-G06 in version 535.104.05, which does not yet enable NVIDIA Grace Hopper GH200.

Check for maintenance updates of those packages with version 545.29.02 or later, or contact the system vendor or chip vendor NVIDIA for whether third-party graphics drivers are available for SUSE Linux Enterprise Server for Arm 15 SP5.

Note: PCIe GPUs not affected

Discrete GPU cards with Hopper microarchitecture, such as NVIDIA H100, are already enabled in shipping package versions.

The NVIDIA* Tegra* System-on-Chip chipsets include an integrated Graphics Processor Unit (GPU).

SUSE Linux Enterprise Server for Arm 15 SP5 does not include graphics drivers for any of the NVIDIA Jetson*, NVIDIA IGX or NVIDIA DRIVE* platforms.

Contact the chip vendor NVIDIA for whether third-party graphics drivers are available for SUSE Linux Enterprise Server for Arm 15 SP5.

The NXP* Layerscape* LS1028A/LS1018A System-on-Chip contains an Arm* Mali*-DP500 Display Processor, whose output is connected to a DisplayPort* TX Controller (HDP-TX) based on Cadence* High Definition (HD) Display Intellectual Property (IP).

A Display Rendering Manager (DRM) driver for the Arm Mali-DP500 Display Processor is available as technology preview (Section 2.8.1.5, “mali-dp driver for Arm Mali Display Processors available”).

However, there was no HDP-TX physical-layer (PHY) controller driver ready yet. Therefore no graphics output will be available, for example, on the DisplayPort* connector of the NXP LS1028A Reference Design Board (RDB).

Contact the chip vendor NXP for whether third-party graphics drivers are available for SUSE Linux Enterprise Server for Arm 15 SP5.

Alternatively, contact your hardware vendor for whether a bootloader update is available that implements graphics output, allowing to instead use efifb framebuffer graphics in SUSE Linux Enterprise Server for Arm 15 SP5.

Note

The Vivante GC7000UL GPU driver (etnaviv) is available as a technology preview (Section 2.8.1.3, “etnaviv drivers for Vivante GPUs are available”).

The following packages in the Public Cloud module have been deprecated and will be removed in SUSE Linux Enterprise Server 15 SP6: