Release Notes #

Modules are fully supported parts of SUSE Linux Enterprise Server with a different life cycle and update timeline. They are a set of packages, have a clearly defined scope and are delivered via an online channel only. Release notes for modules are contained in this document, see Section 9.5, “Modules”.

The following modules are available for SUSE Linux Enterprise Server 12 SP3:

* Module is not available for the AArch64 architecture.

For more information about the life cycle of packages contained in modules, see https://scc.suse.com/docs/lifecycle/sle/12/modules.

Extensions add extra functionality to the system and require their own registration key, usually at additional cost. Extensions are delivered via an online channel or physical media. In many cases, extensions have their own release notes documents that are available from https://www.suse.com/releasenotes/.

The following extensions are available for SUSE Linux Enterprise Server 12 SP3:

Additionally, there are the following extensions which are not covered by SUSE support agreements, available at no additional cost and without an extra registration key:

This sections lists derived and related products. In many cases, these products have their own release notes documents that are available from https://www.suse.com/releasenotes/.

On a default installation of SLES 12 SP3, there is no support for FCoE storage on systems that use Cavium or QLogic storage controllers with support for FCoE offload.

SUSE has created a kISO (Kernel Update ISO) which can be downloaded from https://drivers.suse.com/suse/installer-update/sle-12-sp3-x86_64/1.0/install-readme.html.

For more information about kISOs in general, see https://www.suse.com/communities/blog/kiso-kernel-update-iso/.

To install SLES, you need the installation media. If you also mirror the repositories, for example with SMT, this means that effectively you need to download all packages twice: once as a part of the media and additionally from the online repository.

For such scenarios, we provide packages named tftpboot-installation-* in the product repositories. These packages include an installer prepared for a network boot environment (PXE).

To use them, configure the PXE environment (DHCP, TFTP servers) and install the package for the respective product and architecture. Make sure to adjust the included configuration, so that the correct local URLs are passed to the installer.

This entry has appeared in a previous release notes document.

For some configurations with many network interfaces, it can take several hours until all network interfaces are initialized (see https://bugzilla.suse.com/show_bug.cgi?id=988157 (https://bugzilla.suse.com/show_bug.cgi?id=988157)). In such cases, the installation is blocked. SLE 12 SP1 and earlier did not offer a workaround for this behavior.

Starting with SLE 12 SP2, you can speed up interactive installations on systems with many network interfaces by configuring them via linuxrc. When a network interface is configured via linuxrc, YaST will not perform automatic DHCP configuration for any interface. Instead, YaST will continue to use the configuration from linuxrc.

To configure a particular interface via linuxrc, add the following to the boot command line before starting the installation:

ifcfg=eth0=dhcp

In the parameter, replace eth0 with the name of the appropriate network interface. The ifcfg option can be used multiple times.

Btrfs file system snapshots take up extra disk space. Previous versions of SLE did not check during installation whether a custom root file system size was appropriate for enabling snapshots.

For Btrfs root file systems with snapshotting, the SLE installer now verifies that the size of the file system at least matches the value of root_base from the product's control.xml. For example, for a default SLES installation, the root file system size is 12 GB. If the file system is smaller, the installer will display a warning - which can be ignored.

This entry has appeared in a previous release notes document.

SMT 12 comes with a new database schema and is standardized on the InnoDB database back-end.

In order to upgrade SMT 11 SPx to SMT 12, it is necessary that SMT 11 is configured against SCC (SUSE Customer Center) before initializing the upgrade of SLES and SMT to version 12 SP1 or newer. If the host is upgraded to SLES 12 SP1 or newer without switching to SCC first, the installed SMT instance will no longer work.

Only SMT 11 SP3 can be configured against SCC. Older versions need to be upgraded to version 11 SP3 first.

Whether the schema or database engine must be upgraded is checked during package upgrade and displayed as an update notification. Back up your database before doing the database upgrade. Both the schema and database engine upgrade are done by the utility /usr/bin/smt-schema-upgrade (can be called directly or via systemctl start smt-schema-upgrade) or are done automatically after smt.target restart (computer reboot or via systemctl restart smt.target). However, manual database tuning is required for optimal performance. For details, see https://mariadb.com/kb/en/mariadb/converting-tables-from-myisam-to-innodb/#non-index-issues (https://mariadb.com/kb/en/mariadb/converting-tables-from-myisam-to-innodb/#non-index-issues)

This entry has appeared in a previous release notes document.

Support for NCC (Novell Customer Center) was removed from SMT. SMT can still serve SLE 11 clients, but must be configured to receive updates from SCC.

Before migrating from SMT 11 SP3, SMT must be reconfigured against SCC. Migration from older versions of SMT is not possible.

This entry has appeared in a previous release notes document.

SUSE Linux Enterprise 12 and newer generally supports the installation with a linear LVM2 without a separate /boot partition, for example to use it with Btrfs as the root file system, to achieve full system snapshot and rollback.

However, this setup is only supported under the following conditions:

For a migration from an existing SUSE Linux Enterprise 11 system with LVM2 to SUSE Linux Enterprise 12 or newer, the /boot partition must be preserved.

For SUSE Linux Enterprise 12, there was a High Performance Computing subscription named "SUSE Linux Enterprise Server for HPC" (SLES for HPC). With SLE 15, this subscription does not exist anymore and has been replaced. The equivalent subscription is named "SUSE Linux Enterprise High Performance Computing" (SLE-HPC) and requires a different license key. Because of this requirement, a SLES for HPC 12 system will by default upgrade to a regular "SUSE Linux Enterprise Server".

To properly upgrade a SLES for HPC system to a SLE-HPC, the system needs to be converted to SLE-HPC first. SUSE provides a tool to simplify this conversion by performing the product conversion and switch to the SLE-HPC subscription. However, the tool does not perform the upgrade itself.

When run without extra parameters, the script assumes that the SLES for HPC subscription is valid and not expired. If the subscription has expired, you need to provide a valid registration key for SLE-HPC.

The script reads the current set of registered modules and extensions and after the system has been converted to SLE-HPC, it tries to add them again.

Important: Providing a Registration Key to the Conversion Script

The script cannot restore the previous registration state if the supplied registration key is incorrect or invalid.

For more information, see the man page switch_sles_sle-hpc(8) and README.SUSE.

When upgrading a SLES installation that includes freeradius-server and a non-standard /etc/raddb/radiusd.conf configuration file to SLES 12 SP3, make sure to manually merge the new radiusd.conf configuration section into the custom configuration before running the FreeRADIUS server.

In particular, pay attention to the parameter correct_escapes: The default behavior did not change, but the new default /etc/raddb/policy.d/filter only functions with the setting correct_escapes=true.

When the High Performance Computing module is selected, the following error message may be encountered during Migration from SLES 12 SP2 to SLES 12 SP3:

Can't get available migrations from server: SUSE::Connect::ApiError: The requested products '' are not activated on the system.
'/usr/lib/zypper/commands/zypper-migration' exited with status 1

The problem can be resolved by re-registering the HPC module using the following two commands:

These commands can also be performed before migration as a preventive measure.

If the package logrotate was installed or updated before systemd-presets-branding-SLE, automatic log rotation will be disabled after the upgrade to SLES 12 SP3.

Enable the logrotate systemd timer manually. To do so, run the following commands as root:

The SLES online migration process reports package conflicts when Live Patching is enabled and the kernel is being upgraded. This applies when crossing the boundary between two Service Packs.

To prevent the conflicts, before starting the migration, execute the following as a super user:

zypper rm $(rpm -qa kgraft-patch-*)

It is common that during the lifecycle of a system installation, registered extensions and modules are removed from the system without also deactivating them on the registration server.

To prevent errors and unexpected behavior during an online migration, the status of installed products needs to be checked before the migration to allow reinstalling or deactivating products.

A new step has been added to the current online migration workflow, it will check the registered products that are not currently installed in the system and allows:

This entry has appeared in a previous release notes document.

When performing a service pack migration, it is necessary to change the configuration on the registration server to provide access to the new repositories. If the migration process is interrupted or reverted (via restoring from a backup or snapshot), the information on the registration server is inconsistent with the status of the system. This may lead to you being prevented from accessing update repositories or to wrong repositories being used on the client.

When a rollback is done via Snapper, the system will notify the registration server to ensure access to the correct repositories is set up during the boot process. If the system was restored any other way or the communication with the registration server failed for any reason (for example, because the server was not accessible due to network issues), trigger the rollback on the client manually by calling snapper rollback.

We suggest always checking that the correct repositories are set up on the system, especially after refreshing the service using zypper ref -s.

This entry has appeared in a previous release notes document.

By default, systemd cleans temporary directories daily, and systemd does not honor sysconfig settings in /etc/sysconfig/cron such as TMP_DIRS_TO_CLEAR. Thus, it is needed to change sysconfig settings to avoid data loss or unwanted behavior.

When updating to SLE 12 or newer, the variables in /etc/sysconfig/cron will be automatically migrated into an appropriate systemd configuration (see /etc/tmpfiles.d/tmp.conf). The following variables are affected:

MAX_DAYS_IN_TMP
MAX_DAYS_IN_LONG_TMP
TMP_DIRS_TO_CLEAR
LONG_TMP_DIRS_TO_CLEAR
CLEAR_TMP_DIRS_AT_BOOTUP
OWNER_TO_KEEP_IN_TMP

A large amount of security issues was found and fixed in the Extended Berkeley Packet Filter (eBPF) code. To reduce the attack surface, its usage has been restricted to privileged users only.

Privileged users include root. Programs with the CAP_BPF capability in the newer versions of the Linux kernel can still use eBPF as-is.

To check the privileged state, you can check the value of the /proc/sys/kernel/unprivileged_bpf_disabled parameter. Value of 0 means "unprivileged enable", and value of 2 means "only privileged users enabled".

This setting can be changed by the root user:

As more functionality is added to hardware beginning with family 0x17, being able to track it requires an enhanced approach to MCA.

SLE 12 SP3 now supports AMD's Scalable MCA (SMCA). SMCA is a specification which enriches the error information logged by the hardware to allow for improved error handling, better diagnosability, and future scalability.

Starting with SLE 12 SP3, the update repositories supplying kernel patches that can be applied using kGraft are split up by Service Pack version. This allows for easier maintenance and reduces the chance of complications during Service Pack upgrades.

SLE 12 SP3 now contains support for Intel processors from the generation code-named Kaby Lake.

SLE 12 SP3 now supports Intel Xeon Phi coprocessors from the product line code-named Kights Landing.

SLE 12 SP3 now supports Device DAX. Device DAX is the device-centric analogue of File System DAX: It allows memory ranges to be allocated and mapped without need of an intervening file system. This feature can improve the performance of both KVM guests and databases like MSSQL using raw I/O access to NVDIMM.

SLE 12 SP3 includes a driver to enable Matrox G200eH3 graphics chips that will be used in HPE Gen10 servers.

SLE 12 SP3 includes an updated version of the HPE watchdog driver hpwdt to enable support for the upcoming HPE Gen10 Servers.

This entry has appeared in a previous release notes document.

The page cache is usually used to buffer reads and writes to files. It is also used to provide the pages which are mapped into userspace by a call to mmap. For block devices that are memory-like, the page cache pages would be unnecessary copies of the original storage.

The Direct Access (DAX) kernel code avoids the extra copy by directly reading from and writing to the storage device. For file mappings, the storage device is mapped directly into userspace. This functionality is implemented in the XFS and Ext4 file systems.

Non-volatile DIMMs can be "partitioned" into so-called namespaces which are then exposed as block devices by the Linux kernel. Each namespace can be configured in several modes. Although DAX functionality is available for file systems on top of namespaces in both raw or memory modes, SUSE does not support use of the DAX feature in file systems on top of raw mode namespaces as they have unexpected quirks and in future releases the feature is likely to go away completely.

This entry has appeared in a previous release notes document.

SELinux capabilities have been added to SUSE Linux Enterprise Server (in addition to other frameworks, such as AppArmor). While SELinux is not enabled by default, customers can run SELinux with SUSE Linux Enterprise Server if they choose to.

SELinux Enablement includes the following:

By enabling SELinux in our code base, we add community code to offer customers the option to use SELinux without replacing significant parts of the distribution.

SLES 12 SP3 has TPM support in the bootloader used on UEFI systems.

The original method for implementing Internationalized Domain Names was IDNA2003. This has been replaced by the IDNA2008 standard, the use of which is mandatory for some top-level domains.

The network utilities wget and curl have been updated to support IDNA2008 through the use of libidn2. This update also affects consumers of the libcurl library.

This entry has appeared in a previous release notes document.

The version of Samba shipped with SLE 12 GA and newer does not include support to operate as an Active Directory-style domain controller. This functionality is currently disabled, as it lacks integration with system-wide MIT Kerberos.

The GeoIP databases allow approximately geo-locating users by their IP address. In the past, the company MaxMind made such data available for free in its GeoLite Legacy databases. On January 2, 2019, MaxMind discontinued the GeoLite Legacy databases, now offering only the newer GeoLite2 databases for download. To comply with new data protection regulation, since December 30, 2019, GeoLite2 database users are required to comply with an additional usage license. This change means users now need to register for a MaxMind account and obtain a license key to download GeoLite2 databases. For more information about these changes, see the MaxMind blog (https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/).

SLES includes the GeoIP package of tools that are only compatible with GeoLite Legacy databases. As an update for SLES 12 SP3, we introduce the following new packages to deal with the changes to the GeoLite service:

Salt has been upgraded to upstream version 3000, plus a number of patches, backports and enhancements by SUSE. In particular, CVE-2020-11651 and CVE-2020-11652 fixes are included in our release.

As part of this upgrade, cryptography is now managed by the Python-M2Crypto library (which is itself based on the well-known OpenSSL library).

We intend to regularly upgrade Salt to more recent versions.

For more details about changes in your manually-created Salt states, see the Salt 3000 upstream release notes (https://docs.saltstack.com/en/latest/topics/releases/3000.html).

Salt 3000 is the last version of Salt which will support the old syntax of the cmd.run module.

In previous versions of SLE 12, when using yast clone_system, AutoYaST would always enable snapshots for Btrfs Volumes, regardless of whether they were enabled on the original system.

Starting with SLE 12 SP3, yast clone_system will now create an AutoYaST XML file that accurately reflects snapshot state of Btrfs volumes.

The button Register Extensions or Modules Again has been removed from the YaST registration module.

This option was redundant: It is still possible to register modules or extensions again with a different SCC account or using a different registration server (SCC or SMT).

Additionally, the option to filter out beta versions is now only visible if the server provides beta versions, otherwise the check box is hidden.

The YaST module for configuring an SSH server which was present in SLE 11, is not a part of SLE 12. It does not have any direct successor.

The module SSH Server only supported configuring a small subset of all SSH server capabilities. Therefore, the functionality of the module can be replaced by using a combination of 2 YaST modules: The /etc/sysconfig Editor and the Services Manager. This also applies to system configuration via AutoYaST.

Sudo has been updated from version 1.8.10p3 to 1.8.19p2. This update fixes many bugs and security vulnerabilities and also brings several enhancements. For more information, read the changelog file in /usr/share/doc/packages/sudo/NEWS.

In previous versions of SLE 12, when installing from a USB drive or external disk, the repository linking to the installation media was set to auto-refresh. This means that when the USB drive or the external disk had been removed and you are trying to work with YaST or Zypper, you were asked to insert the external medium again.

In the YaST version shipped with SLE 12 SP3, we have changed the default auto-refresh status for local repositories (USB drives, hard disks or dir://) to off which avoids checking the now usually unnecessary repository.

Normally, the snapper command line tool uses DBus to connect to snapperd which does most of the actual work. This allows non-root users to work with Snapper.

However, there are situations when using DBus is not possible, for example, when chrooted on the rescue system or when DBus itself is broken after an update. This can limit the usefulness of Snapper as a disaster recovery tool. Therefore, some Snapper commands already supported the --no-dbus option, bypassing DBus and snapperd.

In the version of Snapper shipped with SLE 12 SP3, all Snapper commands support the --no-dbus option.

The blogd boot log daemon (package blog and blog-plymouth) can be used as a replacement for Plymouth in situations where a splash screen or usage of a frame buffer is unwanted. blogd is also a Plymouth agent. That means, it can handle requests for a password prompt by the system password service of systemd.

The blogd daemon writes out boot log messages to every terminal device used for /dev/console and to the log file /var/log/boot.log. When halting or rebooting the system, it moves the log file to /var/log/boot.old and appends all log messages up to the point at which the file systems becomes unavailable.

This entry has appeared in a previous release notes document.

ntp was updated to version 4.2.8.

Name resolution for the affected hosts works otherwise.

The meaning of some parameters for the sntp command-line tool have changed or have been dropped, for example sntp -s is now sntp -S. Please review any sntp usage in your own scripts for required changes.

After having been deprecated for several years, ntpdc is now disabled by default for security reasons. It can be re-enabled by adding the line enable mode7 to /etc/ntp.conf, but preferably ntpq should be used instead.

In the past, YaST supported setting a high-memory and low-memory amounts for the kernel parameter crashkernel only from the ncurses or Qt interfaces.

You can now set these memory amounts on the command line too. To do so, use, for example, yast kdump startup enable alloc_mem=256,768. The first number represents the low-memory amount, the second number represents the high-memory amount. Therefore, the example is equivalent to setting crashkernel=256,low crashkernel=768,high on the kernel command line.

With SLE 12 SP3, it is possible to configure Salt clients using AutoYaST. To use this feature, you need the package salt-minion which is not available in the standard SLES product. However, you can install this dependency from the SLE Module Advanced Systems Management.

The zypper option --plus-content was enhanced to allow specifying disabled repositories by name or alias also. Additionally, it can now be used with the zypper refresh command, to refresh either specified or all disabled repositories without the need to enable them.

In the past, the user interface for iSCSI authentication offered by YaST was not optimal. Additionally, not every option was explained in the help.

In SLE 12 SP3, the YaST module iSCSI Initiator and Target has with the following enhancements:

This entry has appeared in a previous release notes document.

SLE 12 has moved to systemd, a new way of managing services. For more information, see the SUSE Linux Enterprise Admin Guide, Section The systemd Daemon (https://documentation.suse.com/sles/12-SP3/.

This entry has appeared in a previous release notes document.

XFS file systems created with the default settings of SLES 12 SP2 and later cannot be used SLE 11 installations.

In SLE 12 SP2 and later, by default, XFS file systems are created with the option ftype=1 that changes the superblock format. Among other things, this helps accommodate Docker. However, this option is incompatible with SLE 11.

To create a SLE 11-compatible XFS file system, use the parameter ftype=0. For example, to format an empty device, run: :

mkfs.xfs -m crc=0 -n ftype=0 [DEVICE]

In SLES 12 SP2 and before, you had to manually delete snapshots created by rollbacks at an appropriate time to avoid filling up the storage.

Starting with SLE 12 SP3, this process has been automated. During a rollback, Snapper sets the cleanup algorithm number for the snapshot corresponding to the previous default subvolume and for the backup snapshot of the previous default subvolume.

For more information, see http://snapper.io/2017/05/10/automatic-cleanup-after-rollback.html (http://snapper.io/2017/05/10/automatic-cleanup-after-rollback.html)

To be able to establish an NVMe-over-Fabrics connection with the Linux kernel provided with the SLE 12 SP3 media, you need to delete or rename the file /etc/nvme/hostid.

To restore this file when the kernel update that fixes this issue is released, generate a new host ID by running:

uuidgen > /etc/nvme/hostid

This entry has appeared in a previous release notes document.

If it is not the root file system and if the file system has at least 20 % free space available, in-place conversion of an existing Ext2/Ext3/Ext4 or ReiserFS file system is supported for data mount points.

SUSE does not recommend or support in-place conversion of OS root file systems. In-place conversion to Btrfs of root file systems requires manual subvolume configuration and additional configuration changes that are not automatically applied for all use cases.

To ensure data integrity and the highest level of customer satisfaction, when upgrading, maintain existing root file systems. Alternatively, reinstall the entire operating system.

This entry has appeared in a previous release notes document.

/var/cache contains very volatile data, like the Zypper cache with RPM packages in different versions for each update. As a result of storing data that is mostly redundant but highly volatile, the amount of disk space a snapshot occupies can increase very fast.

To solve this, move /var/cache to a separate subvolume. On fresh installations of SLE 12 SP2 or newer, this is done automatically. To convert an existing root file system, perform the following steps:

To set up a system with a non-default Btrfs subvolume structure with AutoYaST, you can now specify an arbitrary Btrfs subvolume structure in autoinst.xml.

This entry has appeared in a previous release notes document.

Some programs do not respect the special disk space characteristics of a Btrfs file system containing snapshots. This can result in unexpected situations where no free space is left on a Btrfs filesystem.

Snapper can watch the disk space of snapshots that have automatic cleanup enabled and can try to keep the amount of disk space used below a threshold.

If snapshots are enabled, the feature is enabled for the root file system by default on new installations.

For existing installations, the system administrator must enable quota and set limits for the cleanup algorithm to use this new feature. This can be done using the following commands:

For more information, see the man pages of snapper and snapper-configs.

The following host operating system combinations will be fully supported (L3) for migrating guests from one host to another for SLES 12 SP3:

SUSE Linux Enterprise Virtual Machine Driver Pack is a set of paravirtualized device drivers for Microsoft Windows operating systems. These drivers improve the performance of unmodified Windows guest operating systems that are run in virtual environments created using Xen or KVM hypervisors with SUSE Linux Enterprise Server 11 SP4 and SUSE Linux Enterprise Server 12 SP3. Paravirtualized device drivers are installed in virtual machine instances of operating systems and represent hardware and functionality similar to the underlying physical hardware used by the system virtualization software layer.

SLE now comes with SUSE Linux Enterprise Virtual Machine Driver Pack 2.5.

Previously, this functionality was provided by the pam_userdb module that was part of the general pam package. This module has been removed and the functionality is now provided as part of the pam-extra package.

When first logging in to GNOME on SLES 12 SP3 with the Workstation Extension or SLED 12 SP3, gnome-initial-setup will ask Chinese, Japanese, and Korean users for their preferred input method.

Because gnome-initial-setup is set up to run directly after the first login, it is also set up to not run before the GDM interface starts. This behavior is configured in the GDM configuration file /etc/gdm/custom.conf with the line InitialSetupEnable=False. Do not change this setting, otherwise a system without a normal user will not be able to provide the expected GDM log-in window.

Intel Omni-Path Architecture (OPA) host software is fully supported in SUSE Linux Enterprise Server 12 SP3.

Intel OPA provides Host Fabric Interface (HFI) hardware with initialization and setup for high performance data transfers (high bandwidth, high message rate, low latency) between compute and I/O nodes in a clustered environment.

For instructions on installing Intel Omni-Path Architecture documentation, see https://www.intel.com/content/dam/support/us/en/documents/network-and-i-o/fabric-products/Intel_OP_Software_SLES_12_3_RN_J71758.pdf.

Over the recent years TPM 2.0 variants have become more common. With a different API this needs new libraries, tools and bootloader support.

SLE 12 SP2 and also SP3 provide equal support for TPM 1.2 and TPM 2.0 utilities and booting.

Support for new hardware instructions in binutils, GCC and GDB is available through the Toolchain Module.

Improved initialization of qeth network devices in layer 2 and layer 3 allows for faster booting Linux instances.

The partitioning utility parted now includes partitioning functionality for FBA and ECKD DASDs. This brings parted up to par with the functionality provided by IBM Z tools.

The DASD driver can now exclude paths from normal operation if other channel paths are available.

With the new quick format mode, you can define DASD volumes with a pre-formatted track layout. This significantly reduces the deployment time of DASD volumes.

On SLES 12 SP2 and SLES 12 SP3, IBM Z and POWER machines can now function as SUSE Enterprise Storage (Ceph) clients.

This support is possible because the kernels for IBM Z and POWER now have the relevant modules for CephFS and RBD enabled. The Ceph client RPMs for IBM Z and POWER are included in SLE 12 SP3. Additionally, the QEMU packages for IBM Z and POWER are now built against librbd.

The new partition type "GPFS" in the fdasd tool supports fast identification and handles partitions that contain GPFS Network Shared Disks.

This entry has appeared in a previous release notes document.

Unlike in SLES 11, LUN scanning is enabled by default in SLES 12 and newer. Instead of having a user-maintained whitelist of FibreChannel/SCSI disks that are brought online to the guest, the system now polls all targets on a fabric. This is especially helpful on systems with hundreds of zFCP disks and exclusive zoning.

However, on systems with few disks and an open fabric, this can lead to long boot times or access to inappropriate disks. It can also lead to difficulties offlining and removing disks.

To disable LUN scanning, set the boot parameter zfcp.allow_lun_scan=0.

For LUN Scanning to work properly, the minimum storage firmware levels are:

Secure connections for snIPL enable Linux to remotely handle a greater variety of environments.

The package libica now includes a DRBG (Deterministic Random Bit Generator) that is compliant with the updated security specification NIST SP 800-90A for pseudo-random number generation.

SLES 12 SP3 includes support for using new cryptography hardware in toleration mode. This allows performing cryptographic operations as on older hardware which means an easier migration to new hardware.

To maintain persistent configurations for PCI devices, SLES 12 SP3 now provides stable and unique identifiers for PCI functions for as long as the I/O configuration (IOCDS and HCD) remains stable.

When code needs to be treated as read-only, software breakpoints cannot be used. GDB can now use hardware breakpoints for debugging.

Applications with huge memory sets can use 2 GB large memory pages for improved memory handling.

Addressing CPUs across drawers improves scheduling and performance analysis on IBM z Systems z13 and later hardware.

This entry has appeared in a previous release notes document.

Fully supported packages of the Icinga monitoring server for SUSE Linux Enterprise Server 12 are available with a SUSE Manager subscription. Icinga is compatible with a previously included monitoring server.

For more information about Icinga, see the SUSE Manager documentation at https://www.suse.com/documentation/suse-manager-3/singlehtml/book_suma_advanced_topics_31/book_suma_advanced_topics_31.html#advanced.topics.monitoring.with.icinga.

LibreOffice has been updated to the new major version 6.4. For information about major changes, see the LibreOffice 6.4 release notes at https://wiki.documentfoundation.org/ReleaseNotes/6.4.

SLES 12 SP4 and SLES 15 ship with PostgreSQL 10 by default. To enable an upgrade path for customers, SLE 12 SP3 now includes PostgreSQL 10 in addition to PostgreSQL 9.6 (the version that was originally shipped).

To upgrade a PostgreSQL server installation from an older version, the database files need to be converted to the new version.

Important: PostgreSQL Upgrade Needs to Be Performed Before Upgrade to New SLES Version

Neither SLES 12 SP4 nor SLES 15 include PostgreSQL 9.6. However, availability of PostgreSQL 9.6 is a requirement for performing the database upgrade to the PostgreSQL 10 format. Therefore, you must upgrade the database to the PostgreSQL 10 format before upgrading to the desired new SLES version.

The following major new features are included in PostgreSQL 10:

PostgreSQL 10 also brings an important change to the versioning scheme that is used for PostgreSQL: It now follows the format major.minor. This means that minor releases of PostgreSQL 10 are for example 10.1, 10.2, ... and the next major release will be 11. Previously, both the parts of the version number were significant for the major version. For example, PostgreSQL 9.3 and PostgreSQL 9.4 were different major versions.

For the full PostgreSQL 10 release notes, see https://www.postgresql.org/docs/10/release-10.html (https://www.postgresql.org/docs/10/release-10.html).

Before starting the migration, make sure the following preconditions are fulfilled:

Upstream documentation about pg_upgrade including step-by-step instructions for performing a database migration can be found locally at file:///usr/share/doc/packages/postgresql10/html/pgupgrade.html (if the postgresql10-docs package is installed), or online at https://www.postgresql.org/docs/10/pgupgrade.html (https://www.postgresql.org/docs/10/pgupgrade.html). The online documentation explains how you can install PostgreSQL from the upstream sources (which is not necessary on SLE) and also uses other directory names (/usr/local instead of the update-alternatives based path as described above).

Some programs require GnuTLS version 3.3 or newer to work.

The upgrade from GnuTLS 3.2 to GnuTLS 3.3 is an update which does not change of the major version of libgnutls28, so existing programs will continue to work.

The library libgnutls-xssl.so was not used by other programs and has been removed.

Postfix version 2.x is going out of support in the near future.

In SUSE Linux Enterprise 12 SP3, we have upgraded Postfix to version 3.2.0 (from Postfix 2.11.8 in SUSE Linux Enterprise 12 SP2). For information about major changes in the new version of Postfix, see:

Open vSwitch has been updated to 2.7.0.

Important changes include:

For more detailed information about changes between version 2.6.0 and 2.7.0, see https://github.com/openvswitch/ovs/blob/master/NEWS (https://github.com/openvswitch/ovs/blob/master/NEWS).

This entry has appeared in a previous release notes document.

To upgrade a PostgreSQL server installation from version 9.1 to 9.4, the database files need to be converted to the new version.

Note: System Upgrade from SLE 11

On SLE 12, there are no PostgreSQL 8.4 or 9.1 packages. This means you must first migrate PostgreSQL from 8.4 or 9.1 to 9.4 on SLE 11 before upgrading the system from SLE 11 to SLE 12.

Newer versions of PostgreSQL come with the pg_upgrade tool that simplifies and speeds up the migration of a PostgreSQL installation to a new version. Formerly, it was necessary to dump and restore the database files which was much slower.

To work, pg_upgrade needs to have the server binaries of both versions available. To allow this, we had to change the way PostgreSQL is packaged as well as the naming of the packages, so that two or more versions of PostgreSQL can be installed in parallel.

Starting with version 9.1, PostgreSQL package names on SUSE Linux Enterprise products contain numbers indicating the major version. In PostgreSQL terms, the major version consists of the first two components of the version number, for example, 9.1, 9.3, and 9.4. So, the packages for PostgreSQL 9.3 are named postgresql93, postgresql93-server, etc. Inside the packages, the files were moved from their standard location to a versioned location such as /usr/lib/postgresql93/bin or /usr/lib/postgresql94/bin. This avoids file conflicts if multiple packages are installed in parallel. The update-alternatives mechanism creates and maintains symbolic links that cause one version (by default the highest installed version) to re-appear in the standard locations. By default, database data is stored under /var/lib/pgsql/data on SUSE Linux Enterprise.

The following preconditions have to be fulfilled before data migration can be started:

Upstream documentation about pg_upgrade including step-by-step instructions for performing a database migration can be found under file:///usr/share/doc/packages/postgresql94/html/pgupgrade.html (if the postgresql94-docs package is installed), or online under http://www.postgresql.org/docs/9.4/static/pgupgrade.html (http://www.postgresql.org/docs/9.4/static/pgupgrade.html). The online documentation explains how you can install PostgreSQL from the upstream sources (which is not necessary on SLE) and also uses other directory names (/usr/local instead of the update-alternatives based path as described above).

For background information about the inner workings of pg_admin and a performance comparison with the old dump and restore method, see http://momjian.us/main/writings/pgsql/pg_upgrade.pdf.

This entry has appeared in a previous release notes document.

MariaDB is a backward-compatible replacement for MySQL.

If you update from SLE 11 to SLE 12 or later, it is advisable to do a manual backup before the system update. This can help if a start of the database has issues with the storage engine's on-disk layout.

After the update to SLE 12 or later, a manual step is required to actually get the database running (this way you quickly see if something goes wrong):

touch /var/lib/mysql/.force_upgrade
rcmysql start
# => redirecting to systemctl start mysql.service
rcmysql status
# => Checking for service MySQL:
# => ...

Most functionality of libcgroup1 is also provided by systemd. In fact, the cgroup handling of libcgroup1 can conflict with that of systemd.

Starting with SLE 12 SP4, libcgroup1 has been removed. Migrate to the equivalent functionality in systemd.

For more information, see https://www.suse.com/support/kb/doc/?id=7018741.

Docker Compose is not supported as a part of SUSE Linux Enterprise Server 12. While it was temporarily included as a Technology Preview, testing showed that the technology was not ready for enterprise use.

SUSE's focus is on Kubernetes which provides better value in terms of features, extensibility, stability and performance.

This entry has appeared in a previous release notes document.

The Nagios monitoring server has been removed from SLES 12.

When upgrading to SLES 12 or later, installed Nagios configuration may be removed. Therefore, we recommend creating backups of the Nagios configuration before the upgrade.

In SLE 12 SP2 and earlier, the OFED (OpenFabric Enterprise Distribution) stack came directly from OFED.

Since the release of SLES 12 SP2, most of this stack has been upstreamed to the Linux RDMA project. This has resulted in an influx of contributions to the project and much improved source.

With SLE 12 SP3, we have updated the OFED stack to the version from the new upstream. This has brought the following package changes:

This entry has appeared in a previous release notes document.

The version of the package mvapich2-psm originally shipped with SLES 12 SP2 and SLES 12 SP3 exclusively supported Intel Omni-Path Architecture (OPA) fabrics. In SLES 12 SP1 and earlier, this package supported the use of Intel True Scale fabrics instead.

This issue is fixed by a maintenance update providing an additional package named mvapich2-psm2 which only supports Intel OPA, whereas the original package mvapich2-psm only supports Intel True Scale fabrics again.

If you are currently using mvapich2-psm together with Intel OPA fabrics, make sure to switch to the new package mvapich2-psm2 after this maintenance update.

In past releases, the kernel-default package used to contain firmware for in-kernel drivers.

Starting with SLES 12 SP3, such firmware is now delivered as part of the package kernel-firmware.

Support for new hardware instructions in binutils, GCC and GDB is available through the Toolchain Module.

The Legacy module now provides a package for libgcrypt11. This enables running applications built on SLES 11 against libgcrypt11 on SLES 12.

The following Ext4 features are experimental and unsupported:

SUSE Linux Enterprise was the first enterprise Linux distribution to support journaling file systems and logical volume managers back in 2000. Later, we introduced XFS to Linux, which today is seen as the primary work horse for large-scale file systems, systems with heavy load and multiple parallel reading and writing operations. With SUSE Linux Enterprise 12, we went the next step of innovation and started using the copy-on-write file system Btrfs as the default for the operating system, to support system snapshots and rollback.

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

² ReiserFS is supported for existing file systems. The creation of new ReiserFS file systems is discouraged.

³ 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.

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 above table 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: 1024 Bytes = 1 KiB; 1024 KiB = 1 MiB; 1024 MiB = 1 GiB; 1024 GiB = 1 TiB; 1024 TiB = 1 PiB; 1024 PiB = 1 EiB. See also http://physics.nist.gov/cuu/Units/binary.html.

NFSv4 with IPv6 is only supported for the client side. An NFSv4 server with IPv6 is not supported.

The version of Samba shipped with SUSE Linux Enterprise Server 12 SP3 delivers integration with Windows Active Directory domains. In addition, we provide the clustered version of Samba as part of SUSE Linux Enterprise High Availability Extension 12 SP3.

Some file system features are available in SUSE Linux Enterprise Server 12 SP3 but are not supported by SUSE. By default, the file system drivers in SUSE Linux Enterprise Server 12 SP3 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.