diff --git a/DC-Micro-developers-guide b/DC-Micro-developers-guide
new file mode 100644
index 000000000..0cf7bcab4
--- /dev/null
+++ b/DC-Micro-developers-guide
@@ -0,0 +1,14 @@
+# This file originates from the project https://github.com/openSUSE/doc-kit
+# This file can be edited downstream.
+
+MAIN="customizing-products-images.asm.xml"
+SRC_DIR="articles"
+IMG_SRC_DIR="images"
+
+PROFOS="slmicro"
+PROFCONDITION="suse-product"
+#PROFCONDITION="suse-product;beta"
+#PROFCONDITION="community-project"
+
+STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns"
+FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse-ns"
diff --git a/articles/customizing-products-images.asm.xml b/articles/customizing-products-images.asm.xml
new file mode 100644
index 000000000..9de86f040
--- /dev/null
+++ b/articles/customizing-products-images.asm.xml
@@ -0,0 +1,195 @@
+
+
+
+
+ %entities;
+]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Legal Notice
+
+
+ GNU Free Documentation License
+
+
+
+
+
+ Customizing &productname; on Premises
+
+
+
+
+ 2025-11-04
+
+
+
+ Initial version
+
+
+
+
+
+
+
+
+ &x86-64;
+ &power;
+
+
+
+ &productname;
+
+ Customizing &productname; on Premises
+ How to customize deployment images, kernel modules and kernel drivers
+
+ Customize deployment images, kernel modules and kernel drivers
+
+
+ Systems Management
+
+
+
+
+ Configuration
+ Installation
+
+ Products & Solutions
+
+
+ https://bugzilla.suse.com/enter_bug.cgi
+ Documentation
+ SUSE Linux Micro 6.2
+
+ jsindelarova@suse.com
+
+
+ yes
+
+
+
+
+ WHAT?
+
+
+ This article provides a comprehensive guide for customers building their own
+ solutions based on &productname;.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/concepts/customizing-products-drivers.xml b/concepts/customizing-products-drivers.xml
new file mode 100644
index 000000000..5520a3dfd
--- /dev/null
+++ b/concepts/customizing-products-drivers.xml
@@ -0,0 +1,38 @@
+
+
+
+
+ %entities;
+]>
+
+
+
+
+
+
+ Creating custom drivers
+
+
+
+
+ The topic serves as a link to the SolidDriver Program description.
+
+
+
+
+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 &sle;.
+
+
+ For a detailed description of the &suse; SolidDriver Program, refer to the official documentation of the
+ program.
+
+
diff --git a/concepts/customizing-products-identification.xml b/concepts/customizing-products-identification.xml
new file mode 100644
index 000000000..edaadc688
--- /dev/null
+++ b/concepts/customizing-products-identification.xml
@@ -0,0 +1,113 @@
+
+
+
+
+ %entities;
+]>
+
+
+
+
+
+
+ Identifying &suse; OEM
+
+
+
+
+ Products based on &slea; 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 &slea; 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.
+
+
+ Modification of <filename>/etc/os-release</filename>
+ 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 &slea; when integrating it into
+ the OEM solution, the file /etc/os-release shall be amended. For details
+ about the file structure, refer to the &slea;
+ 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.
+
+
+
+
+
+
+
+
+ Modification of <filename>/etc/issue</filename>
+ The file /etc/issue provides a banner to a system on login.
+ As the default on &slea;, /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.
+
+
+
+ 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 &slea; system. Instead, the information contained in the file needs
+ to come from the OEM and explicitly identify the OEM system.
+
+
diff --git a/concepts/customizing-products-images-introduction.xml b/concepts/customizing-products-images-introduction.xml
new file mode 100644
index 000000000..ce9afae7e
--- /dev/null
+++ b/concepts/customizing-products-images-introduction.xml
@@ -0,0 +1,37 @@
+
+
+
+
+ %entities;
+]>
+
+
+
+
+
+
+ Introduction
+
+
+
+
+ The topic is just an introduction to the article.
+
+
+
+
+ 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.
+
+
diff --git a/concepts/customizing-products-kernel.xml b/concepts/customizing-products-kernel.xml
new file mode 100644
index 000000000..7d696069d
--- /dev/null
+++ b/concepts/customizing-products-kernel.xml
@@ -0,0 +1,39 @@
+
+
+
+
+ %entities;
+]>
+
+
+
+
+
+
+ Packaging custom kernel modules
+
+
+
+
+ The topic serves as a link to an SBP.
+
+
+
+
+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.
+
+
diff --git a/tasks/customizing-products-images.xml b/tasks/customizing-products-images.xml
new file mode 100644
index 000000000..3c645af9e
--- /dev/null
+++ b/tasks/customizing-products-images.xml
@@ -0,0 +1,208 @@
+
+
+
+
+ %entities;
+]>
+
+
+
+
+
+
+ Building custom images based on &productname;
+
+
+
+
+ This section provides a brief guide for creating custom images based on &productname;, 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.
+
+
+
+ Downloading files for image customization
+
+ To get the necessary files that define the custom image, proceed as follows:
+
+
+
+
+Navigate to the &osuse; Build Service.
+
+
+
+
+ Download the content of the package SL-Micro.
+
+
+
+
+
+ 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:
+
+
+
+
+ the type of image to be built. For details, refer to the preferences
+ definition.
+
+
+
+
+ repositories to use either the &suse; Open Build Service ones or your custom
+ repositories. For details, refer to the repository
+ definition.
+
+
+
+
+ RPM packages to install. For details, refer to the packages
+ definition.
+
+
+
+
+ scripts to run during the build process. For details, refer to the boot image hook-scripts.
+
+
+
+
+ custom configuration. For details, refer to .
+
+
+
+
+ For a complete specification of the elements, refer to the KIWI image description.
+
+
+
+ Adding custom files
+
+You can add your custom configuration files to the image. To do so, proceed as follows:
+
+
+
+
+Navigate to the directory with the build definition file.
+
+
+
+
+ Create a root directory if it does not exist.
+
+
+
+
+ Inside root, create the directory path where you want your file to be placed.
+
+
+
+
+ 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.
+
+
+
+
+
+ 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 &slea; 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.
+
+
+
+
+ Either download the container image from the registry.
+
+
+ Or you can use KIWI directly after installing it:
+
+ &prompt.sudo;zypper install python3-kiwi
+
+
+
+ Make sure that the target build directory exists.
+
+
+
+
+ Start the container:
+
+ &prompt.user;podman run --privileged -v
+ PATH_TO_DESCRIPTION_FILE:/image:Z -v /dev:/dev
+ registry.suse.com/bci/kiwi:10.2
+
+
+
+ Trigger the build either directly or inside the KIWI container:
+
+ &prompt.sudo;kiwi-ng system build \
+ --description IMAGE_DESCRIPTION \
+ --target-dir OUTPUT_BUILD_DIRECTORY
+
+
+
+If the container was used, exit it by typing exit in the container prompt.
+
+
+
+
+ After the build process completes, check the output build directory with the image.
+
+
+
+
+
+