SUSE Linux Enterprise Micro is normally installed as an independent operating system. With virtualization it is also possible to run multiple instances of SUSE Linux Enterprise Micro on the same hardware.

Most installations are to a local hard disk. Therefore, it is necessary for the hard disk controllers to be available to the installation system. If a special controller (like a RAID controller) needs an extra kernel module, provide a kernel module update disk to the installation system.

Other installation targets may be various types of block devices that provide sufficient disk space and speed to run an operating system. This includes network block devices like iSCSI or SAN. It is also possible to install on network file systems that offer the standard Unix permissions. However, it may be problematic to boot these, because they must be supported by the initramfs before the actual system can start. Such installations can be useful when you need to start the same system in different locations or you plan to use virtualization features like domain migration.

Boot problems may prevent the YaST installer from starting on your system. Another symptom is when your system does not boot after the installation has been completed.

If an unexpected problem occurs during installation, information is needed to determine the cause of the problem. Use the following directions to help with troubleshooting:

To simplify the installation process and avoid accidental installations, the default setting on the installation medium for SUSE Linux Enterprise Micro is that your system is booted from the first hard disk. At this point, an installed boot loader normally takes over control of the system. This means that the boot medium can stay in the drive during the installation. To start the installation, choose one of the installation possibilities in the boot menu of the media.

SUSE Linux Enterprise Micro is normally installed as an independent operating system. With virtualization it is also possible to run multiple instances of SLE Micro on the same hardware. The installation of the VM Host Server is performed like a typical installation with some additional packages.

Most installations are to a local hard disk. Therefore, it is necessary for the hard disk controllers to be available to the installation system. If a special controller (like a RAID controller) needs an extra kernel module, provide a kernel module update disk to the installation system.

Other installation targets may be various types of block devices that provide sufficient disk space and speed to run an operating system. This includes network block devices like iSCSI or SAN. It is also possible to install on network file systems that offer the standard Unix permissions. However, it may be problematic to boot these, because they must be supported by the initramfs before the actual system can start. Such installations can be useful when you need to start the same system in different locations or you plan to use virtualization features like domain migration.

Boot problems may prevent the YaST installer from starting on your system. Another symptom is failure to boot after the installation has been completed.

If an unexpected problem occurs during installation, information is needed to determine the cause of the problem. Use the following directions to help with troubleshooting:

console=tty

To simplify the installation process and avoid accidental installations, the default setting on the installation DVD for SUSE Linux Enterprise Micro is that your system is booted from the first hard disk. At this point, an installed boot loader normally takes over control of the system. This means that the boot DVD can stay in the drive during an installation. To start the installation, choose one of the installation possibilities in the boot menu of the media.

The primary processor on the Raspberry Pi's System-on-Chip (SoC) is the Broadcom VideoCore Graphics Processing Unit (GPU), not the Arm Central Processing Unit (CPU). It is the GPU which starts initializing the hardware from a first-stage boot loader in the on-chip Boot Read-Only Memory (Boot ROM). Only a few configuration options can influence the Boot ROM; see Section 3.6.1.2, “OTP memory”.

The Raspberry Pi 3 hardware does not have any built-in firmware. Instead, its second-stage boot loader firmware bootcode.bin is loaded from the boot medium every time the machine is powered on. It in turn loads the third-stage boot loader start.elf.

The Raspberry Pi 4 hardware has a small Electrically Erasable Programmable Read-Only Memory (EEPROM) for the second-stage boot loader. Apart from that, its boot sequence is similar to that of the Raspberry Pi 3, loading the third-stage boot loader start4.elf from the boot medium.

Warning: EEPROM update on Raspberry Pi 4

An update of the second-stage boot loader can be performed by booting from a specially prepared microSD card.

Only insert boot media that you trust, and verify that no file called recovery.bin is unintentionally present.

If an armstub8.bin file is present, it will be loaded as a fourth-stage boot loader at AArch64 Exception Level 3 (EL3). Otherwise, a minimal integrated stub will be used.

Note: EL3 security considerations

Code loaded for EL3 (often called BL31) will reside in memory, and Linux may attempt hypercalls into EL3 throughout its runtime.

Verify that your boot media have no armstub8.bin file unintentionally present. SUSE Linux Enterprise Micro 5.3 does not include it.

Beware that the Raspberry Pi's SoC does not provide TrustZone secure memory. Both the OS on the CPU and any software on the GPU may access its RAM. It is therefore unsuited for cryptographic EL0-s applications. SUSE Linux Enterprise Micro does not provide an EL1-s Trusted Execution Environment (TEE) for that reason.

SUSE Linux Enterprise Micro for the Raspberry Pi is configured to load a fifth-stage boot loader called Das U-Boot.

3.6.1.2 OTP memory #

  

The SoC also has a very small amount of One-Time Programmable Memory (OTP memory). This can be used to configure some settings, such as whether the Boot ROM should attempt to boot from USB devices or over Ethernet.

This OTP memory is described on the Raspberry Pi Foundation Web site: https://www.raspberrypi.org/documentation/hardware/raspberrypi/otpbits.md

Warning: One-time programmable only

Configuration settings written into OTP memory cannot be reversed.

The most common use case for OTP memory will be enabling USB boot on Raspberry Pi 3 Model B or Compute Module 3.

program_usb_boot_mode=1

There is no battery-backed Real-Time Clock (RTC) on the Raspberry Pi itself.

Note: Time synchronization

The lack of a Real-Time Clock means that Raspberry Pi devices need to be configured to fetch the time from a network server by Network Time Protocol (NTP).

However, base boards for the Raspberry Pi Compute Modules may feature an RTC.

It is also possible to connect an RTC via the GPIO connector, using Hardware Attached on Top (HATs) or other expansion boards.

Either way, check whether the respective RTC chipset is supported by SUSE Linux Enterprise Micro. The connected RTC will need to be described to the operating system via a Device Tree Overlay (Section 3.6.1.1, “Config.txt”).

For other boards and HATs, consult the documentation of the they are shipped with.

The most common method to deploy an operating system onto Raspberry Pi hardware is to copy a pre-installed system image onto a boot medium, usually a microSD card. This is the simplest and easiest method.

SUSE provides a preconfigured bootable image of SUSE Linux Enterprise Micro for Raspberry Pi hardware. This comes with the Btrfs file system, with compression enabled to improve performance and reduce wear on microSD media.

A microSD card with a minimum size of 8 GB is recommended. Faster cards will give better system performance. On the first boot, the operating system automatically expands the file system to fill the card. This means that the first boot will be substantially slower than subsequent boots.

The process of writing the card image onto microSD media is described in the Raspberry Pi Quick Start.

Some models of Raspberry Pi allow booting from USB mass storage devices. This will then allow deploying SUSE Linux Enterprise Micro on Raspberry Pi similar to server platforms.

Installation can be performed from a removable USB medium, such as a memory stick, onto a microSD card in the machine's internal slot. Alternatively, it can be performed from a removable USB medium onto another USB medium, such as a USB-connected hard disk.

Note: USB bandwidth limitations

Note that the Ethernet controller on the Raspberry Pi 3 is connected to the device's on-board USB 2.0 bus.

Therefore an operating system running from a disk attached via USB must share the total 480 Mbps bandwidth of the USB 2.0 controller. This will limit performance, and could significantly impact network performance.

This limitation does not apply to the Raspberry Pi 4.

Newer models of Raspberry Pi 3 with BCM2837 B0 silicon (silver instead of black chip), including Raspberry Pi 3 Model B+ and Compute Module 3+, allow booting from USB-connected storage devices by default.

On older models, such as Raspberry Pi 3 Model B or Compute Module 3, USB boot can be enabled by booting from a specially prepared microSD card once. See Section 3.6.1.2, “OTP memory” for instructions.

Because of the hardware's lack of on-board firmware (Section 3.6.1, “Boot process”), network-booting the Raspberry Pi using PXE is more complex than with more conventional computers.

The process of setting up a PXE boot server for x86 and Arm is described in the SUSE Best Practices document How to Set Up a Multi-PXE Installation Server.

The Raspberry Pi Foundation publishes information on how to boot using PXE one Raspberry Pi from another Raspberry Pi: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

For more information, consult the following resources:

SUSE Linux Enterprise Micro runs on the following platforms:

4.1.1.1 Memory requirements #

  

Different installation methods have different memory requirements during installation. At least 1 GB of memory is recommended for the text-mode installation under z/VM, LPAR, and KVM. Installation in the graphical mode requires at least 1.5 GB of memory.

Note: Memory requirements with remote installation sources

A minimum of 512 MB of memory is required for installation from NFS, FTP, and SMB installation sources, or when VNC is used. Keep in mind that memory requirements also depend on the number of devices visible to the z/VM guest or the LPAR image. Installation with many accessible devices (even if unused for the installation) may require more memory.

Documentation about restrictions and requirements for this release of SUSE Linux Enterprise Server be found on IBM developerWorks at https://developer.ibm.com/technologies/linux/. We recommend to use the highest service level available. Contact IBM support for minimum requirements.

For z/VM, the following versions are supported:

Since it might be necessary to activate the VM APARs before installing the new MicroCode levels, clarify the order of installation with IBM support.

When installing SUSE Linux Enterprise Micro via non-Linux–based NFS or FTP, you might experience problems with NFS or FTP server software. The Windows* standard FTP server can cause errors, so we recommend performing installation via SMB on these machines.

To connect to the SUSE Linux Enterprise Micro installation system, one of the following methods is required (SSH or VNC are recommended):

Tip: More information

Before installing SUSE Linux Enterprise Micro on IBM Z, consult the README file located in the root directory of the first installation medium of SUSE Linux Enterprise Micro. The file complements this documentation.

This section provides detailed information about making the SUSE Linux Enterprise Micro IBM Z installation data accessible for installation. Depending on your computer and system environment, choose between NFS or FTP installation. If you are running Microsoft Windows workstations in your environment, you can use the Windows network (including the SMB protocol) to install SUSE Linux Enterprise Micro on your IBM Z system.

Tip: IPL from DVD

It is possible to IPL from DVD and use the DVD as the installation medium. This is very convenient if you have restrictions setting up an installation server providing installation media over your network. The prerequisite is an FCP-attached SCSI DVD Drive.

Note: No installation from hard disk

It is not possible to perform installation from a hard disk by putting the content of the DVD to a partition on a DASD.

4.2.1.1 Using a Linux workstation or SUSE Linux Enterprise Micro DVD #

  

You can use a Linux workstation in your computer environment to provide the installation data to the IBM Z installation process by NFS or FTP.

Important: Exporting mounted devices with NFS

Exporting the file system root (/) does not automatically export the mounted devices, such as DVD. Therefore, you need to explicitly name the mount point in /etc/exports:

/media/dvd  *(ro)

After changing this file, restart the NFS server with the command sudo systemctl restart nfsserver.

Setting up an FTP server on a Linux system involves the installation and configuration of server software like vsftpd. Downloading the installation data via anonymous login is not supported, therefore you need to configure the FTP server to support user authentication.

4.2.1.1.1 SUSE Linux Enterprise Micro on DVD #

  

The first installation medium of the SUSE Linux Enterprise Micro for IBM Z contains a bootable Linux image for Intel-based workstations and an image for IBM Z.

For Intel-based workstations, boot from this medium. When prompted, choose the desired answer language and keyboard layout and select Start rescue system. You need at least 64 MB RAM for this. No disk space is needed, because the entire rescue system resides in the workstation's RAM. This approach requires setting up the networking of the workstation manually.

For IBM Z, IPL your LPAR/VM guest from this medium as described in Section 4.2.4.1.2, “IPL from FCP-attached SCSI DVD”. After entering your network parameters, the installation system treats the medium as the source of installation data. Because IBM Z cannot have an X11-capable terminal attached directly, choose between VNC or SSH installation. Refer to Section 13.3, “Monitoring installation via VNC” or Section 13.4, “Monitoring installation via SSH” for more information. SSH also provides a graphical installation by tunneling the X connection through SSH with ssh -X.

Important: ssh -X connections between different architectures

By default, recent versions of the X.org and Xwayland servers do not accept connections from clients on different architectures. If you connect to the IBM Z machine from a AMD64/Intel 64 workstation with ssh -X, you will likely see the error message: “Prohibited client endianess, see the Xserver man page”.

To enable X connections between different architectures, create the file /etc/X11/xorg.conf.d/99-byte-swapping.conf with the following content:

Section "ServerFlags"
    Option "AllowByteSwappedClients" "on"
EndSection

Restart your X.org or Xwayland server to apply the configuration change:

> sudo systemctl restart display-manager.service

smb://DOMAIN;USER:PW@SERVERNAME/SHAREPATH

> sudo cobbler import --path=PATH1 --name=IDENTIFIER2 --arch=s390x

> sudo cobbler distro add --arch=s390 --breed=suse --name="IDENTIFIER"1 \
  --os-version=slemicro5.22 \
  --initrd=/srv/www/cobbler/ks_mirror/IDENTIFIER/boot/s390x/initrd3 \
  --kernel=/srv/www/cobbler/ks_mirror/IDENTIFIER/boot/s390x/linux4 \
  --kopts="install=http://cobbler.example.com/cobbler/ks_mirror/IDENTIFIER"5

> sudo cobbler distro edit \
--name=IDENTIFIER1 --os-version=sles102 --ksmeta=""3
--kopts="install=http://cobbler.example.com/cobbler/ks_mirror/IDENTIFIER"4

> sudo cobbler system add --name=linux01 --hostname=linux01.example.com \
--profile=IDENTIFIER --interface=qdio \
--ip-address=192.168.2.103 --subnet=192.168.2.255 --netmask=255.255.255.0 \
--name-servers=192.168.1.116 --name-servers-search=example.com \
--gateway=192.168.2.1 --kopts="KERNEL_OPTIONS"

--kopts=" \
AutoYaST=http://192.168.0.5/autoinst.xml \
Hostname=linux01.example.com \
Domain=example.com \
HostIP=192.168.2.103 \
Gateway=192.168.2.1 \
Nameserver=192.168.1.116 \
Searchdns=example.com \
InstNetDev=osa; \
Netmask=255.255.255.0 \
Broadcast=192.168.2.255 \
OsaInterface=qdio \
Layer2=0 \
PortNo=0 \
ReadChannel=0.0.0700 \
WriteChannel=0.0.0701 \
DataChannel=0.0.0702 \
DASD=600"

4.2.1.4 Installing from a USB Flash Drive of the HMC #

  

Installation of SUSE Linux Enterprise Micro on IBM Z servers usually requires a network installation source. If this requirement cannot be fulfilled, SUSE Linux Enterprise Server allows you to use the USB flash drive of the Hardware Management Console (HMC) as an installation source for installation on an LPAR.

To perform installation from the USB flash drive of the HMC, proceed as follows:

• Add install=hmc:/ to the parmfile (see Section 4.4, “The parmfile—automating the system configuration”) or kernel options.

• In the manual-mode installation using linuxrc, choose Start Installation, then Installation, and then Hardware Management Console. The installation medium must be in the HMC.

Important: Configure network

Before starting the installation, specify a network configuration in linuxrc. You cannot do this via boot parameters, and it is very likely that you will need network access. In linuxrc, go to Start Installation, then choose Network Setup.

Important: Linux system must boot first

Before granting access to the media in the USB flash drive of the HMC, wait until the Linux system is booted. IPLing can disrupt the connection between the HMC and the LPAR. If the first attempt to use the described method fails, you can grant the access and retry the option HMC.

Note: Installation repository

The USB flash drive is not kept as an installation repository, as the installation is a one-time procedure. If you need an installation repository, register and use the online repository.

This section describes SUSE Linux Enterprise Micro installation steps for each installation mode. When the preparation steps described in the previous chapters have been completed, follow the overview of the desired installation mode.

As described in Section 4.2.1, “Making the installation data available”, there are three different installation modes for Linux on IBM Z: LPAR, z/VM, and KVM guest installation.

Wait until the kernel has completed its start-up routines. If you perform the installation in basic mode or in an LPAR, open the Operating System Messages on the HMC or SE.

First, choose Start Installation in the linuxrc main menu. Then choose Start Installation or Update to start the installation process. Select Network as the installation medium, then select the type of network protocol to use for the installation. Section 4.2.1, “Making the installation data available” describes how to make the installation data available for the various types of network connections. Currently, FTP, HTTP, NFS, and SMB/CIFS (Windows file sharing) are supported.

From the list of available devices, choose an OSA or HiperSockets network device for receiving the installation data. Although the list may contain CTC, ESCON, or IUCV devices, they are no longer supported on SUSE Linux Enterprise Micro.

Choose the network device.

 1) IBM parallel CTC Adapter (0.0.0600)
 2) IBM parallel CTC Adapter (0.0.0601)
 3) IBM parallel CTC Adapter (0.0.0602)
 4) IBM Hipersocket (0.0.0800)
 5) IBM Hipersocket (0.0.0801)
 6) IBM Hipersocket (0.0.0802)
 7) IBM OSA Express Network card (0.0.0700)
 8) IBM OSA Express Network card (0.0.0701)
 9) IBM OSA Express Network card (0.0.0702)
10) IBM OSA Express Network card (0.0.f400)
11) IBM OSA Express Network card (0.0.f401)
12) IBM OSA Express Network card (0.0.f402)
13) IBM IUCV

> 4

Device address for read channel. (Enter '+++' to abort).
[0.0.0800]> 0.0.0800

Device address for write channel. (Enter '+++' to abort).
[0.0.0801]> 0.0.0801

Device address for data channel. (Enter '+++' to abort).
[0.0.0802]> 0.0.0802

Choose the network device.

 1) IBM parallel CTC Adapter (0.0.0600)
 2) IBM parallel CTC Adapter (0.0.0601)
 3) IBM parallel CTC Adapter (0.0.0602)
 4) IBM Hipersocket (0.0.0800)
 5) IBM Hipersocket (0.0.0801)
 6) IBM Hipersocket (0.0.0802)
 7) IBM OSA Express Network card (0.0.0700)
 8) IBM OSA Express Network card (0.0.0701)
 9) IBM OSA Express Network card (0.0.0702)
10) IBM OSA Express Network card (0.0.f400)
11) IBM OSA Express Network card (0.0.f401)
12) IBM OSA Express Network card (0.0.f402)
13) IBM IUCV

> 7

Enter the relative port number. (Enter '+++' to abort).
> 0

Device address for read channel. (Enter '+++' to abort).
[0.0.0700]> 0.0.0700

Device address for write channel. (Enter '+++' to abort).
[0.0.0701]> 0.0.0701

Device address for data channel. (Enter '+++' to abort).
[0.0.0702]> 0.0.0702

Enable OSI Layer 2 support?

0) <-- Back <--
1) Yes
2) No

> 1

MAC address. (Enter '+++' to abort).
> +++

Automatic configuration via DHCP?

0) <-- Back <--
1) Yes
2) No

> 2

Enter your IP address with network prefix.

You can enter more than one, separated by space, if necessary.
Leave empty for autoconfig.

Examples: 192.168.5.77/24 2001:db8:75:fff::3/64. (Enter '+++' to abort).
> 192.168.0.20/24

Enter your name server IP address.

You can enter more than one, separated by space, if necessary.
Leave empty if you don't need one.

Examples: 192.168.5.77 2001:db8:75:fff::3. (Enter '+++' to abort).
> 192.168.0.1

Enter your search domains, separated by a space:. (Enter '+++' to abort).
> example.com

Enter the IP address of your name server. Leave empty if you do not need one. (En
ter '+++' to abort).
> 192.168.0.1

After loading the installation system, linuxrc prompts you to choose what type of display to use to control the installation procedure. The available options include Remote X11 (X Window System), VNC (Virtual Network Computing protocol), SSH (text mode or X11 installation via Secure Shell), Text-based UI and Graphical UI. The latter starts YaST in graphical mode on a local graphics display if it exists. On the s390x architecture, a local graphics display can be implemented using QEMU and the virtio-gpu driver.

The recommended options are VNC or SSH.

If the Text-based UI option is selected, YaST starts in text mode, and you can perform the installation directly within your terminal. The Text-based UI option is only useful when installing into LPAR.

Note: Terminal emulation for Text-based UI

To be able to work with YaST in the text mode, it needs to run in a terminal with VT220/Linux emulation (also called Text-based UI).

4.2.6.2 Initiating the installation for the X Window system #

  

Important: X authentication mechanism

The direct installation with the X Window System relies on an authentication mechanism based on host names. This mechanism is disabled in current SUSE Linux Enterprise Micro versions. We recommend performing the installation using SSH or VNC.

To remotely control an installation via X forwarding, follow these steps:

1. Make sure that the X server allows the client (the system that is installed) to connect. Set the variable DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" in the file /etc/sysconfig/displaymanager. Restart the X server and allow client binding to the server using xhost CLIENT_IP_ADDRESS.

2. When prompted at the installation system, enter the IP address of the machine running the X server.

3. Wait until YaST opens, then start the installation.

4.2.6.3 Initiating the installation for SSH #

  

To connect to an installation system with the name earth via SSH, use the ssh -X earth command. If your workstation runs on Microsoft Windows, use the Putty tool available from http://www.chiark.greenend.org.uk/~sgtatham/putty/. Set Enable X11 forwarding in Putty under Connection › SSH › X11.

If you use another operating system, execute ssh -X earth to connect to an installation system with the name earth. X-Forwarding over SSH is supported if you have a local X server available. Otherwise, YaST provides a text interface over ncurses.

When prompted, enter the root user name and log in with your password. Enter yast.ssh to start YaST. YaST then guides you through the installation.

Important: Fixing YaST over SSH issue

In certain situations, running the GUI version of YaST over SSH with X forwarding may fail with the following error message:

XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:11.0"

In this case you have two options.

• Run YaST with the QT_XCB_GL_INTEGRATION=none option, for example:

  QT_XCB_GL_INTEGRATION=none yast.ssh
  QT_XCB_GL_INTEGRATION=none yast2 disk

• Run the ncurses version of YaST application by disabling X forwarding or by specifying ncurses as the desired UI. To do the latter, use the yast2 disk --ncurses or YUI_PREFERED_BACKEND=ncurses yast2 disk command.

Proceed with the installation procedure as described in Chapter 12, Installation steps.

On SLES 10 and 11 the boot process was handled by the zipl boot loader. To enable booting from Btrfs partitions and supporting system rollbacks with Snapper, the way SUSE Linux Enterprise Micro is booted on IBM Z has changed.

GRUB 2 replaces zipl on SUSE Linux Enterprise Micro for IBM Z. GRUB 2 on the AMD64/Intel 64 architecture includes device drivers on the firmware level to access the file system. On the mainframe there is no firmware and adding ccw to GRUB 2 would not only be a major undertaking, but would also require a reimplementation of zipl in GRUB 2. Therefore SUSE Linux Enterprise Micro uses a two-stage approach:

Important: Configuring the network interface

The settings described in this section apply only to the network interface used during installation.

Each of the interfaces requires certain setup options:

I/O device auto-configuration is a mechanism that allows users to specify IDs and settings of I/O devices that should be automatically enabled in Linux. This information is specified for an LPAR via an HMC running in DPM (Dynamic Partition Manager) mode.

Note

The I/O device auto-configuration functionality is available on systems with the DPM running. DPM runs by default on LinuxONE machines. For IBM Z, this functionality must be ordered.

In linuxrc, the DeviceAutoConfig parameter controls the use of I/O device auto-configuration data for IBM Z systems.

If device auto-config is disabled by the user, the kernel parameter rd.zdev=no-auto is added to the boot options of the target system.

To enable I/O auto-configuration using YaST, run the yast2 system_settings command, switch to the Kernel Settings section, and enable the Enable I/O device auto-configuration option.

To disable I/O auto-configuration in an AutoYaST profile, add the following kernel parameter in the append section of the global boot loader options. For example:

<bootloader>
  <global>
    <append>rd.zdev=no-auto</append>
  </global>
</bootloader>

For more context on the AutoYaST boot loader options, see Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.4 “The boot loader”.

During installation, the status of the auto-configuration setting is displayed in the Device Settings section of the Installation Settings screen.

The maximum capacity of a parmfile is 860 characters. As a rule of thumb, the parmfile should contain a maximum of 10 lines with no more than 79 characters. When reading a parmfile, all lines are concatenated without adding white spaces, therefore the last character (79) of each line needs to be a Space.

To receive potential error messages on the console, use

linuxrclog=/dev/console

ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc TERM=dumb
instnetdev=osa osainterface=qdio layer2=1 osahwaddr=
pointopoint=192.168.0.1 hostip=192.168.0.2
nameserver=192.168.0.3 DeviceAutoConfig=1
install=nfs://192.168.0.4/SLES/SLES-12-Server/s390x/DVD1
autoyast=http://192.168.0.5/autoinst.xml
linuxrclog=/dev/console vnc=1 VNCPassword=testing

ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc TERM=dumb
AutoYast=nfs://192.168.1.1/autoinst/s390.xml
Hostname=zsystems.example.com HostIP=192.168.1.2
Gateway=192.168.1.3 Nameserver=192.168.1.4
InstNetDev=hsi layer2=0
Netmask=255.255.255.128 Broadcast=192.168.1.255
readchannel=0.0.702c writechannel=0.0.702d datachannel=0.0.702e
install=nfs://192.168.1.5/SLES-12-Server/s390x/DVD1/
ssh=1 ssh.password=testing linuxrclog=/dev/console

ro ramdisk_size=50000 MANUAL=0 PORTNO=1 ReadChannel=0.0.b140
WriteChannel=0.0.b141 DataChannel=0.0.b142
cio_ignore=all,!condev,!0.0.b140-0.0.b142,!0.0.e92c,!0.0.5000,!0.0.5040
HostIP= Gateway= Hostname=zsystems.example.com nameserver=192.168.0.1
Install=ftp://user:password@10.0.0.1/s390x/SLES15.0/INST/ usevnc=1
vncpassword=12345 InstNetDev=osa Layer2=1 OSAInterface=qdio ssl_certs=0
osahwaddr= domain=example.com self_update=0
vlanid=201

A general coverage of Linux on IBM Z can be found in the following documents:

These documents might not reflect the current state of Linux, but the principles of Linux deployment outlined there remain accurate.

Refer to the following documents for technical information about the Linux kernel and application topics. For the most recent versions of the documents, visit (https://developer.ibm.com/technologies/linux/).

A Redbook for Linux application development is available at http://www.redbooks.ibm.com:

Refer to the following Redbooks, Redpapers, and online resources for more complex IBM Z scenarios:

config.ign is a JSON configuration file that provides prescriptions for Ignition. You can either create the file manually in JSON, or you can use the Fuel Ignition tool (https://opensuse.github.io/fuel-ignition/) to generate a basic set of prescriptions. Bear in mind that the Fuel Ignition tool does not provide a full set of options, so you might have to modify the file manually.

When installing on bare metal, the configuration file config.ign must reside in the ignition subdirectory on the configuration media labeled ignition. The directory structure must look as follows:

<root directory>
└── ignition
  └── config.ign

If you intend to configure a QEMU/KVM virtual machine, provide the path to config.ign as an attribute of the qemu command. For example:

-fw_cfg name=opt/com.coreos/config,file=PATH_TO_config.ign

When configuring a virtual machine with Virtual Machine Manager (libvirt), provide the path to the config.ign file in its XML definition, for example:

<domain ... >
<sysinfo type="fwcfg">
<entry name="opt/com.coreos/config" file="/location/to/config.ign"/>
</sysinfo>
</domain>

Alternatively, when using libvirt, you can provide the path as an option to the virt-install command:

--sysinfo type=fwcfg,entry0.name="opt/com.coreos/config",entry0.file="PATH_TO_config.ign>"

The config.ign file contains various 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 with SLE Micro, its value must be set either to 3.3.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. If you want 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.

7.2.1.1 Configuration examples #

  

This section will provide you with some common examples of the Ignition configuration in the JSON format.

Important: Declaring content outside the default subvolumes

Bear in mind that if you want to create files outside the default mounted directories, you need to define the directories using the filesystem attribute.

Note: The version attribute is mandatory

Include the version specification in config.ign (version 3.3.0 or lower).

7.2.1.1.1 Storage configuration #

  

The storage attribute is used to configure partitions and RAID, define file systems, create files, etc. To define partitions, use the disks attribute. The filesystem 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.

7.2.1.1.1.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 will use a single virtual device and divide the disk into four partitions:

  {
  "variant": "fcos",
  "version": "3.3.0",
  "storage": {
      "disks": [
          {
              "device": "/dev/vda",
              "wipe_table": true,
              "partitions": [
                  {
                      "label": "root",
                      "number": 1,
                      "type_guid": "4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709"
                  },
                  {
                      "label": "boot",
                      "number": 2,
                      "type_guid": "BC13C2FF-59E6-4262-A352-B275FD6F7172"
                  },
                  {
                      "label": "swap",
                      "number": 3,
                      "type_guid": "0657FD6D-A4AB-43C4-84E5-0933C84B4F4F"
                  },
                  {
                      "label": "home",
                      "number": 4,
                      "type_guid": "933AC7E1-2EB4-4F13-B844-0E14E2AEF915"
                  }
              ]
          }
      ]
  }
}

7.2.1.1.1.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

    {
  "variant": "fcos",
  "version": "3.3.0",
  "storage": {
      "raid": [
          {
              "name": "system",
              "level": "raid1",
              "devices": [
                  "/dev/sda",
                  "/dev/sdb"
              ]
          }
      ]
  }
}

7.2.1.1.1.3 The filesystem attribute #

  

Note: Ignition does not perform modifications to mount units

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.

filesystem 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)

Note

In the case of SLE Micro, the root file system must be formatted to Btrfs.

The following example demonstrates using the filesystem attribute. The /opt directory will be mounted to the /dev/sda1 partition, which is formatted to Btrfs. The partition table will not be erased.

{
  "variant": "fcos",
  "version": "3.3.0",
  "storage": {
      "filesystems": [
          {
              "path": "/opt",
              "device": "/dev/sda1",
              "format": "btrfs",
              "wipe_filesystem": false
          }
      ]
  }
}

7.2.1.1.1.4 The files attribute #

  

You can use the files attribute to create any files on your machine. Bear in mind that if you want to create files outside the default mounted directories, you need to define the directories by using the filesystem attribute.

In the following example, a host name is created by using the files attribute. The file /etc/hostname will be created with the slemicro-1 host name.

Note: Decimal numeral systems in JSON

Bear in mind that JSON uses the decimal numeral system, so the mode value is a decimal notation of the access rights.

{
  "variant": "fcos",
  "version": "3.3.0",
  "storage": {
      "files": [
          {
              "path": "/etc/hostname",
              "mode": 420,
              "overwrite": true,
              "contents": {
                  "inline": "slemicro-1"
              }
          }
      ]
  }
}

7.2.1.1.1.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.

{
  "variant": "fcos",
  "version": "3.3.0",
  "storage": {
      "directories": [
          {
              "path": "/mnt/backup",
              "user": {
                  "name": "tux"
              }
          }
      ]
  }
}

7.2.1.1.2 Users administration #

  

The passwd attribute is used to add users. If you intend to log in to your system, create root and set the root's password and/or add the SSH key to the Ignition configuration. You need to hash the root password, 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.

The users attribute must contain at least one name attribute. ssh_authorized_keys is a list of SSH keys for the user.

Note: Creating other users than root

When you are creating other users than root, you need to define /home directories for the users, because these directories (usually /home/USER_NAME) are not mounted by default. Therefore, declare these directories using the storage/filesystem attribute. For example, for tux, the example looks as follows:

      {
"ignition": {
  "version": "3.2.0"
},
"passwd": {
  "users": [
    {
      "name": "tux",
      "passwordHash": "$2a$10$US9XSqLOqMmGq/OnhlVjPOwuZREh2.iEtlwD5LI7DKgV24NJU.wO6"
    }
  ]
},
"storage": {
  "filesystems": [
    {
      "device": "/dev/disk/by-label/ROOT",
      "format": "btrfs",
      "mountOptions": [
        "subvol=/@/home"
      ],
      "path": "/home",
      "wipeFilesystem": false
    }
  ]
}
}

7.2.1.1.3 Enabling systemd services #

  

You can enable systemd services by specifying them in the systemd attribute. The name must be the exact name of a service to be enabled (including the suffix).

{
"ignition": {
  "version": "3.0.0"
},
"systemd": {
  "units": [
    {
      "enabled": true,
      "name": "sshd.service"
    }
  ]
}
}

The script configuration file is a set of commands that are executed on your system in a transactional-update shell. This section provides examples for performing various configuration tasks by using Combustion.

Important: Include interpreter declaration

As the script file is interpreted by shell, start the file with the interpreter declaration on the first line. For example, for 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. 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.

 # combustion: network

#!/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

exec 1>&- 2>&-; wait;

7.3.1.4 Partitioning #

  

SLE Micro raw images are delivered with a default partitioning scheme as described in Section 7.1, “Default partitioning”. You might want to use a different partitioning. The following set of example snippets moves the /home to a different partition.

Note: Performing changes outside of directories included in snapshots

The following script performs changes that are not included in snapshots. If the script fails and the snapshot is discarded, some changes remain visible and cannot be reverted (like the changes to the /dev/vdb device.)

The following snippet creates a GPT with a single partition on the /dev/vdb device:

sfdisk /dev/vdb <<EOF
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

 echo 'root:$5$.wn2BZHlEJ5R3B1C$TAHEchlU.h2tvfOpOki54NaHpGYKwdNhjaBuSpDotD7' | chpasswd -e

7.3.1.6 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

Note

The SSH service must be enabled in case you need to use remote login via SSH. For details, refer to Section 7.3.1.7, “Enabling services”.

 systemctl enable sshd.service

7.3.1.8 Installing packages #

  

Important: Network connection and registering your system might be necessary

As some packages may require additional subscription, you might 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

Note

Bear in mind that you cannot 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. For details, refer to Book “Administration Guide”, Chapter 3 “Administration using transactional updates”.

To activate an extension, proceed as follows:

If you activated the SUSE Linux Enterprise Live Patching extension, you need to perform additional steps as described below:

To deactivate the extension, run the following command:

# transactional-update register -d \
  -p EXTENSION_NAME

For example, for the SUSE Linux Enterprise Live Patching extension, the command is as follows:

# transactional-update register -d \
  -p sle-module-live-patching/15.4/x86_64

The boot screen displays several options for the installation procedure. Boot from Hard Disk boots the installed system and is selected by default, because the CD is often left in the drive. Select one of the other options with the arrow keys and press Enter to boot it. The relevant options are:

Figure 11.1: The boot screen on machines with a traditional BIOS #

  

Use the function keys shown at the bottom of the screen to change the language, screen resolution, installation source or to add an additional driver from your hardware vendor:

UEFI (Unified Extensible Firmware Interface) is a new industry standard which replaces and extends the traditional BIOS. The latest UEFI implementations contain the “Secure Boot” extension, which prevents booting malicious code by only allowing signed boot loaders to be executed.

The boot manager GRUB 2, used to boot machines with a traditional BIOS, does not support UEFI, therefore GRUB 2 is replaced with GRUB 2 for EFI. If Secure Boot is enabled, YaST will automatically select GRUB 2 for EFI for installation. From an administrative and user perspective, both boot manager implementations behave the same and are called GRUB 2 in the following.

Tip: Using additional drivers with Secure Boot

When installing with Secure Boot enabled, you cannot load drivers that are not shipped with SUSE Linux Enterprise Micro. This is also true of drivers shipped via SolidDriver, because their signing key is not trusted by default.

To load drivers not shipped with SUSE Linux Enterprise Micro, do either of the following:

• Before the installation, add the needed keys to the firmware database via firmware/system management tools.

• Use a bootable ISO that will enroll the needed keys in the MOK list on the first boot.

The boot screen displays several options for the installation procedure. Change the selected option with the arrow keys and press Enter to boot it. The relevant options are:

GRUB 2 for EFI on SUSE Linux Enterprise Micro does not support a boot prompt or function keys for adding boot parameters. By default, the installation will be started with American English and the boot media as the installation source. A DHCP lookup will be performed to configure the network. To change these defaults or to add boot parameters you need to edit the respective boot entry. Highlight it using the arrow keys and press E. See the on-screen help for editing hints (note that only an English keyboard is available now). The Installation entry will look similar to the following:

setparams 'Installation'

   set gfxpayload=keep
   echo 'Loading kernel ...'
   linuxefi /boot/x86_64/loader/linux splash=silent
   echo 'Loading initial ramdisk ...'
   initrdefi /boot/x86_64/loader/initrd

Add space-separated parameters to the end of the line starting with linuxefi. To boot the edited entry, press F10. If you access the machine via serial console, press Esc–0. A complete list of parameters is available at https://en.opensuse.org/Linuxrc.

Important: Configuring the network interface

The settings discussed in this section apply only to the network interface used during installation.

The network will only be configured if it is required during the installation. To force the network to be configured, use the netsetup or ifcfg parameters.

If you are not using DVD or USB flash drive for installation, specify an alternative installation source.

Only one of the different remote control methods should be specified at a time. The different methods are: SSH, VNC, remote X server. For information about how to use the parameters listed in this section, see Chapter 13, Remote installation.

By default you can only assign IPv4 network addresses to your machine. To enable IPv6 during installation, enter one of the following parameters at the boot prompt:

In networks enforcing the usage of a proxy server for accessing remote web sites, registration during installation is only possible when configuring a proxy server.

On systems with traditional BIOS, press F4 on the boot screen and set the required parameters in the HTTP Proxy dialog.

On Systems with UEFI BIOS, provide the boot parameter proxy at the boot prompt:

Enabling SELinux upon installation start-up enables you to configure it after the installation has been finished without having to reboot. Use the following parameters:

security=selinux selinux=1

If your screen uses a very high DPI, use the boot parameter QT_AUTO_SCREEN_SCALE_FACTOR. This scales font and user interface elements to the screen DPI.

QT_AUTO_SCREEN_SCALE_FACTOR=1

The boot parameter mitigations lets you control mitigation options for side-channel attacks on affected CPUs. Its possible values are:

auto.  Enables all mitigations required for your CPU model, but does not protect against cross-CPU thread attacks. This setting may impact performance to some degree, depending on the workload.

nosmt.  Provides the full set of available security mitigations. Enables all mitigations required for your CPU model. In addition, it disables Simultaneous Multithreading (SMT) to avoid side-channel attacks across multiple CPU threads. This setting may further impact performance, depending on the workload.

off.  Disables all mitigations. Side-channel attacks against your CPU are possible, depending on the CPU model. This setting has no impact on performance.

Each value comes with a set of specific parameters, depending on the CPU architecture, the kernel version, and on the vulnerabilities that need to be mitigated. Refer to the kernel documentation for details.

Skip this step if you are not installing on IBM Z hardware.

Figure 12.4: DASD disk management #

  

After selecting Configure DASD Disks, an overview lists all available DASDs. To get a clearer picture of the available devices, use the text box located above the list to specify a range of channels to display. To filter the list according to such a range, select Filter.

Specify the DASDs to use for the installation by selecting the corresponding entries in the list. Use Select All to select all DASDs currently displayed. Activate and make the selected DASDs available for the installation by selecting Perform Action › Activate. To format the DASDs, select Perform Action › Format.

Skip this step if you are not installing on IBM Z hardware.

Figure 12.5: Configured zFCP Devices #

  

After selecting Configure zFCP Disks, a dialog with a list of the zFCP disks available on the system opens. In this dialog, select Add to open another dialog in which to enter zFCP parameters.

To make a zFCP disk available for the SUSE Linux Enterprise Micro installation, choose an available Channel Number from the drop-down box. Get WWPNs (World Wide Port Number) and Get LUNs (Logical Unit Number) return lists with available WWPNs and FCP-LUNs, respectively, to choose from. Automatic LUN scanning only works with NPIV enabled.

When completed, exit the zFCP dialog with Next and the general hard disk configuration dialog with Finish to continue with the rest of the configuration.

To make the registration more convenient, you can also store your registration codes on a USB storage device such as a flash disk. YaST will automatically pre-fill the corresponding text box. This is particularly useful when testing the installation or if you need to register many systems or extensions.

Create a file named regcodes.txt or regcodes.xml on the USB disk. If both are present, the XML takes precedence.

In that file, identify the product with the name returned by zypper search --type product and assign it a registration code as follows:

SLEMicro    cc36aae1

<?xml version="1.0"?>
<profile xmlns="http://www.suse.com/1.0/yast2ns"
 xmlns:config="http://www.suse.com/1.0/configns">
  <suse_register>
    <addons config:type="list">
      <addon>
<name>SLEMicro</name>
<reg_code>cc36aae1</reg_code>
      </addon>
     </addons>
  </suse_register>
</profile>

Note: Limitations

Currently flash disks are only scanned during installation or upgrade, but not when registering a running system.

Figure 12.11: Suggested partitioning #

  

Warning: The use of Btrfs and snapshots is mandatory.

SLE Micro requires Btrfs on the root partition with snapshots and Snapper enabled. Snapper is enabled by default—do not disable it afterwards.

In case you need to adjust the partitioning scheme, click the Partitioning menu to open the Suggested partitioning dialog box.

The installer creates a proposal for one of the available disks containing a root partition formatted with Btrfs and a swap partition. If one or more swap partitions have been detected on the available hard disks, these partitions will be used. You have several options to proceed:

12.9.1.1 Expert Partitioner #

  

Figure 12.12: Expert Partitioner #

  

Expert partitioner enables you to set up logical volume management (LVM), configure software RAID and device mapping (DM), encrypt partitions, mount NFS shares and manage tmpfs volumes. To fine-tune settings such as the subvolume and snapshot handling for each Btrfs partition, choose Btrfs.

All existing or suggested partitions on all connected hard disks are displayed in the left part of the Expert Partitioner dialog. Entire hard disks are listed as devices without numbers, such as /dev/sda (or /dev/dasda). Partitions are listed as parts of these devices, such as /dev/sda1 (or /dev/dasda1, respectively). The size, type, encryption status, file system, and mount point of the hard disks and their partitions are also displayed. The mount point describes where the partition appears in the Linux file system tree.

12.9.1.1.1 Partition tables #

  

SUSE Linux Enterprise Micro allows to use and create different partition tables. In some cases the partition table is called disk label. The partition table is important to the boot process of your computer. To boot your machine from a partition in a newly created partition table, make sure that the table format is supported by the firmware.

To change the partition table, click the relevant disk name in the left part and choose Device › Create New Partition Table. You can create the following partition tables:

Master boot record

The master boot record (MBR) is the legacy partition table used on IBM PCs. It is sometimes also called an MS-DOS partition table. The MBR only supports four primary partitions. If the disk already has an MBR, SUSE Linux Enterprise Micro allows you to create additional partitions in it which can be used as the installation target.

The limit of four partitions can be overcome by creating an extended partition. The extended partition itself is a primary partition and can contain more logical partitions.

GPT partition table

UEFI computers use a GUID Partition Table (GPT) by default. SUSE Linux Enterprise Micro will create a GPT on a disk if no other partition table exists.

Old BIOS firmware does not support booting from GPT partitions.

You need a GPT partition table to use more than four primary partitions, UEFI Secure Boot or use disks larger than 2 TB.

12.9.1.1.2 Creating partitions #

  

The expert partitioner enables you to add partitions. Bear in mind that the root file system must be formatted to Btrfs and snapshots must be enabled.

The procedure below creates a Btrfs partition with enabled snapshots.

1. Select the desired hard disk in the left part and click Add Partition.

2. Define size of the partition or define the region of disk for the partition. Proceed with Next

   

3. Select a role:

   

4. Format and mount the partition as needed and proceed with Next:

   

5. (Optional) If you chose to encrypt the partition, enter the encryption password and complete the process with Next:

   

12.9.1.1.3 Creating volume groups #

  

To create a volume group follow these steps:

Procedure 12.1: Creating volume groups #

  

1. Create partitions with the following attributes:

   • the partitions are not mounted

   • PartitionID is Linux LVM

2. Click LVM Volume Groups › Add Volume Group

3. Select partitions to be added to the volume group and click Add. Name the volume group, select the Physical Extent Size and click Next to proceed further.

   

12.9.1.1.4 Creating RAIDs #

  

SLE Micro supports the following RAID levels: 0, 1, 5, 6 and 10. To create a RAID follow proceed as follows:

Procedure 12.2: Creating RAID #

  

1. Create partitions (the count of partitions depend on the RAID level) with these parameters:

   • The partitions have the Raw Volume role assigned.

   • The partitions are not formatted to any file system.

   • The partitions are not mounted.

   • The partitions have the Linux RAID PartitionID.

2. Click RAID in the left pane and then click Add RAID. The Add RAID dialog box opens.

3. Choose the partitions and add them to the RAID. Select RAID level and optionally you can name the RAID. Proceed with Next.

   

4. Select the Chunk Size. The default value is usually sufficient. Click Next.

5. In the Device Overview select the created RAID and click Edit.

6. Select a role of the RAID and click Next.

7. Format and mount the device and optionally you can select that the RAID will be encrypted.

Figure 12.13: Software configuration #

  

SUSE Linux Enterprise Micro contains several software patterns for various application purposes. Click Software to open the Software Selection and System Tasks screen where you can modify the pattern selection according to your needs. Select a pattern from the list and see a description in the right-hand part of the window.

In this menu you can select the Web based remote system managment pattern that will install Cockpit system. Cockpit is a web monitoring tool that enables you to administer your system. For details, refer to Article “Cockpit Guide”, Section 2 “Getting Cockpit”.

Here you can also select the KVM Virtualization Host pattern to install packages required to run SLE Micro as a KVM host server (Xen is not supported). However, you should consider the limitations of SLE Micro running as a KVM host server; for details, refer to virtualization limits and support.

Each pattern contains several software packages needed for specific functions (for example Podman). For a more detailed selection based on software packages to install, select Details to switch to the YaST Software Manager.

Figure 12.14: Time zone configuration #

  

By default, the time is synchronized by using the NTP servers you provided in the previous steps of the installation procedure. You can select the region and time zone either by clicking a particular place on the map or by selecting a region and time zone in the drop-down menus.

Important: Set the hardware clock to UTC

The switch from standard time to daylight saving time (and vice versa) can only be performed automatically when the hardware clock (CMOS clock) is set to UTC. This also applies if you use automatic time synchronization with NTP, because automatic synchronization will only be performed if the time difference between the hardware and system clock is less than 15 minutes.

Since a wrong system time can cause serious problems, it is strongly recommended to always set the hardware clock to UTC.

The button Other settings enables you to set the date and time manually or configure NTP servers synchronization.

If you want to set the time and date manually, click the Other settings button and select Manually.

Note: Time cannot be changed on IBM Z

Since the operating system is not allowed to change time and date directly, the Other Settings option is not available on IBM Z.

Network is automatically configured at the beginning of the installation process, but if it is necessary you can change the configuration by clicking Network Configuration. A dialog box opens, for details refer to Section 12.2, “Network settings”.

SLE Micro uses NetworkManager by default, but you can switch to wicked by clicking switch to wicked. Bear in mind that after the installation is complete, you cannot switch the network managing service to NetworkManager.

Figure 12.15: Booting #

  

The installer proposes a boot configuration for your system. Other operating systems found on your computer, such as Microsoft Windows or other Linux installations, will automatically be detected and added to the boot loader. However, SUSE Linux Enterprise Micro will be booted by default. Normally, you can leave these settings unchanged. If you need a custom setup, modify the proposal according to your needs.

Important: Software RAID 1

Booting a configuration where /boot resides on a software RAID 1 device is supported, but it requires installing the boot loader into the MBR (Boot Loader Location › Boot from Master Boot Record). Having /boot on software RAID devices with a level other than RAID 1 is not supported.

Figure 12.16: Kdump configuration #

  

Using Kdump, you can save a dump of the kernel (in case of a crash) to analyze what went wrong. By default, Kdump is enabled. By clicking Kdump you open a dialog box for configuring Kdump.

Figure 12.17: System overview #

  

This screen lists all the hardware information the installer could obtain about your computer. When opened for the first time, the hardware detection is started. Depending on your system, this may take some time. Select any item in the list and click Details to see detailed information about the selected item. Use Save to File to save a detailed list to either the local file system or a removable device.

Advanced users can also change the PCI ID Setup and kernel settings by choosing Kernel Settings. A screen with two tabs opens:

Figure 12.18: Security configuration #

  

Important: Do not use firewall along with Podman

Using firewall along with Podman may result in missing Podman-related firewall rules after reloading the firewalld service. Therefore, it is recommended to keep the firewall in its default setting (disabled) if you intend to use Podman.

You can enable the firewall or disable the SSH service directly by clicking the respective button. Clicking on the button next to CPU mitigations opens the Boot Loader Settings dialog box, where you can change kernel parameters including the CPU mitigations configuration.

The CPU Mitigations refer to kernel boot command line parameters for software mitigations that have been deployed to prevent CPU side-channel attacks. You can configure the following values:

By default, the firewall is disabled. Click enable to change the default.

The SSH service is enabled by default. Click disable to change the setting. If you disable the SSH service, you will not be able to login to your system remotely. The SSH port (22) is open by default.

The default SELinux option is permissive. You can change the value by clicking Security and selecting another option in the Mode menu.

In the Security dialog box, you can also select PolicyKit privileges in the PolicyKit Default Privilegs dropdown menu.