This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Key Technical Differences Between SLE 15 and SLE 16
SUSE Linux Enterprise Server 16.0

Key Technical Differences Between SLE 15 and SLE 16

Publication Date: 24 Oct 2025
WHAT?

This article addresses common technical questions about installing and using SLE 16.

WHY?

SLE 16 introduces significant changes compared to its predecessor, SLE 15. This article helps you navigate those differences.

EFFORT

It takes approximately 20 minutes to read the article.

GOAL

You will have a clear understanding of what has been added or removed in SLE 16.

1 Changes in the installation process

 

This section answers common questions about the new installer and deployment process.

1.1 What happened to YaST?

 

For installation, SLE 16 comes with installer images based on a new technology called Agama. The single purpose of Agama is to install a new system and not to serve as a management tool like YaST was.

Agama images are delivered in several flavors. To name several of them:

  • minimal: for installation from the network

  • full: with a full copy of the package repositories for all product flavors

  • remote installation: deployment using the PXE client

Agama supports unattended installation and maintains a high degree of compatibility with AutoYaST's file format and data schema. However, Agama is not a fully compatible drop-in replacement for AutoYaST. Although you can use many existing profiles, some adjustments to the profiles are expected. Additionally, a new, more powerful profile schema based on JSON/Jsonnet is also available.

You can install SLE 16 using repositories provided by a local RMT server inside the customer's network. There is no RMT version based on SLE 16 yet. However, RMT 15 is fully supported as an installation source for SLE 16.

1.2 Where is the rescue system?

 

The Agama installation images no longer come with a separate rescue system. In a future release of SLE 16, we plan to provide a separate image for this purpose.

To enter a rescue shell (without starting Agama), you can use the live media. Alternatively, you can use the Agama image to access the installed for diagnosis and repair in any of the following ways:

  • Boot the installation image, switch to another virtual console and log in as root.

  • Boot the installation image and open a terminal window.

  • Boot the installation image, and before starting the Linux kernel, add 3 to the kernel CLI. This will boot into runlevel 3, skipping the graphical system and thus the installer.

Any of these methods will give you a root shell that should allow you to access your root partition. Many of the tools needed to repair or recover a potentially broken installation should be available inside the Agama live media.

2 Migration from previous SLE releases

 

For migration from SLE 15 to SLE 16, we use a new approach to migration based on a technology called SUSE Migration Services.

This technology uses a special medium that attempts the migration in several steps after booting. The first, pre-migration step analyzes the existing installation to identify problematic settings that cannot be converted automatically, such as AppArmor profiles. Such issues are flagged, and you are given the option to either accept an incomplete migration or cancel the process. In the second step, the system boots into a special medium that performs the actual migration. After that, the system boots into the migrated system and performs optional final tasks.

Migration of a running system is no longer provided.

SLE 16.1 is the target release for delivering full migration support. 16.0 provides limited migration capabilities, supporting only migrations from SLE 15 SP7. Furthermore, the tools in 16.0 do not cover all aspects of migration.

3 Changes in the base system and the boot process

 

Let us dive into the foundational changes affecting system services, core libraries, and essential utilities.

3.1 Are there any changes to the boot loader in SLE 16?

 

The boot loader in SLE 16 is GRUB 2 2.12. BLS and systemd-boot are not used now, but may be added in the future.

On AMD64/Intel 64, full disk encryption is supported using PCR to unlock the disk if the TPM chip supports TPM v2.1 and later.

3.2 Where have the configuration files from /etc been moved?

 

SUSE continues to move configuration files delivered by SUSE from /etc to /usr. This solution enables you to maintain your settings in /etc without worrying about maintenance updates overwriting them. Even though many packages follow the paradigm, certain tools are still shipped with regular configuration files located in /etc. The process is still ongoing, and we expect that the other tools will be adapted in a future SLE release.

You have three options for how to modify the configuration of a service or tool. For example, the tool frobnicator usually has configuration files in /etc/frob.conf. Starting with SLE 16.0, the default configuration file of the tool is /usr/etc/frob.conf. Do not modify this file as it may be overwritten by future maintenance updates. To apply your custom changes, you have the following options:

  • Place your own copy of the configuration file into /etc/frob.conf, which has a precedence and the configuration file supplied by SUSE is then ignored.

  • You can place drop-in files into /etc/frob.d. The tool first loads the configuration from /usr/etc/frob.conf and then updates it using the drop-in files in /etc/frob.d.

Important
Important: Possible unexpected errors

This solution can lead to unexpected results if you have tools that try to update configuration files in /etc blindly. In particular, creating an empty /etc/ssh/sshd_config file may result in getting locked out of your system.

For more information and a list of affected packages, refer to configuration split details.

3.3 Are there any changes in the way the base system works in general?

 

Yes, /tmp is no longer persistent on reboot but uses tmpfs.

3.4 Do you support transactional updates in SUSE Linux Enterprise Server?

 

Currently, transactional updates are not supported on SUSE Linux Enterprise Server. The transactional update is supported by another product—SUSE Linux Micro.

3.5 Deprecated technologies in the base system

 

The following technologies have been deprecated:

  • NIS aka Yellow Pages

  • nscd: The name service caching daemon

  • wicked: Replaced by NetworkManager for managing network connections

  • AppArmor: SELinux is used exclusively as the security framework

  • SystemV init support

3.6 What architecture level sets are supported?

 

The following table summarizes supported architecture level sets.

Table 1: Supported architecture level sets
 
ArchitectureSupported versionNotes
AMD64/Intel 64AMD64/Intel 64-v2Optimized v3 versions of certain shared libraries are now available. These libraries, which follow the naming scheme libfoo-x86_64_v3, are installed automatically on systems that support the new instruction set.
Intel 32-bitNot supportedA 32-bit runtime is no longer supported, and SUSE does not provide any 32-bit libraries anymore.
IBM POWERPOWER 9 and higherSLE 16.0 is supported on POWER 10 and POWER 11. Even though SLE 16.0 continues to work on POWER 9 (except for KVM), this is not supported by IBM.
IBM POWER 32-bitNot supportedSupport for a 32-bit runtime has been discontinued since SLES 15 SP3.
IBM IBM ZIBM Z14 
AArch64Armv8.0-ANo change from SLE 15.

3.7 Do you still support legacy BIOS on AMD64/Intel 64?

 

The default for fresh installations of SLE 16.0 is UEFI. Support for legacy BIOS is deprecated and will be removed in a future version of the product. However, support for legacy BIOS is provided for backward compatibility in the following scenarios:

  • migration of VMs that use Legacy BIOS

  • certain instances in public clouds

  • systems upgraded from SLE 15

Some features may not be available when using Legacy BIOS, such as full disk encryption with TPM.

4 Changes in security

 

This section covers the most critical security updates and changes.

4.1 What is the status of SELinux?

 

In standard installations, SELinux is enabled by default and set to enforcing mode. When configuring a SLES or SLES for SAP applications system to run SAP, SELinux is changed to permissive mode transparently. Future SAP notes may further clarify details on how to modify the SELinux setup to guarantee optimal performance.

For details on SELinux, refer to the Understanding SELinux Basics article.

4.2 Are you changing the rules for root access?

 

Starting with SLE 16, root access is modified to be more secure by default. For users with physical access to the system (that is, text console, serial, graphical desktop), login as root is still allowed by default. There is no change in behavior compared to SLE 15. However, for remote access via SSH, root login is disabled when trying to use password authentication. To allow it, install the openssh-server-config-rootlogin package. Also, root login is still possible when you configure SSH keys in /root/.ssh/authorized_keys*.

4.3 What about sudo?

 

In SLE (15 and older), sudo is configured to prompt for the password of the target user (the account you want to switch to). In SLE 16, we have strengthened the security of the default setup:

  • The first user created by the installer is now added to the wheel group.

  • When using sudo -i, kexec or polkit for authentication, the following rules apply:

    • If the user is part of the wheel group, they are prompted for their own password, rather than the root password.

    • If the user is not part of the wheel group, they are prompted for the root password.

This new policy is implemented with the sudo-policy-wheel-auth-self package, which is installed by default on new SLE 16.0 systems.

5 Changes in kernel and storage

 

Explore the updates at the core of the system, from the Linux kernel to the storage stack.

5.1 Kernel version and kernel subsystem changes

 

Support of the following core kernel subsystems has been dropped:

  • quota v1

  • cgroups v1 interface

SLE 16.0 is delivered with kernel version 6.12.

5.2 Support status of file systems

 

The following table provides an overview of the file system status in SLE 16:

Table 2: Supported architecture level sets
 
File systemStatus
reiserfsDropped
hfsplusDropped
UFSDropped
quota v1Dropped
ocfs2Dropped. Use gfs2 instead (available only on SLE HA).
btrfsSupported and set as the default file system
xfsSupported
extSupported
gfs2Supported—both read and write operations. Available on SLE HA only.

5.3 How do I configure Kdump?

 

On SLE 15 you could configure Kdump using YaST. However, with YaST not available on SLE 16, the kdumptool tool is now used to configure Kdump. You can control settings using the following variables in /etc/sysconfig/kdump:

  • KDUMP_CRASHKERNEL

  • KDUMP_UPDATE_BOOTLOADER

Using kdumptool, you can perform the following tasks:

  • Check whether the running kernel has the expected crashkernel settings

  • Update the bootloader configuration to enforce the expected settings on next reboot

  • Disable kdump by removing crashkernel settings from your boot loader configuration

6 Changes in virtualization

 

SLE 16 continues to support KVM. Support for Xen has been dropped.

7 Changes in the desktop environment

 

The desktop product has been discontinued. SLE 16 is available with a minimal desktop environment based on GNOME 48, including essential applications such as the Firefox Web browser, file browser, viewers for PDFs and images, and so on.

Changes in desktop technologies:

  • X11 is no longer shipped. Desktop sessions now use Wayland.

  • The VNC server is no longer shipped. Remote desktop and sharing are now provided using RDP.

  • The GTK2, Qt5 and wxWidgets widget libraries have been dropped.

8 Changes in the system management

 

Here, we answer your questions about the changes to system administration tools and automation frameworks.

8.1 Which management frameworks are available?

 

The YaST management tool is not shipped anymore, so for general 1:1 management tasks you can use the delivered Cockpit. However, Cockpit does not provide a full replacement, and some modules YaST used are missing in it. For details regarding Cockpit, refer to the Cockpit guide.

For management automation, SLE 16 supports Ansible. SUSE Multi-Linux Manager is another option for managing SLE 16 installations that use Salt internally. However, SLE 16 itself does not contain Salt packages.

Support of WBEM has been dropped (in SLE 15 it was provided by the SBLIM packages).

8.2 What has changed in the update stack and package management?

 

In SLE 16, there are no modules anymore to distinguish between, for example, the base system, server applications or development packages. There are also no longer separate channels for pool and update. These changes, together with improvements to zypper, should result in better performance when applying updates. SLE minor releases (aka 16.1, 16.2 and so on) will continue to have separate repositories.

SLE 16 instances can register against (and receive updates from) an RMT server. Currently, the RMT service has to run on a SLE 15 instance as we do not support the RMT service on SLE 16 yet. RMT on SLE 16 is expected to be delivered with SLE 16.1.