Deploying SLE Micro Using Raw Disk Images on IBM Z DASD Disks
- WHAT?
SUSE Linux Enterprise Micro provides raw images (also referred to as pre-built images) that can be deployed directly to your device storage.
- WHY?
This article provides you with step-by-step instructions on deploying SUSE Linux Enterprise Micro on an IBM Z machine.
- EFFORT
It takes approximately 20 minutes to read the article.
- GOAL
SUSE Linux Enterprise Micro is successfully deployed on your system.
- REQUIREMENTS
A disk with running Linux.
A disk where you deploy the raw image and where SUSE Linux Enterprise Micro will run.
A disk that serves as a configuration medium.
1 About pre-built images #
Pre-built images are ready-to-use representations of a running operating system. They are not installed in a traditional way using an installer, but copied to the hard disk of the target host. The topic covers basic information about these pre-built images.
The pre-built images are intended to be configured on the first boot by using tools delivered in the images. The boot loader detects the first boot as described in Section 1.1, “First boot detection”.
1.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.
1.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 Deployment of SLE Micro #
The deployment procedure of SLE Micro comprises three phases. Do not skip any of the phases and follow the order as stated below.
DASD disks activation—before you start the deployment, you need to ensure that all disks to be used are available and active. For details, refer to Section 3.1, “Preparing the DASD disks”.
Preparing a configuration device—to configure the network, add users and register the system, prepare the configuration according to the instructions provided in Section 4, “Preparing the configuration disk”.
Downloading the SLE Micro image and deploying it on the disk. For details, refer to Section 5, “Deploying the raw disk image on the disk”.
3 Preparing the machine #
3.1 Preparing the DASD disks #
Before you start deploying SLE Micro, you need to check if all the three needed DASD disks are active. To check the disks' state, run the command:
#
lsdasd
Bus-ID Status Name Device Type BlkSz Size Blocks
================================================================================
0.0.0100 active dasda 94:0 ECKD 4096 30720MB 7864380
0.0.0101 active dasdc 94:8 ECKD 4096 20480MB 5243040
0.0.0102 active dasdb 94:4 ECKD 4096 5120MB 1310760
The 5 GB disk will be used as a configuration device, and the 20 GB disk is the disk where SUSE Linux Enterprise Micro will be deployed.
If you do not see the disks in the command output, you need to activate the disks. To do so, proceed as follows:
Run the
lszdev dasd
to display a full list of devices:#
lszdev dasd TYPE ID ON PERS NAMES dasd-eckd 0.0.0100 yes no dasda dasd-eckd 0.0.0101 no no dasd-eckd 0.0.0102 no no dasd-eckd 0.0.0190 no no dasd-eckd 0.0.019d no no dasd-eckd 0.0.019e no no dasd-eckd 0.0.0592 no noActivate the disks by using the command:
#
chzdev -e DISK_IDFor example, to activate the disk
0.0.0101
:#
chzdev -e 0.0.0101Verify that the disks are active in the output of the
lsdasd
command.
4 Preparing the configuration disk #
A virtual disk may be more suitable for production deployments, while a physical disk is better suited for development.
During the installation process, you can pass a complex configuration to define users, directories, or to provide SSH keys. To do so, create a configuration device that stores a complete configuration. The following example procedure describes how to create such a device:
Identify the disk:
#
lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks ================================================================================ 0.0.0100 active dasda 94:0 ECKD 4096 30720MB 7864380 0.0.0101 active dasdc 94:8 ECKD 4096 20480MB 5243040 0.0.0102 active dasdb 94:4 ECKD 4096 5120MB 1310760In the output above, the
Bus-ID
value of the disk to be used as a configuration device is 0.0.0102. Use the value ofBus-ID
or the disk size to identify the disk, as the device name (/dev/dasdX
) can change after each reboot.Format the disk. Keep in mind that formatting removes all data on that disk.
#
dasdfmt -b 4096 -y -p /dev/dasdbCreate a partition:
#
parted /dev/dasdb mkpart ext4 0% 100%Format the partition:
#
mkfs.ext4 /dev/dasdbLabel the partition as
ignition
:#
e2label /dev/dasdb1 ignitionVerify the file system:
#
blkidMount the partition:
#
mount /dev/dasdb1 /mntPrepare the directory structure for Ignition and/or Combustion. For Ignition:
#
mkdir -p /mnt/ignitionFor Combustion:
#
mkdir -p /mnt/combustionCopy your public SSH key to
/mnt/combustion
asssh_key.pub
.Prepare the configuration as described further.
4.1 Configuring SLE 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.
4.1.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 file script
must reside in the
combustion
subdirectory on the configuration media labeled
combustion
. The directory structure must look as follows:
<root directory> └── combustion └── script └── other files
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.
4.1.2 Combustion configuration examples #
4.1.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.
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.
4.1.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.
4.1.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 4.1.2.1.3, “Performing modifications in the initramfs”.
If you do not use the statement, the system remains configured without any network connection.
4.1.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
4.1.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;
4.1.2.1.5 Partitioning #
SLE 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
4.1.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 6.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
4.1.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
4.1.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 4.1.2.1.9, “Enabling services”.
4.1.2.1.9 Enabling services #
To enable system services, for example, the SSH service, add the
following line to script
:
systemctl enable sshd.service
4.1.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.
4.1.2.2 A complete example of the script
file #
The following script
provides complete settings that
may serve you as a guide on how to write your own Combustion
configuration. The example does not require any further Ignition
configuration.
#!/bin/bash # combustion: network prepare set -euxo pipefail ## The OSA subchannels to enable ZNET_SUBCHANNELS=0.0.1000,0.0.1001,0.0.1002 ## Network information to configure IPADDRESS="10.144.64.155/24" ## Formet is ipaddress/cidr GATEWAY="10.144.64.254" NAMESERVERS="10.144.53.53;10.144.53.54" ## A semicolon-separated list of name servers ## Hostname information NODE_HOSTNAME="micro6" ## Add password for root user ## Use either 'openssl passwd -6' or 'mkpasswd --method=sha-512' to encrypt the password. ROOT_USER_PASSWORD='PASSWORD_HASH' SSH_ROOT_PUBLIC_KEY=ssh_key.pub ## Add a regular user, because root login may be disallowed in some services. CREATE_NORMAL_USER=user ## Replace the "user" with a desired username here. NORMAL_USER_PASSWORD='PASSWORD_HASH' SSH_USER_PUBLIC_KEY=ssh_key.pub ## Register to SUSE Customer Center and install additional packages REG_EMAIL='tux@suse.com' ## Email address for product registration SLMICRO_REGCODE='REGISTRATIONCODE' ## A registration code required to install additional packages ADDITIONAL_PACKAGES='' ## A space separated list of additional packages to install nm_config() { umask 077 # Required for Network Manager configuration mkdir -p /etc/NetworkManager/system-connections/ cat >'/etc/NetworkManager/system-connections/Wired connection 1.nmconnection' <<EOF [connection] id=static type=ethernet autoconnect=true [ipv4] method=manual address1=$IPADDRESS gateway=$GATEWAY dns=$NAMESERVERS EOF } if [ "${1-}" = "--prepare" ]; then # Configure Network Manager in the initrd nm_config # Enable OSA network devices chzdev qeth $ZNET_SUBCHANNELS -ep chzdev qeth $ZNET_SUBCHANNELS -e exit 0 fi ## Post output on stdout exec > >(exec tee -a /dev/ttyS0) 2>&1 ## Set hostname echo $NODE_HOSTNAME > /etc/hostname ## Set root password echo root:$ROOT_USER_PASSWORD | chpasswd -e ## Add ssh public key as authorized key for the root user mkdir -pm700 /root/.ssh/ cat $SSH_ROOT_PUBLIC_KEY >> /root/.ssh/authorized_keys ## Mount /var and /home so user can be created smoothly if [ "$CREATE_NORMAL_USER" ] then mount /var && mount /home fi ## User creation if [ "$CREATE_NORMAL_USER" ] then echo "User creation is requested, creating user." useradd -m $CREATE_NORMAL_USER -s /bin/bash -g users echo $CREATE_NORMAL_USER:$NORMAL_USER_PASSWORD | chpasswd -e echo $CREATE_NORMAL_USER "ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/adminusers mkdir -pm700 /home/$CREATE_NORMAL_USER/.ssh/ chown -R $CREATE_NORMAL_USER:users /home/$CREATE_NORMAL_USER/.ssh/ cat $SSH_USER_PUBLIC_KEY >> /home/$CREATE_NORMAL_USER/.ssh/authorized_keys echo "Requested user has been created, requested password has been set." else echo "No user will be created" fi # Configure NM in the system nm_config # Enable OSA network device chzdev qeth $ZNET_SUBCHANNELS -ep chzdev qeth $ZNET_SUBCHANNELS -e ## Enable services echo "Enabling services." systemctl enable cockpit.socket systemctl enable sshd ## Unmount var and home if [ "$CREATE_NORMAL_USER" ] then umount /var && umount /home fi # Close outputs and wait for tee to finish exec 1>&- 2>&-; wait; echo "Configured with Combustion at $(date)" > /etc/issue.d/combustion
4.2.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.
4.2.1.1 config.ign
#
The configuration file
config.ign
must reside in the
ignition
subdirectory on the configuration media, for example, a USB
stick labeled ignition
. The directory structure must look as follows:
<root directory> └── ignition └── config.ign
To create a disk image with the Ignition configuration, you can use the Fuel Ignition Web application at https://ignite.opensuse.org.
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
SLE 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.
4.2.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.
4.2.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.
4.2.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.
4.2.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 } ] } }
4.2.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" } ] } }
4.2.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 SLE 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 } ] } }
4.2.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 } ] } }
4.2.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" } } ] } }
4.2.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 6.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.
4.2.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" } ] } }
4.2.2.5 Converting YAML formatted files into JSON #
JSON is a universal file format for storing structured data. Applications, for example, Ignition, use it to store and retrieve their configuration. Because JSON's syntax is complex and hard to read for human beings, you can write the configuration in a more friendly format called YAML and then convert it into JSON.
4.2.2.5.1 Converting YAML files into JSON format #
The tool that converts Ignition-specific vocabularies in YAML files
into JSON format is butane
. It also verifies the
syntax of the YAML file to catch potential errors in the structure. For
the latest version of butane
, add the following
repository:
>
sudo
zypper ar -f \ https://download.opensuse.org/repositories/devel:/kubic:/ignition/openSUSE_Tumbleweed/ \ devel_kubic_ignition
Replace openSUSE_Tumbleweed
with one of the following
(depending on your distribution):
'openSUSE_Leap_$releasever'
15.5
Now you can install the butane
tool:
>
sudo
zypper ref && zypper in butane
After the installation is complete, you can invoke
butane
by running:
>
butane -p -o config.ign config.fcc
config.fcc
is the path to the YAML configuration file.config.ign
is the path to the output JSON configuration file.The
-p
command option adds line breaks to the output file and thus makes it more readable.
5 Deploying the raw disk image on the disk #
To deploy SUSE Linux Enterprise Micro on your machine, proceed as follows:
Download the raw disk image using
wget
orcurl
. For example:>
curl -L0kOExtract the image:
>
unpack xz -d BUILD_IDENTIFICATION.raw.xzExport a variable that finds and stores the 20 GB device name.
#
export SMDASD=$(lsdasd -s | grep 20480MB | tr -s [:blank:] | cut -d' ' -f3)Format the disk:
If the disk is formatted for the first time:
#
dasdfmt -b 4096 -y -p /dev/$SMDASDIf the disk was previously formatted:
#
dasdfmt -b 4096 -M quick -y -p /dev/$SMDASD
Copy the raw disk image to the disk:
dd if=IMAGE_NAME.raw status=progress of=/dev/dasdc bs=4k
Shut down the running Linux:
#
init 0Start SUSE Linux Enterprise Micro by booting the second DASD minidisk in an x3270 terminal:
#
ipl 101
6 Post-deployment steps #
6.1 Registering SLE Micro from CLI #
If your system was not registered during the deployment process
by using the Combustion script
, you can
register from the running system.
To register SUSE Linux Enterprise 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 Enterprise 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 Enterprise Micro is now registered.
For information that goes beyond the scope of this section, refer to the
inline documentation with SUSEConnect --help
.
6.2 Adding users #
As SUSE Linux Enterprise Micro requires having a non-privileged user to log in via SSH or to access Cockpit, you need to create such an account.
This step is optional if you have defined an unprivileged user in the Combustion.
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
7 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.