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 (prerelease) 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 (prerelease) (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 (prerelease) (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:

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 (prerelease), 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 (prerelease).

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 (prerelease). 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.

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 (prerelease). 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 (prerelease):

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

¹ 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 (prerelease), 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 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:

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 (prerelease) but are not supported by SUSE. By default, the file system drivers in SUSE Linux Enterprise Server 15 SP5 (prerelease) 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 (prerelease) 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: