documentation.suse.com / Customizing SUSE Linux Micro on Premises
SUSE Linux Micro 6.2

Customizing SUSE Linux Micro on Premises

Publication Date: 03 Nov 2025
WHAT?

This article provides a comprehensive guide for customers building their own solutions based on SUSE Linux Micro.

WHY?

You want to create a deployment image completely suited to your needs.

EFFORT

It takes about 30 minutes to read the article.

GOAL

You will be able to build kernel modules, drivers and images tailored to your needs.

REQUIREMENTS

  • List the requirements to accomplish the task(s) described below.

1 Introduction

 

This article explains how to transform the provided raw OS image into a purpose-built system. The process may involve installing the necessary software from RPMs and applying custom configurations for standard deployments. For specialized hardware not supported by the default image, we will also cover how to build and integrate custom kernel modules and drivers to ensure full system functionality.

2 Identifying SUSE OEM

 

Products based on SLE support more than 7,000 software applications and the widest range of hardware platforms and architectures in the industry. Partnering with SUSE enables OEMs to build and deliver solutions that help customers reduce costs, manage complexity, and mitigate risk. However, when SLE family products are being bundled with a system or integrated into a solution by an OEM, the system or solution needs to state the OEM status to customers, users and any compliance team. An important reason for this is that the terms and conditions of an OEM license agreement usually differ from a common end-user license agreement (EULA).

To mark a system as containing an OEM version of a SUSE Linux Enterprise family product, follow the instructions detailed below.

2.1 Modification of /etc/os-release

 

The file /etc/os-release is part of the *-release package for each product of the SUSE Linux Enterprise family. It is used to identify the respective product.

If the OEM does not rebrand SLE when integrating it into the OEM solution, the file /etc/os-release shall be amended. For details about the file structure, refer to the SLE OS identification .

The definition of /etc/os-release does not cover OEM identification. However, custom values can be added when correctly prefixed. We suggest OEMs to introduce:

SUSE_OEM_NAME

A mandatory clear identifier for the OEM solution/appliance.

SUSE_OEM_SUPPORT_URL

The attribute refers to the main support page for the OEM operating system.

SUSE_OEM_BUG_REPORT_URL

The attribute refers to the main bug reporting page for the OEM operating system.

2.2 Modification of /etc/issue

 

The file /etc/issue provides a banner to a system on login. As the default on SLE, /etc/issue identifies the version, architecture, kernel and currently running network configuration of the respective product. An example follows.

Welcome to SUSE Linux Micro 6.2  (x86_64) - Kernel \r (\l).

eth0: \4{eth0} \6{eth0}

OEMs shall adjust /etc/issue to identify the OEM solution instead of SUSE Linux Enterprise.

2.3 Completely rebranded systems

 

An OEM can decide to completely rebrand a SUSE Linux Enterprise system. In this case, the OEM needs to create an individual *-release package including the /etc/issue and /etc/os-release files. The *-release package from the respective product provided by SUSE may be used as a template.

It is important for the OEM to make sure no SUSE-originated files can be found in /etc/products.d/ that would identify the system as a SLE system. Instead, the information contained in the file needs to come from the OEM and explicitly identify the OEM system.

3 Packaging custom kernel modules

 

Working with external kernel modules on SUSE Linux Enterprise systems requires a specific approach to ensure they remain compatible with kernel updates. The official Kernel Module Packages Manual provides detailed guidelines on this process. This comprehensive guide covers everything from the background on kernel ABI stability to the step-by-step process of building, packaging, signing, and deploying your own kernel modules correctly. For details, refer to the Kernel Module Packages Manual.

4 Creating custom drivers

 

Installing third-party hardware drivers in a mission-critical environment can be a source of significant concern, from ensuring compatibility to guaranteeing support. The SUSE SolidDriver Program directly addresses these challenges by creating a standardized framework for our hardware partners. This ensures that kernel drivers are delivered in a uniform, proven, and reliable manner, giving customers the confidence to integrate the latest technology into their SUSE Linux Enterprise.

For a detailed description of the SUSE SolidDriver Program, refer to the official documentation of the program.

5 Building custom images based on SUSE Linux Micro

 

This section provides a brief guide for creating custom images based on SUSE Linux Micro, allowing you to build a system tailored to your solution's needs. The entire process relies on the KIWI NG image builder and can be summarized in the following key stages:

For a complete description of how KIWI GN works, refer to the KIWI documentation.

5.1 Downloading files for image customization

 

To get the necessary files that define the custom image, proceed as follows:

  1. Navigate to the openSUSE Build Service.

  2. Download the content of the package SL-Micro.

5.2 Modifying image definition files

 

In the SL-Micro package, there is the build definition file SL-Micro.kiwi. You can modify the file to suit your needs as described below:

For a complete specification of the elements, refer to the KIWI image description.

5.2.1 Adding custom files

 

You can add your custom configuration files to the image. To do so, proceed as follows:

  1. Navigate to the directory with the build definition file.

  2. Create a root directory if it does not exist.

  3. Inside root, create the directory path where you want your file to be placed.

  4. Place your custom configuration file in that directory.

Alternatively, to generate the files during the image build process, use the config.sh script. For details, refer to the KIWI documentation.

5.3 Building the custom image

 

After you have prepared all necessary files and the directory structure, you can use kiwi-ng to build the image. To build it directly with kiwi-ng, you need to have the version included in SLE 16.0 or higher. Alternatively, you can use a container.

Then, to build the image, proceed as follows. Make sure to have Podman installed if you intend to use a container for the build process.

  1. Either download the container image from the registry.

    Or you can use KIWI directly after installing it: 

    > sudo zypper install python3-kiwi

  2. Make sure that the target build directory exists.

  3. (Optional) Start the container: 

    > podman run --privileged -v
          PATH_TO_DESCRIPTION_FILE:/image:Z -v /dev:/dev
          registry.suse.com/bci/kiwi:10.2

  4. Trigger the build either directly or inside the KIWI container: 

    > sudo kiwi-ng system build \
    --description IMAGE_DESCRIPTION \
    --target-dir OUTPUT_BUILD_DIRECTORY

  5. (Optional) If the container was used, exit it by typing exit in the container prompt.

  6. After the build process completes, check the output build directory with the image.