Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Micro – Dokumentation  / Administration Guide / Troubleshooting / Gathering system information for support
Applies to SUSE Linux Enterprise Micro 5.5

11 Gathering system information for support

 

In case of problems, a detailed system report may be created with the supportconfig command-line tool. The tool will collect information about the system, such as the current kernel version, hardware, installed packages, partition setup, and much more. The result is a TAR archive of files. After opening a Service Request (SR), you can upload the TAR archive to Global Technical Support. It will help you to locate the reported issue and solve the problem.

You can analyze the supportconfig output for known issues to help resolve problems faster.

11.1 Collecting system information with supportconfig

 

To create a TAR archive with detailed system information that you can hand over to Global Technical Support, use the command supportconfig. The command-line tool is provided by the package supportutils which is installed by default.

Depending on which packages are installed on your system, some of these packages integrate supportconfig plug-ins. When supportconfig is executed, all plug-ins are executed as well, creating one or more result files for the archive. This has the benefit that the only topics checked are those that contain a specific plug-in for them. supportconfig plug-ins are stored in the directory /usr/lib/supportconfig/plugins/.

The following procedure shows how to create a Supportconfig archive, but without submitting it to support directly. For uploading it, you need to run the command with certain options as described in Procedure 11.1, “Submitting information to support from command line”.

  1. Run supportconfig as root. Usually, it is enough to run this tool without any options. Some options are very common and are displayed in the following list:

    -E MAIL, -N NAME, -O COMPANY, -P PHONE

    Sets your contact data: e-mail address (-E), company name (-O), your name (-N), and your phone number (-P).

    -i KEYWORDS, -F

    Limits the features to check. The placeholder KEYWORDS is a comma-separated list of case-sensitive keywords. Get a list of all keywords with supportconfig -F.

  2. Wait for the tool to complete the operation.

  3. The default archive location is /var/log, with the file name format being scc_HOST_DATE_TIME.txz

11.1.1 Understanding the output of supportconfig

 

If you run supportconfig, the script gives you a summary of what it did. 

                     Support Utilities - Supportconfig
                          Script Version: 3.1.11-46.2 
                          Library Version: 3.1.11-29.6
                          Script Date: 2022 10 18
[...]
Gathering system information
  Data Directory:    /var/log/scc_d251_180201_1525 1

  Basic Server Health Check...                 Done 2
  RPM Database...                              Done 2
  Basic Environment...                         Done 2
  System Modules...                            Done 2
[...]
  File System List...                          Skipped 3
[...]
  Command History...                           Excluded 4
[...]
  Supportconfig Plugins:                       1 5
    Plugin: pstree...                          Done
[...]
Creating Tar Ball

==[ DONE ]===================================================================
  Log file tar ball: /var/log/scc_d251_180201_1525.txz 6
  Log file size:     732K
  Log file md5sum:   bf23e0e15e9382c49f92cbce46000d8b
=============================================================================

1

The temporary data directory to store the results. This directory is archived as a tar file, see 6.

2

The feature was enabled (either by default or selected manually) and executed successfully. The result is stored in a file (see Table 11.1, “Comparison of features and file names in the TAR archive”).

3

The feature was skipped because some files of one or more RPM packages were changed.

4

The feature was excluded because it was deselected via the -x option.

5

The script found one plug-in and executes the plug-in pstree. The plug-in was found in the directory /usr/lib/supportconfig/plugins/. See the man page for details.

6

The tar file name of the archive, compressed with xz by default.

11.1.2 Common supportconfig options

 

The supportconfig utility is usually called without any options. Display a list of all options with supportconfig -h. The following list gives a brief overview of some common use cases:

Reducing the amount of the information being gathered

Use the minimal option (-m): 

# supportconfig -m
Limiting the information to a specific topic

If you have already localized a problem that relates to a specific area or feature set only, you should limit the collected information to the specific area for the next supportconfig run. For example, you have detected problems with LVM and want to test a recent change that you introduced to the LVM configuration. In this case, it makes sense to gather the minimum Supportconfig information around LVM only: 

# supportconfig -i LVM

Additional keywords can be separated with commas. For example, an additional disk test: 

# supportconfig -i LVM,DISK

For a complete list of feature keywords that you can use for limiting the collected information to a specific area, run: 

# supportconfig -F
Including additional contact information in the output:
# supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...

(all in one line)

Collecting already rotated log files
# supportconfig -l

This is especially useful in high-logging environments or after a kernel crash when syslog rotates the log files after a reboot.

11.1.3 Overview of the archive content

 

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 11.1.2, “Common supportconfig options”).

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

# tar xf /var/log/scc_earth_180131_1545.txz

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

Minimum files in archive
 
basic-environment.txt

Contains the date when this script was executed and system information like version of the distribution, hypervisor information, and more.

basic-health-check.txt

Contains some basic health checks like uptime, virtual memory statistics, free memory and hard disk, checks for zombie processes, and more.

hardware.txt

Contains basic hardware checks like information about the CPU architecture, list of all connected hardware, interrupts, I/O ports, kernel boot messages, and more.

messages.txt

Contains log messages from the system journal.

rpm.txt

Contains a list of all installed RPM packages, their names and versions and where they come from.

summary.xml

Contains information in XML format, such as distribution, version and product-specific fragments.

supportconfig.txt

Contains information about the supportconfig script itself.

y2log.txt

Contains YaST-specific information like specific packages, configuration files and log files.

Table 11.1, “Comparison of features and file names in the TAR archive” lists all available features and their file names.

Table 11.1: Comparison of features and file names in the TAR archive
 
FeatureFile name
APPARMOR security-apparmor.txt
AUDIT security-audit.txt
AUTOFS fs-autofs.txt
BOOT boot.txt
BTRFS fs-btrfs.txt
DAEMONS systemd.txt
CIMOM cimom.txt
CRASH crash.txt
CRON cron.txt
DHCP dhcp.txt
DISK fs-diskio.txt
DNS dns.txt
DOCKER docker.txt
DRBD drbd.txt
ENV env.txt
ETC etc.txt
HISTORY shell_history.txt
ISCSI fs-iscsi.txt
LDAP ldap.txt
LIVEPATCH kernel-livepatch.txt
LVM lvm.txt
MEM memory.txt
MOD modules.txt
MPIO mpio.txt
NET network-*.txt
NFS nfs.txt
NTP ntp.txt
NVME nvme.txt
OCFS2 ocfs2.txt
PAM pam.txt
PODMAN podman.txt
PRINT print.txt
PROC proc.txt
SAR sar.txt
SLERT slert.txt
SLP slp.txt
SMT smt.txt
SMART fs-smartmon.txt
SMB samba.txt
SRAID fs-softraid.txt
SSH ssh.txt
SSSD sssd.txt
SYSCONFIG sysconfig.txt
SYSFS sysfs.txt
TRANSACTIONAL transactional-update.txt
TUNED tuned.txt
UDEV udev.txt
UFILES fs-files-additional.txt
UP updates.txt
WEB web.txt

11.2 Submitting information to Global Technical Support

 

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

11.2.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
Note: Privacy statement

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

11.2.2 Upload targets

 

After having created a service request number, you can upload your Supportconfig archives to Global Technical Support. In the examples below, the 12345678901 serves as a placeholder for your service request number. Replace the placeholder with the service request number you created in Section 11.2.1, “Creating a service request number”.

Procedure 11.1: Submitting information to support from command line
 

The following procedure assumes that you have already created a Supportconfig archive but have not uploaded it yet.

  1. Servers with Internet connectivity:

    1. To use the default upload target https://support-ftp.us.suse.com/incoming/upload.php?file={tarball}, run: 

      > sudo supportconfig -ur 12345678901

    2. For the FTPS upload target ftps://support-ftp.us.suse.com, use the following command: 

      > sudo supportconfig -ar 12345678901

      To use a different upload target, for example, for the EMEA area, use the -U followed by the particular URL, either https://support-ftp.emea.suse.com/incoming/upload.php?file={tarball} or ftps://support-ftp.emea.suse.com/incoming/ 

      > sudo supportconfig -r 12345678901 -U https://support-ftp.emea.suse.com/incoming

  2. Servers without Internet connectivity:

    1. Run the following: 

      > sudo supportconfig -r 12345678901

    2. Manually upload the /var/log/scc_SR12345678901*txz archive to one of our servers. The selection of a server depends on your location in the world:

  3. After the TAR archive arrives in the incoming directory of our FTP server, it becomes automatically attached to your service request.

11.3 Gathering information during the installation

 

When performing the manual installation, supportconfig is not available. However, you can collect log files from YaST by using save_y2logs. This command will create a .tar.xz archive in the directory /tmp.

11.4 Support of kernel modules

 

An important requirement for every enterprise operating system is the level of support you receive for your environment. Kernel modules are the most relevant connector between hardware (“controllers”) and the operating system. Every kernel module in SLE Micro has a supported flag that can take three possible values:

  • “yes,” thus supported

  • “external,” thus supported

  • (empty, not set), thus unsupported

The following rules apply:

  • All modules of a self-recompiled kernel are by default marked as unsupported.

  • Kernel modules supported by SUSE partners and delivered using SUSE SolidDriver Program are marked “external.”

  • If the supported flag is not set, loading this module will taint the kernel. Tainted kernels are not supported.

  • Kernel modules not provided under a license compatible to the license of the Linux kernel will also taint the kernel. For details, see the state of /proc/sys/kernel/tainted.

11.4.1 Technical background

 

  • Linux kernel: The value of /proc/sys/kernel/unsupported defaults to 2, which means that no syslog warning is generated when unsupported modules are loaded. This default is used in the installer and in the installed system.

  • modprobe: The modprobe utility for checking module dependencies and loading modules appropriately checks for the value of the supported flag. If the value is “yes” or “external,” the module will be loaded, otherwise it will not. For information on how to override this behavior, see Section 11.4.2, “Working with unsupported modules”.

    Note
    Note: Support

    SUSE does not generally support the removal of storage modules via modprobe -r.

11.4.2 Working with unsupported modules

 

While general supportability is important, situations can occur where loading an unsupported module is required. For example, for testing or debugging purposes, or if your hardware vendor provides a hotfix.

  • To override the default, copy /lib/modprobe.d/10-unsupported-modules.conf to /etc/modprobe.d/10-unsupported-modules.conf and change the value of the variable allow_unsupported_modules from 0 to 1. Do not edit /lib/modprobe.d/10-unsupported-modules.conf directly; any changes will be overwritten whenever the suse-module-tools package is updated.

    If an unsupported module is needed in the initrd, do not forget to run transactional-update initrd to update the initrd.

    If you only want to try loading a module once, you can use the --allow-unsupported-modules option with modprobe. For more information, see the comments in /lib/modprobe.d/10-unsupported-modules.conf and the modprobe help.

  • To enforce the loading of unsupported modules during boot and afterward, use the kernel command-line option oem-modules. While installing and initializing the suse-module-tools package, the kernel flag TAINT_NO_SUPPORT (/proc/sys/kernel/tainted) will be evaluated. If the kernel is already tainted, allow_unsupported_modules will be enabled. This will prevent unsupported modules from failing in the system being installed. If no unsupported modules are present during installation and the other special kernel command-line option (oem-modules=1) is not used, the default is still to disallow unsupported modules.

Remember that loading and running unsupported modules will make the kernel and the whole system unsupported by SUSE.