SLE Micro Administration Guide

Snapshots share data for efficient use of storage space, so using ordinary commands like du and df does not determine the used disk space accurately. When you want to free up disk space on Btrfs with quotas enabled, you need to know how much exclusive disk space is used by each snapshot, rather than shared space. The btrfs command provides a view of the space used by snapshots:

# btrfs qgroup show -p /
qgroupid         rfer         excl parent  
--------         ----         ---- ------  
0/5          16.00KiB     16.00KiB ---     
[...]    
0/272         3.09GiB     14.23MiB 1/0     
0/273         3.11GiB    144.00KiB 1/0     
0/274         3.11GiB    112.00KiB 1/0     
0/275         3.11GiB    128.00KiB 1/0     
0/276         3.11GiB     80.00KiB 1/0     
0/277         3.11GiB    256.00KiB 1/0     
0/278         3.11GiB    112.00KiB 1/0     
0/279         3.12GiB     64.00KiB 1/0     
0/280         3.12GiB     16.00KiB 1/0     
1/0           3.33GiB    222.95MiB ---

The qgroupid column displays the identification number for each subvolume, assigning a qgroup level/ID combination.

The rfer column displays the total amount of data referred to in the subvolume.

The excl column displays the exclusive data in each subvolume.

The parent column shows the parent qgroup of the subvolumes.

The final item, 1/0, shows the totals for the parent qgroup. In the above example, 222.95 MiB will be freed after all subvolumes are removed. Run the following command to see which snapshots are associated with each subvolume:

# btrfs subvolume list -st /

To keep the base operating system stable and consistent, the SUSE Linux Enterprise Micro uses a read-only root file system. Therefore, you cannot perform direct changes to the root file system, for example, by using the zypper command. Instead, SLE Micro introduces transactional updates that allow you to apply one or more changes to the root file system.

The default transactional-update behavior is to create a new snapshot from the current root file system after each change. To apply the changes, you need to reboot the host. You cannot run the transactional-update command multiple times without rebooting to add more changes to the snapshot. This action creates separate independent snapshots that do not include changes from the previous snapshots.

Each time you call the transactional-update command to change your system—either to install a package, perform an update, or apply a patch—the following actions take place:

Each time you run the transactional-update command, the changes are performed in a new snapshot. The environment in the snapshot may differ from the one in the shell you run the transactional-update command from. For example, the current working directory ($PWD) is not set to the directory from which you run the transactional-update, but is set to /.

From within the snapshot, you cannot access the /var directory. This directory is also not included in the snapshot. However, some directories are not included in the snapshot but are accessible inside the transactional-update environment, for example, the /root directory.

To make multiple changes to the root file system without rebooting, you have several options, which are described in the following sections:

3.5.2 The transactional-update run command #

  

The transactional-update run command normally runs only a single command. However, you can use it to run multiple commands in one transactional session by concatenating them within a command shell such as bash, for example:

> sudo transactional-update run bash -c 'ls && date; if [ true ]; then echo -n "Hello "; echo '\''world'\''; fi'

Note

The transactional-update run command has the same limitations as the transactional-update shell command described in Section 3.5.3, “The transactional-update shell” except that the entered commands are logged in the /var/log/transactional-update.log file.

3.5.3 The transactional-update shell #

  

The transactional-update shell command opens a shell in the transactional-update environment. In the shell, you can enter almost any Linux command to make changes to the file system, for example, install multiple packages with the zypper command or perform changes to files that are part of the read-only file system. You can also verify that the changes you previously made with the transactional-update command are correct.

Important

The transactional shell has several limitations. For example, you cannot operate start or stop services using systemd commands, or modify the /var partition because it is not mounted. Also, commands entered during a shell session are not logged in the /transactional-update.log file.

All changes that you make to the file system are part of a single snapshot. After you finish making changes to the file system and leave the shell with the exit command, you need to reboot the host to apply the changes.

The transactional-update command syntax is as follows:

transactional-update [option] [general_command] [package_command] standalone_command

Note: Running transactional-update without arguments

If you do not specify any command or option while running the transactional-update command, the system updates itself.

Possible command parameters are described further.

transactional-update recognizes the following cleanup commands:

When booting a snapshot, the parts of the file system included in the snapshot are mounted read-only; all other file systems and parts that are excluded from snapshots are mounted read-write and can be modified.

Tip: Rolling back to a specific installation state

An initial bootable snapshot is created at the end of the initial system installation. You can go back to that state at any time by booting this snapshot. The snapshot can be identified by the description first root file system.

There are two methods to perform a system rollback.

If your current snapshot is functional, you can use the following procedure for a system rollback.

The following procedure is used in case the current snapshot is broken and you cannot boot into it.

Automatic updates are controlled by systemd.timer that runs once per day. This applies all updates and informs rebootmgrd that the machine should be rebooted. You may adjust the time when the update runs, see systemd.timer(5) documentation.

> sudo systemctl --now disable transactional-update.timer

> sudo transactional-update pkg in systemd-status-mail mailx

For ULP to work, proceed as follows:

4.1.1 Using libpulp #

  

Note: Supported libraries for patching

Currently, only glibc and openssl (openssl1_1) are supported. Additional packages will be available after they are prepared for live patching. To receive glibc and openssl live patches, install both glibc-livepatches and openssl-livepatches packages:

> transactional-update pkg in glibc-livepatches openssl-livepatches

After successful installation, reboot your system.

To check whether a library is live patchable, use the following command:

> ulp livepatchable PATH_TO_LIBRARY

A shared object (.so) is a live patch container if it contains the ULP patch description embedded into it. You can verify it with the following command:

> readelf -S SHARED_OBJECT | grep .ulp

If the output shows that there are both .ulp and .ulp.rev sections in the shared object, then it is a live patch container.

NetworkManager is a program that manages the primary network connection and other connection interfaces. wicked is a network management tool that provides network configuration as a service and enables changing the network configuration dynamically.

NetworkManager and wicked provide similar functionality; however, they differ in the following points:

The main configuration file for the NetworkManager is /etc/NetworkManager/NetworkManager.conf. This file can be used to configure the behavior of NetworkManager.

The file consists of sections of key-value pairs. Each key-value pair must belong to a section. A section starts with a name enclosed in []. Lines beginning with a # are considered comments. The minimal configuration needs to include the [main] section with the plugins value:

[main]
plugins=keyfile

The keyfile plug-in supports all the connection types and capabilities of NetworkManager.

The default configuration file contains the connectivity section that specifies the URI to check the network connection.

On SUSE Linux Enterprise Micro, you can also use other sections. For details, refer to networkmanager.conf(5) or Gnome's developer guide.

health-checker supports the addition of your own plug-ins to check services during the boot process. Each plug-in is a bash script that must fulfill the following requirements:

To start the toolbox container as a regular user with root rights, run the following command:

> toolbox --root

As root, you can omit the --root option:

# toolbox

If the script completes successfully, you can see the toolbox container prompt.

To remove the container, run the following command:

> sudo podman rm toolbox-USER

For example, for the root user:

# podman rm toolbox-root

Note: Obtaining the toolbox image

You can also use Podman or Cockpit to pull the toolbox image and start a container based on that image.

The PCP container image is based on the BCI-Init container that utilizes systemd used to manage the PCP services.

You can pull the container image using Podman or from the Cockpit Web management console. To pull the image by using Podman, run the following command:

# podman pull registry.suse.com/suse/pcp:latest

To get the container image using Cockpit, go to Podman containers, click Get new image, and search for pcp. Then select the image from the registry.suse.com for SLE 15 SP4 and download it.

The following command shows minimal options that you need to use to run a PCP container:

# podman run -d  \
  --systemd always \
  -p HOST_IP:HOST_PORT:CONTAINER_PORT \
  -v HOST_DIR:/var/log/pcp/pmlogger \
  PCP_CONTAINER_IMAGE

where the options have the following meaning:

Other useful options of the podman run command follow:

All services that run inside the PCP container have a default configuration that might not suit your needs. If you need a custom configuration that cannot be covered by the environment variables, create configuration files for the PCP services and pass them to the PCP using a bind mount as follows:

# podman run -d \
  --name CONTAINER_NAME \
  --systemd always \
  -v $HOST_CONFIG:CONTAINER_CONFIG_PATH:z \
  -v HOST_LOGS_PATH:/var/log/pcp/pmlogger  \
  registry.suse.com/suse/pcp:latest

Where:

For example, a container called pcp, with the configuration file pmcd on the host machine and the pcp-archives directory for logs on the host machine, is run by the following command:

# podman run -d \
  --name pcp  \
  --systemd always \
  -v $(pwd)/pcp-archives:/var/log/pcp/pmlogger \
  -v $(pwd)/pmcd:/etc/sysconfig/pmcd \
registry.suse.com/suse/pcp:latest

      PMCD_LOCAL=0
      PMCD_MAXPENDING=5
      PMCD_ROOT_AGENT=1
      PMCD_RESTART_AGENTS=1
      PMCD_WAIT_TIMEOUT=70
      PCP_NSS_INIT_MODE=readwrite

8.3.2 Custom pmlogger configuration #

  

The custom configuration for the pmlogger is stored in the following configuration files:

• /etc/sysconfig/pmlogger

• /etc/pcp/pmlogger/control.d/local

8.3.2.1 The /etc/sysconfig/pmlogger file #

  

You can use the following attributes to configure the pmlogger:

PMLOGGER_LOCAL

Defines whether pmlogger allows connections from remote hosts. If set to 1, pmlogger allows connections from a local host only.

PMLOGGER_MAXPENDING

Defines the maximum count of pending connections. The default value is 5.

PMLOGGER_INTERVAL

Defines the default sampling interval pmlogger uses. The default value is 60 s. Keep in mind that this value can be overridden by the pmlogger command line.

PMLOGGER_CHECK_SKIP_LOGCONF

Setting this option to yes disables the regeneration and checking of the pmlogger configuration if the configuration pmlogger comes from pmlogconf. The default behavior is to regenerate configuration files and check for changes every time pmlogger is started.

An example follows:

PMLOGGER_LOCAL=1
PMLOGGER_MAXPENDING=5
PMLOGGER_INTERVAL=10
PMLOGGER_CHECK_SKIP_LOGCONF=yes

8.3.2.2 The /etc/pcp/pmlogger/control.d/local file #

  

The file /etc/pcp/pmlogger/control.d/local stores specifications of the host, which metrics should be logged, the logging frequency (default is 24 hours), and pmlogger options. For example:

# === VARIABLE ASSIGNMENTS ===
#
# DO NOT REMOVE OR EDIT THE FOLLOWING LINE
$version=1.1

# Uncomment one of the lines below to enable/disable compression behaviour
# that is different to the pmlogger_daily default.
# Value is days before compressing archives, 0 is immediate compression,
# "never" or "forever" suppresses compression.
#
#$PCP_COMPRESSAFTER=0
#$PCP_COMPRESSAFTER=3
#$PCP_COMPRESSAFTER=never

# === LOGGER CONTROL SPECIFICATIONS ===
#
#Host           P?  S?  directory                       args

# local primary logger
LOCALHOSTNAME   y   n   PCP_ARCHIVE_DIR/LOCALHOSTNAME   -r -T24h10m -c config.default -v 100Mb

Note: Defaults point to local host

If you run the pmlogger in a container on a different machine than the one that runs the pmcd (a client), change the following line to point to the client:

# local primary logger
CLIENT_HOSTNAME   y   n   PCP_ARCHIVE_DIR/CLIENT_HOSTNAME   -r -T24h10m -c config.default -v 100Mb

For example, for the slemicro_1 host name, the line should look as follows:

# local primary logger
slemicro_1   y   n   PCP_ARCHIVE_DIR/slemicro_1   -r -T24h10m -c config.default -v 100Mb

If problems occur, you can use the supportconfig command-line tool to create a detailed system report. The tool collects information about the system, such as the current kernel version, hardware, installed packages, partition setup, and much more.

The command-line tool is provided by the package supportutils, which is installed by default. However, supportconfig can integrate plug-ins that are used with each running of supportconfig. Which plug-ins are available on your system, depends on installed packages. The plug-ins are stored in the /usr/lib/supportconfig/plugins/ directory.

The supportconfig tool creates a TAR archive with detailed system information that you can hand over to Global Technical Support.

To create a TAR archive with detailed system information that you can hand over to Global Technical Support, follow the procedure:

The TAR archive contains all the results from the features. Depending on what you have selected (all or only a small set), the archive can contain more or fewer files. The set of features can be limited using the -i option (see Section 9.2.1, “Common supportconfig options”).

To list the contents of the archive, use this tar command:

# tar xf /var/log/scc_&exampleclient;_180131_1545.txz

The following file names are always available inside the TAR archive:

The following table lists all available features and their file names.

After you have created the archive using the supportconfig tool, you can submit the archive to SUSE.

9.4.1 Creating a service request number #

  

Before handing over the supportconfig data to Global Technical Support, you need to generate a service request number first. You will need it to upload the archive to support.

To create a service request, go to https://scc.suse.com/support/requests and follow the instructions on the screen. Write down the service request number.

Note: Privacy statement

SUSE treats system reports as confidential data. For details about our privacy commitment, see https://www.suse.com/company/policies/privacy/.