SL Micro Release Notes #

For the most up-to-date version of the documentation for SL Micro, see:

Images other than QCOW or VMDK target bare metal deployments.

Use of SL Micro without a container runtime is only supported when SL Micro is used as a KVM host and workloads are installed into KVM virtual machines. Running workloads directly on the OS is not supported, with the exception of system management software.

SL Micro 6.0 only supports deployment via images. An installer based installation method is not offered.

Customization of the installation process with the provided images can be done with Ignition and Combustion (pre-configured images and self-installing images).

We will offer select images with support for cloud-init with a later milestone.

An online migration of existing SL Micro 5.5 installations to SL Micro 6.0 is possible and is fully supported. Upgrading from SL Micro 5.5 is only possible via the transactional-update tool. For the upgrade procedure, refer to https://documentation.suse.com/sle-micro/6.0/html/Micro-upgrade/index.html

With previous releases we supported manual installation via a YaST based image. With SLM we have dropped support for this installation method and only focus on RAW image based deployments. The SelfInstall image variant has been extended to allow setting of various parameters to direct it and also enable an unattended installation using the SelfInstall image.

SLM is focused on distributed infrastructures/Edge deployments, which means systems running SLM are not necessarily within DCs or secure locations. We therefore have improved our security story and added support for full disk encryption (FDE) to SLE Micro.

We are offering capabilities for confidential compute on SLM via the included virtualization stack.

Since SL Micro is positioned to be used within decentralized infrastructures including Edge use cases and Industrial Edge, a system management based on current YaST2 is not within scope. Specifically, for Industrial Edge, a basic web-based system management was required. We have chosen the cockpit project as a base for that. Therefore, the cockpit packages are added to the common code base and adjusted for the Immutable OS setup of SL Micro.

For the Intel/AMD 64bit architecture (x86_64) the real-time (rt) kernel is provided in addition to the default kernel. Support for RT includes support for Kernel Live Patching on the RT kernel. Note: When using the RT kernel, KVM is not supported, and workloads need to be run within containers Containers need special treatment with RT.

With SUSE Linux Enterprise we fully support AppArmor and in addition provide the framework for SELinux – without providing and supporting a policy for SELinux. On SL Micro we do not support AppArmor. SL Micro only supports SELinux and in addition we ship a supported policy. On top of that, we will look into providing dedicated SELinux policies for the containers we already provide or support on top of SL Micro (PCP and Nvidia). SL Micro 6.0 will have SELinux in enforced mode as a default.

Podman 4.7 is a major release with tons of new features and extensive bug fixes compared to Podman 4.3. Individual changes are to be found upstream https://github.com/containers/podman/blob/main/RELEASE_NOTES.md

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 improvements:

To ensure that nothing breaks with this major change, the old CNI stack will remain the default on existing installations. Bear in mind that Netavark will be released as part of a maintenance update.

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.

If you have run Podman 3.x before upgrading to Podman 4, Podman will continue to use CNI plugins as it had before. To begin using Podman 4 with Netavark, you need to run the command podman system reset. The command will destroy all images, networks and all containers.

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.

With SL Micro 6.0 legacy BIOS boot support on Intel/AMD 64bit systems (x86_64) is deprecated and will be removed with a later release.

SL Micro 6.0 provides support for LTTng (Linux Trace Toolkit: next generation). Support for LTTng will however be removed in a later SL Micro version in favor of alternative solutions for tracing like bpftrace.

For web-based management of a single node, Cockpit is included. For details, refer to https://documentation.suse.com/en-us/sle-micro/6.0/html/Micro-6.0-cockpit/.

There have been new Cockpit modules added to the product. Due to the amount of dependencies, not all of the Cockpit modules are part of the raw images and some have to be installed additionally.

When enabling a firewall via the Cockpit user interface, be aware that your connection to the host may be interrupted unless the Cockpit port is configured to be open in advance.

The SELinux module for Cockpit provides basic functionality for users to troubleshoot their configuration. With this release the functionality has been extended with the introduction of the setroubleshoot-server package.

SUSE Manager can be used to manage SL Micro hosts. There are certain limitations:

We intend to resolve these issues in the future maintenance updates of SL Micro on SUSE Manager.

The Public Cloud instance initialization code has been changed from using Ignition and Afterburn to cloud-init in AWS EC2, cloud-init and the Azure agent in Azure, and the Google guest environment for GCE. This means configuration of instances through user data now behaves the same as SUSE Linux Enterprise Server, any version, instances. This also addresses the issue in Azure with the state detection of the VM. The web console will now properly show a VM in "Running" state instead of appearing to be stuck in "Provisioning". This also allows user configuration through the web console in Azure and user configuration using the customary ways in AWS EC2 and GCE.

The container registry entries for Docker Hub and openSUSE Registry, which were previously included by default, have now been removed. If you want to pull container images from either of them, add them to the /etc/containers/registries.conf file.

When you run the toolbox script to pull and start the toolbox container, a previous version of the container image is pulled. This does not influence toolbox funcionality and you can use the toolbox container as needed.

Previously, it was possible to SSH as root using password-based authentication. In SLM 6.0 only key-based authentication is allowed by default. Systems upgraded to 6.0 from 5.x carry over the old behavior. New installations will enforce the new behavior.

Installing the package openssh-server-config-rootlogin restores the old behavior and allows password-based login for the root user.

SLM 6.0 includes driver enablement for the following System-on-Chip (SoC) chipsets:

Note

Driver enablement is done as far as available and requested. Refer to the following sections for any known limitations.

Some systems might need additional drivers for external chips, such as a Power Management Integrated Chip (PMIC), which may differ between systems with the same SoC chipset.

For booting, systems need to fulfill either the Server Base Boot Requirements (SBBR) or the Embedded Base Boot Requirements (EBBR), that is, the Unified Extensible Firmware Interface (UEFI) either implementing the Advanced Configuration and Power Interface (ACPI) or providing a Flat Device Tree (FDT) table. If both are implemented, the kernel will default to the Device Tree; the kernel command line argument acpi=force can override this default behavior.

Check for SUSE YES! certified systems, which have undergone compatibility testing.

SLES 15 SP5 and SLE Micro 5.5 added 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) as well as NVIDIA IGX Orin based systems.

NVIDIA JetPack* 6.0 boot firmware and Linux kernel 6.5 changed the Application Binary Interface (ABI) for numbering General Purpose Input/Output (GPIO) pins — specifically the main GPIO ports X, Y, Z, AC, AD, AE, AF and AG — referenced in the machine-specific vendor Device Tree (DT) binary for NVIDIA Orin based systems.

SLM 6.0 adopts the behavior of the latest kernels and requires NVIDIA JetPack 6.0 or later boot firmware to be flashed on any NVIDIA Orin based platforms.

Refer to your system vendor’s documentation for how to enter Recovery Mode and to flash the boot firmware. For example: sudo ./flash.sh device-identifier-and-boot-medium external

The following features and packages are deprecated and will be removed in a future version of SL Micro.

The following ceph client packages have been deprecated and will be removed in 6.1: