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”.
Run
supportconfig
asroot
. 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
.
Wait for the tool to complete the operation.
The default archive location is
/var/log
, with the file name format beingscc_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 =============================================================================
The temporary data directory to store the results. This directory is archived as a tar file, see 6. | |
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”). | |
The feature was skipped because some files of one or more RPM packages were changed. | |
The feature was excluded because it was deselected via the
| |
The script found one plug-in and executes the plug-in
| |
The tar file name of the archive, compressed with
|
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 LVMAdditional keywords can be separated with commas. For example, an additional disk test:
#
supportconfig -i LVM,DISKFor 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 -lThis 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:
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.
Feature | File 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.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.
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”.
The following procedure assumes that you have already created a Supportconfig archive but have not uploaded it yet.
Servers with Internet connectivity:
To use the default upload target https://support-ftp.us.suse.com/incoming/upload.php?file={tarball}, run:
>
sudo
supportconfig -ur 12345678901For the FTPS upload target ftps://support-ftp.us.suse.com, use the following command:
>
sudo
supportconfig -ar 12345678901To 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
Servers without Internet connectivity:
Run the following:
>
sudo
supportconfig -r 12345678901Manually 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:North America: HTTPS https://support-ftp.us.suse.com/incoming/upload.php?file={tarball}, FTPS ftps://support-ftp.us.suse.com/incoming/
EMEA, Europe, the Middle East, and Africa: FTP https://support-ftp.emea.suse.com/incoming/upload.php?file={tarball}, FTPS ftps://support-ftp.emea.suse.com/incoming/
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 to2
, 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
: Themodprobe
utility for checking module dependencies and loading modules appropriately checks for the value of thesupported
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: SupportSUSE 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 variableallow_unsupported_modules
from0
to1
. 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 withmodprobe
. For more information, see the comments in/lib/modprobe.d/10-unsupported-modules.conf
and themodprobe
help.To enforce the loading of unsupported modules during boot and afterward, use the kernel command-line option
oem-modules
. While installing and initializing thesuse-module-tools
package, the kernel flagTAINT_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.