Deploying SUSE Linux Micro Using Network PXE Boot
- WHAT?
SUSE Linux Micro provides images that can be deployed remotely using the PXE boot of the target device.
- WHY?
You want to deploy SUSE Linux Micro remotely.
- EFFORT
It takes about 15 minutes to read the article.
- GOAL
A properly configured instance of SUSE Linux Micro.
- REQUIREMENTS
A properly configured DHCP server
An installed TFTP server
1 Introduction to the PXE installation of SUSE Linux Micro #
SUSE Linux Micro can be installed via a Preboot Execution Environment (PXE). The client hardware needs to support booting via PXE. The network needs to provide a DHCP server and a TFTP server providing the required data to the clients.
The deployment procedure can be summarized to the following steps:
(Optional) To perform a more complex firstboot configuration or installation without user interaction, prepare the firstboot configuration used by Combustion or Ignition. For example, you can define users of the system, install packages, configure host name, register the system and many other task. For details, refer to Section 2.2, “Configuring SUSE Linux Micro deployment with Combustion” or Section 2.3, “Configuring SUSE Linux Micro deployment with Ignition”.
Make sure the DHCP server is configured properly.
Prepare the TFTP server by adding the installation image, configuring the boot settings, and placing the Combustion/Ignition configuration on the TFTP server. For details, refer to Section 3, “Preparing the TFTP server”.
On the target machine select PXE boot and boot the machine. For details, refer to Section 4, “Deploying the image remotely”.
2 Creating firstboot configuration #
The following sections provide information about two tools that you can use to configure SUSE Linux Micro on the first boot. You can use either Combustion and write a configuration BASH script, or you can use Ignition and use JSON. Alternatively, if you do not need a complex configuration or unattended configuration, you can skip this step as basic configuration can be performed using JeOS Firstboot as described in Section 4.1, “Configuring SUSE Linux Micro with JeOS Firstboot”.
2.1 First boot detection #
The deployment configuration runs on the first boot only. To distinguish
between the first and subsequent boots, the file
/etc/machine-id
is created after the
first boot finishes. If the file is not present in the file system, the system assumes that
this is a first boot and triggers the configuration process. After completing the first boot, the
/etc/machine-id
file is
created.
/etc/machine-id
file is always created
Even though the configuration may not be successful because of improper
or missing configuration files, the
/etc/machine-id
file is
created.
2.1.1 Force system reconfiguration on a subsequent boot #
If you need to reconfigure your system after the first boot happened, you can force the reconfiguration on the subsequent boot. Here you have two options.
You can pass the
ignition.firstboot
orcombustion.firstboot
attribute to the kernel command line.You can delete the file
/etc/machine-id
and reboot the system.
2.2 Configuring SUSE Linux Micro deployment with Combustion #
Combustion is a dracut module that enables you to configure your system on the first boot. You can use Combustion, for example, to change the default partitions, set user passwords, create files, or install packages.
2.2.1 How does Combustion work? #
Combustion is invoked after the ignition.firstboot
argument is passed to the kernel command line. Combustion reads a
provided file named script
, executes included
commands, and thus performs changes to the file system. If
script
includes the network flag, Combustion tries
to configure the network. After /sysroot
is mounted,
Combustion tries to activate all mount points in
/etc/fstab
and then calls
transactional-update
to apply other changes, for
example, setting root
password or installing packages.
The configuration script must reside on the TFTP server and during the boot, its URL must be
provided to the kernel using the combustion.url
parameter. For details,
refer to Section 3, “Preparing the TFTP server”.
Combustion can be used along with Ignition. If you intend to do
so, label your configuration medium ignition
and
include the ignition
directory with the
config.ign
to your directory structure as shown
below:
<root directory> └── combustion └── script └── other files └── ignition └── config.ign
In this scenario, Ignition runs before Combustion.
2.2.2 Combustion configuration examples #
2.2.2.1 The script
configuration file #
The script
configuration file is a set of commands
that are parsed and executed by Combustion in a transactional-update
shell. This
article provides examples of configuration tasks performed by
Combustion.
To create the Combustion script, you can use the Fuel Ignition Web application. There you can select appropriate parameters and the application generates a Combustion script that you can download.
As the script
file is interpreted by the shell,
always start the file with the interpreter declaration on its first
line. For example, in case of Bash:
#!/bin/bash
To log in to your system, include at least the root
password.
However, it is recommended to establish the authentication using SSH
keys. If you need to use a root
password, make sure to configure a
secure password. For a randomly generated password, use at least 10
characters. If you create your password manually, use even more than 10
characters and combine uppercase and lowercase letters and numbers.
2.2.2.1.1 Default partitioning #
Each image has the following subvolumes:
/home /root /opt /srv /usr/local /var
The /etc
directory is mounted as overlayFS, where the
upper directory is mounted to /var/lib/overlay/1/etc/
.
You can recognize the subvolumes mounted by default by the option
x-initrd.mount
in /etc/fstab
. Other
subvolumes or partitions must be configured either by Ignition or
Combustion.
If you want to add a new user or modify any of the files on a subvolume that is not mounted by default, you need to declare such subvolume first so that it is mounted as well.
2.2.2.1.2 Network configuration #
To configure and use the network connection during the first boot, add
the following statement to script
:
# combustion: network
Using this statement passes the rd.neednet=1
argument to dracut. The network configuration defaults to using DHCP.
If a different network configuration is needed, proceed as described in
Section 2.2.2.1.3, “Performing modifications in the initramfs”.
If you do not use the statement, the system remains configured without any network connection.
2.2.2.1.3 Performing modifications in the initramfs #
You may need to perform changes to the initramfs environment, for
example, to write a custom network configuration for NetworkManager into
/etc/NetworkManager/system-connections/
. To do so,
use the prepare
statement.
For example, to create a connection with a static IP address and configure DNS:
#!/bin/bash # combustion: network prepare set -euxo pipefail nm_config() { umask 077 # Required for NM config mkdir -p /etc/NetworkManager/system-connections/ cat >/etc/NetworkManager/system-connections/static.nmconnection <<-EOF [connection] id=static type=ethernet autoconnect=true [ipv4] method=manual dns=192.168.100.1 address1=192.168.100.42/24,192.168.100.1 EOF } if [ "${1-}" = "--prepare" ]; then nm_config # Configure NM in the initrd exit 0 fi # Redirect output to the console exec > >(exec tee -a /dev/tty0) 2>&1 nm_config # Configure NM in the system curl example.com # Close outputs and wait for tee to finish exec 1>&- 2>&-; wait; # Leave a marker echo "Configured with combustion" > /etc/issue.d/combustion
2.2.2.1.4 Waiting for the task to complete #
Some processes may be run in background, for example, the tee
process
that redirects output to the terminal. To ensure that all running processes are completed before the
script
execution finishes, add the following line:
exec 1>&- 2>&-; wait;
2.2.2.1.5 Partitioning #
SUSE Linux Micro raw images are delivered with a default partitioning
scheme. You might want to
use a different partitioning. The following set of example snippets
moves the /home
to a different partition.
The following script performs changes that are not included in
snapshots. If the script fails and the snapshot is discarded, certain
changes remain visible and cannot be reverted, for example, the
changes to the /dev/vdb
device.
The following snippet creates a GPT partitioning schema with a single
partition on the /dev/vdb
device:
sfdisk /dev/vdb <<EOF sleep 1 label: gpt type=linux EOF partition=/dev/vdb1
As the sfdisk
command may take longer time to complete, postpone
label
by using the
sleep
command after sfdisk
.
The partition is formatted to Btrfs:
wipefs --all ${partition} mkfs.btrfs ${partition}
Possible content of /home
is moved to the new
/home
folder location by the following snippet:
mount /home mount ${partition} /mnt rsync -aAXP /home/ /mnt/ umount /home /mnt
The snippet below removes an old entry in
/etc/fstab
and creates a new entry:
awk -i inplace '$2 != "/home"' /etc/fstab echo "$(blkid -o export ${partition} | grep ^UUID=) /home btrfs defaults 0 0" >>/etc/fstab
2.2.2.1.6 Creating new users #
As some services, such as Cockpit, require login using a non-root user, define at least one unprivileged user here. Alternatively, you can create such a user from a running system as described in Section 5.2, “Adding users”.
To add a new user account, first create a hash string that represents
the user's password. Use the openssl passwd -6
command.
After you obtain the password hash, add the following lines to the
script
:
mount /home useradd -m EXAMPLE_USER echo 'EXAMPLE_USER:PASSWORD_HASH' | chpasswd -e
2.2.2.1.7 Setting a password for root
#
Before you set the root
password, generate a hash of the
password, for example, by using the openssl passwd
-6
. To set the password, add the following line to the
script
:
echo 'root:PASSWORD_HASH' | chpasswd -e
2.2.2.1.8 Adding SSH keys #
The following snippet creates a directory to store the root
's SSH
key and then copies the public SSH key located on the configuration
device to the authorized_keys
file.
mkdir -pm700 /root/.ssh/ cat id_rsa_new.pub >> /root/.ssh/authorized_keys
The SSH service must be enabled in case you need to use remote login via SSH. For details, refer to Section 2.2.2.1.9, “Enabling services”.
2.2.2.1.9 Enabling services #
To enable system services, for example, the SSH service, add the
following line to script
:
systemctl enable sshd.service
2.2.2.1.10 Installing packages #
As certain packages may require additional subscription, you may need to register your system beforehand. An available network connection may also be needed to install additional packages.
During the first boot configuration, you can install additional
packages to your system. For example, you can install the
vim
editor by adding:
zypper --non-interactive install vim-small
Bear in mind that you will not be able to use
zypper
after the configuration is complete and you
boot to the configured system. To perform changes later, you must use
the transactional-update
command to create a
changed snapshot.
2.3.1 How does Ignition work? #
When the system is booted for the first time, Ignition is loaded as
part of an initramfs
and searches for a
configuration file within a specific directory (on a USB flash disk, or
you can provide a URL). All changes are performed before the kernel
switches from the temporary file system to the real root file system
(before the switch_root
command is issued).
Ignition uses a configuration file in the JSON format named
config.ign
. You can either write the configuration
manually or use the Fuel Ignition Web application at
https://ignite.opensuse.org to generate it.
Fuel Ignition does not cover the complete Ignition vocabulary yet, and the resulting JSON file may need additional manual tweaking.
2.3.1.1 config.ign
#
The config.ign
contains multiple data types:
objects, strings, integers, booleans and lists of objects. For a
complete specification, refer to
Ignition
specification v3.3.0.
The version
attribute is mandatory and in case of
SUSE Linux Micro, its value must be set either to
3.4.0
or to any lower version. Otherwise, Ignition
will fail.
To log in to your system as root
, you must at least
include a password for root
. However, it is recommended to
establish access via SSH keys. To configure a password, make sure to
use a secure one. If you use a randomly generated password, use at
least 10 characters. If you create your password manually, use even
more than 10 characters and combine uppercase and lowercase letters and
numbers.
2.3.2 Ignition configuration examples #
This section provides several examples of the Ignition configuration in the built-in JSON format.
version
attribute is mandatory
Each config.ign
must include version 3.4.0 or
lower that is then converted to the corresponding Ignition
specification.
2.3.2.1 Default partitioning #
Each image has the following subvolumes:
/home /root /opt /srv /usr/local /var
The /etc
directory is mounted as overlayFS, where the
upper directory is mounted to /var/lib/overlay/1/etc/
.
You can recognize the subvolumes mounted by default by the option
x-initrd.mount
in /etc/fstab
. Other
subvolumes or partitions must be configured either by Ignition or
Combustion.
If you want to add a new user or modify any of the files on a subvolume that is not mounted by default, you need to declare such subvolume first so that it is mounted as well.
2.3.2.2 Storage configuration #
The storage
attribute is used to configure
partitions, RAID, define file systems, create files, etc. To define
partitions, use the disks
attribute. The
filesystems
attribute is used to format partitions. The
files
attribute can be used to create files in the
file system. Each of the mentioned attributes is described in the
following sections.
2.3.2.2.1 The disks
attribute #
The disks
attribute is a list of devices that
enables you to define partitions on these devices. The
disks
attribute must contain at least one
device
, other attributes are optional. The
following example uses a single virtual device and divides the
disk into four partitions:
{ "ignition": { "version": "3.0.0" }, "storage": { "disks": [ { "device": "/dev/vda", "partitions": [ { "label": "root", "number": 1, "typeGuid": "4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709" }, { "label": "boot", "number": 2, "typeGuid": "BC13C2FF-59E6-4262-A352-B275FD6F7172" }, { "label": "swap", "number": 3, "typeGuid": "0657FD6D-A4AB-43C4-84E5-0933C84B4F4F" }, { "label": "home", "number": 4, "typeGuid": "933AC7E1-2EB4-4F13-B844-0E14E2AEF915" } ], "wipeTable": true } ] } }
2.3.2.2.2 The raid
attribute #
The raid
is a list of RAID arrays. The following
attributes of raid
are mandatory:
- level
a level of the particular RAID array (linear, raid0, raid1, raid2, raid3, raid4, raid5, raid6)
- devices
a list of devices in the array referenced by their absolute paths
- name
a name that will be used for the md device
For example:
{ "ignition": { "version": "3.0.0" }, "storage": { "raid": [ { "devices": [ "/dev/sda", "/dev/sdb" ], "level": "raid1", "name": "system" } ] } }
2.3.2.2.3 The filesystems
attribute #
The file system
attribute does not modify mount units. If you add a new partition or remove an
existing partition, you must manually adjust the mount units.
filesystems
must contain the following attributes:
- device
the absolute path to the device, typically
/dev/sda
in case of physical disk- format
the file system format (Btrfs, Ext4, xfs, vfat or swap)
NoteIn case of SUSE Linux Micro, the
root
file system must be formatted to Btrfs.
The following example demonstrates using the
filesystems
attribute. The
/opt
directory will be mounted to the
/dev/sda1
partition, which is formatted to Btrfs.
The device will not be erased.
For example:
{ "ignition": { "version": "3.0.0" }, "storage": { "filesystems": [ { "device": "/dev/sda1", "format": "btrfs", "path": "/opt", "wipeFilesystem": false } ] } }
Normally, a regular user's home directory is located in the
/home/USER_NAME
directory. Since /home
is not mounted by default
in the initrd, the mount has to be explicitly defined for the user
creation to succeed:
{ "ignition": { "version": "3.1.0" }, "passwd": { "users": [ { "name": "root", "passwordHash": "PASSWORD_HASH", "sshAuthorizedKeys": [ "ssh-rsa SSH_KEY_HASH" ] } ] }, "storage": { "filesystems": [ { "device": "/dev/sda3", "format": "btrfs", "mountOptions": [ "subvol=/@/home" ], "path": "/home", "wipeFilesystem": false } ] } }
2.3.2.2.4 The files
attribute #
You can use the files
attribute to create any
files on your machine. Bear in mind that to create files
outside the default partitioning schema, you need to define the
directories by using the filesystems
attribute.
In the following example, a host name is created by using the
files
attribute. The file
/etc/hostname
will be created with the
sl-micro1 host name:
Keep in mind that JSON accepts file modes in decimal numbers, for
example, 420
.
JSON:
{ "ignition": { "version": "3.0.0" }, "storage": { "files": [ { "overwrite": true, "path": "/etc/hostname", "contents": { "source": "data:,sl-micro1" }, "mode": 420 } ] } }
2.3.2.2.5 The directories
attribute #
The directories
attribute is a list of directories
that will be created in the file system. The
directories
attribute must contain at least one
path
attribute.
For example:
{ "ignition": { "version": "3.0.0" }, "storage": { "directories": [ { "path": "/home/tux", "user": { "name": "tux" } } ] } }
2.3.2.3 Users administration #
The passwd
attribute is used to add users. As some services, such as Cockpit, require login using a non-root user, define at
least one unprivileged user here. Alternatively, you can create such a user from a running
system as described in Section 5.2, “Adding users”.
To log in to your system, create root
and a regular user and set their
passwords. You need to hash the passwords, for example, by
using the openssl
command:
openssl passwd -6
The command creates a hash of the password you chose. Use this hash as
the value of the password_hash
attribute.
For example:
{ "ignition": { "version": "3.0.0" }, "passwd": { "users": [ { "name": "root", "passwordHash": "PASSWORD_HASH", "sshAuthorizedKeys": [ "ssh-rsa SSH_KEY_HASH USER@HOST" ] } ] } }
The users
attribute must contain at least one
name
attribute.
ssh_authorized_keys
is a list of ssh keys for the
user.
2.3.2.4 Enabling systemd
services #
You can enable systemd
services by specifying them in the
systemd
attribute.
For example:
{ "ignition": { "version": "3.0.0" }, "systemd": { "units": [ { "enabled": true, "name": "sshd.service" } ] } }
3 Preparing the TFTP server #
To deploy SUSE Linux Micro using the PXE client, you need to perform the following steps:
Review the
tftpd
configuration in/etc/sysconfig/tftp
and add or change options as required. Refer toman 8 tftpd
for more details. The TFTP daemon works without changing the configuration. The default root directory for the files is/srv/tftpboot
.Ensure that
tftpd
is started at boot time, and restart it to read the new configuration.>
sudo
systemctl enable tftp.socket
>
sudo
systemctl restart tftp.socket
Ensure that
tftp.socket
remains active during the whole deployment process, which may take several minutes.Prepare the directory structure:
>
sudo
mkdir /srv/tftpboot/sl-microNavigate to the directory:
>
cd /srv/tftpboot/sl-micro
Download the
SL-Micro.ARCHITECTURE-6.1-IMAGE_TYPE-GM.install.tar
to the TFTP server.Unpack the TAR file:
>
sudo
tar xvf IMAGE_TAR -C .
Make sure that all necessary files are present in the
/srv/tftpboot/sl-micro
:>
ls
pxeboot.SL-Micro.ARCH-VERSION.kernel pxeboot.SL-Micro.ARCH-VERSION.initrd SL-Micro.ARCH-VERSION.append SL-Micro.ARCH-VERSION.config.bootoptions SL-Micro.ARCH-VERSION.initrd SL-Micro.ARCH-VERSION.kernel SL-Micro.ARCH-VERSION.md5 SL-Micro.ARCH-VERSION.xzCreate symlinks as follows:
>
sudo
ln -s pxeboot.*.kernel linux
>
sudo
ln -s pxeboot.*.initrd initrd
(Optional) Create directories for the first boot configuration: for Combustion and/or Ignition configuration:
for the Combustion configuration:
#
mkdir combustion
for the Ignition configuration:
#
mkdir ignition
Place the Combustion and/or Ignition configuration to corresponding directories.
Adjust/add the following parameters in the
SL-Micro.ARCH-.append
file:rd.kiwi.install.image
– provide the path to the installation imageSL-Micro.ARCH.xz
. The path must include the protocol, IP address and the relative path to the installation image:tftp://TFTP_SERVER/sl-micro/IMAGE_NAME
If the TFTP root directory is defined, make sure to omit it from the path. The default directory
/srv/tftboot
can be configured in/etc/sysconfig/tftp
, or you can specify the directory in a service unit file attribute that defines the binary to run using the-s
option.rd.kiwi.oem.installdevice
– enables you to perform unattended installation.rd.kiwi.install.pass.bootparam
– after the image is copied to the target disk, kiwi performs a kexec. This parameter instructs kiwi that it must pass additional parameters to the kernel. For example, the below described ones.combustion.url
– if needed, provide a full URL to the Combustion script that is passed to the kernel CLI.ignition.config.url
– if needed, provide a full URL to the Ignition configuration file that is passed to the kernel CLI. Can be used along with Combustion.
Adjust the
/srv/tftpboot/pxelinux.cfg/default
file to include SUSE Linux Micro:LABEL Install SUSE Linux Micro LINUX sl-micro/linux INITRD sl-micro/initrd APPEND PATH_TO_APPEND_FILE
4 Deploying the image remotely #
After you prepared the DHCP and TFTP servers, you can start deployment of SUSE Linux Micro on the target machine.
Power on the target machine.
Enter the UEFI boot menu and select PXE booting.
The machine should start the deployment. Kernel and initrd are downloaded from the TFTP. Boot loader is started.
Select
Install SUSE Linux Micro
. This item may be different if you used a differentLABEL
value in/srv/tftpboot/pxelinux.cfg/default
.Select a disk to deploy SUSE Linux Micro and confirm deleting data on that device. The image is then copied to the disk.
Using Kexec, your system reboots and is then prepared for the configuration process.
Start the configuration process by selecting Section 4.1, “Configuring SUSE Linux Micro with JeOS Firstboot”.
. If the Ignition or Combustion instructions have not been provided, JeOS Firstboot is triggered. For details, refer to
4.1 Configuring SUSE Linux Micro with JeOS Firstboot #
To configure the system with JeOS Firstboot, proceed as follows:
Enter.
displays a welcome screen. Confirm withOn the next screens, select keyboard, confirm the license agreement and select the time zone.
In the
dialog window, enter a password for theroot
and confirm it.Figure 1: Enter root password #(Optional) To enroll SSH keys for access, press Yes. If you pressed YES, proceed as described below:
Using SSH, connect to the displayed IP address.
If you received a public key properly, confirm it in the next screen.
A prompt to import an SSH key appears. Select the option according to your preferences.
(Optional) If desired, you can create an unprivileged user in the
User Creation
form. Fill in the user name, full name and a password twice. Confirm with OK.(Optional) To set up MFA for accessing Cockpit, open a TOTP application and scan the QR code. Enter the OTP value provided by the application. Proceed with OK.
After successful deployment, register your system as described in Section 5.1, “Registering SUSE Linux Micro from CLI”.
5 Post-deployment steps #
5.1 Registering SUSE Linux Micro from CLI #
After successful deployment, you need to register the system to get
technical support and receive updates. Registering the system is
possible from the command line using the transactional-update
register
command.
To register SUSE Linux Micro with SUSE Customer Center, proceed as follows:
Run
transactional-update register
as follows:#
transactional-update register -r REGISTRATION_CODE -e EMAIL_ADDRESSTo register with a local registration server, additionally provide the URL to the server:
#
transactional-update register -r REGISTRATION_CODE -e EMAIL_ADDRESS \ --url "https://suse_register.example.com/"Replace REGISTRATION_CODE with the registration code you received with your copy of SUSE Linux Micro. Replace EMAIL_ADDRESS with the e-mail address associated with the SUSE account you or your organization uses to manage subscriptions.
Reboot your system to switch to the latest snapshot.
SUSE Linux Micro is now registered.
For information that goes beyond the scope of this section, refer to the
inline documentation with SUSEConnect --help
.
5.2 Adding users #
Since SUSE Linux Micro requires having an unprivileged user to log in via SSH or to access Cockpit by default, we recommend to create such an account.
This step is optional if you have defined an unprivileged user during the deployment of the system. If not, you can proceed as described below:
Run the
useradd
command as follows:#
useradd -m USER_NAME
Set a password for that account:
#
passwd USER_NAMEIf needed, add the user to the
wheel
group:#
usermod -aG wheel USER_NAME
6 Legal Notice #
Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.