SUSE Linux Enterprise Desktop DocumentationAdministration Guide > Support and Common Tasks > ◀ ▶

Chapter 2. Gathering System Information for Support

Contents

2.1. Collecting System Information with Supportconfig
2.2. Submitting Information to Global Technical Support
2.3. Support of Kernel Modules
2.4. For More Information

Abstract

In case of problems, a detailed system report may be created with either the supportconfig command line tool or the YaST Support module. Both will collect information about the system such as: 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 to locate the issue you reported and to assist you in solving the problem.

The command line tool is provided by the package supportutils which is installed by default. The YaST Support module is based on the command line tool.

2.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 either the supportconfig command line tool directly or the YaST Support module. The command line tool is provided by the package supportutils which is installed by default. The YaST Support module is also based on the command line tool.

2.1.1. Creating a Service Request Number

Supportconfig archives can be generated at any time. However, for 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 http://www.novell.com/center/eservice and follow the instructions on the screen. Write down your 11-digit service request number.

[Note]Privacy Statement

SUSE and Novell treat system reports as confidential data. For details about our privacy commitment, see http://www.novell.com/company/legal/privacy/.

2.1.2. Upload Targets

After having created a service request number, you can upload your supportconfig archives to Global Technical Support as described in Procedure 2.1, “Submitting Information to Support with YaST” or Procedure 2.2, “Submitting Information to Support from Command Line”. Use one of the following upload targets:

Alternatively, you can manually attach the TAR archive to your service request using the service request URL: http://www.novell.com/center/eservice.

2.1.3. Creating a Supportconfig Archive with YaST

To use YaST to gather your system information, proceed as follows:

  1. Start YaST and open the Support module.

  2. Click Create report tarball.

  3. In the next window, select one of the supportconfig options from the radio button list. Use Custom (Expert) Settings is pre-selected by default. If you want to test the report function first, use Only gather a minimum amount of info. For some background information on the other options, refer to the supportconfig man page.

    Proceed with Next.

  4. Enter your contact information. It will be written to a file called basic-environment.txt and included in the archive to be created.

  5. If you want to submit the archive to Global Technical Support at the end of the information collection process, Upload Information is required. YaST automatically proposes an upload server. If you want to modify it, refer to Section 2.1.2, “Upload Targets” for details of which upload servers are available.

    If you want to submit the archive later on, you can leave the Upload Information empty for now.

  6. Proceed with Next.

  7. The information gathering begins.

    After the process is finished, continue with Next.

  8. Review the data collection: Select the File Name of a log file to view its contents in YaST. To remove any files you want excluded from the TAR archive before submitting it to support, use Remove from Data. Continue with Next.

  9. Save the TAR archive. If you started the YaST module as root user, by default YaST proposes to save the archive to /var/log (otherwise, to your home directory). The file name format is nts_HOST_DATE_TIME.tbz.

  10. If you want to upload the archive to support directly, make sure Upload log files tarball to URL is activated. The Upload Target shown here is the one that YaST proposes in Step 5. If you want to modify the upload target, find detailed information of which upload servers are available in Section 2.1.2, “Upload Targets”.

  11. If you want to skip the upload, deactivate Upload log files tarball to URL.

  12. Confirm your changes to close the YaST module.

2.1.4. Creating a Supportconfig Archive from Command Line

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 2.2, “Submitting Information to Support from Command Line”.

  1. Open a shell and become root.

  2. Run supportconfig without any options. This gathers the default system information.

  3. Wait for the tool to complete the operation.

  4. The default archive location is /var/log, with the file name format being nts_HOST_DATE_TIME.tbz

2.1.5. Common Supportconfig Options

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

Reducing the Size 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 with the default supportconfig output and have found that it relates to a specific area or feature set only, you may want to limit the collected information to the specific area for the next supportconfig run. For example, if you detected problems with LVM and want to test a recent change that you did to the LVM configuration, it makes sense to gather the minimum supportconfig information around LVM only: 

supportconfig -i LVM

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.

2.2. Submitting Information to Global Technical Support

Use the YaST Support module or the supportconfig command line utility to submit system information to the Global Technical Support. When you experience a server issue and want the support's assistance, you will need to open a service request first. For details, see Section 2.1.1, “Creating a Service Request Number”.

The following examples use 12345678901 as a placeholder for your service request number. Replace 12345678901 with the service request number you created in Section 2.1.1, “Creating a Service Request Number”.

Procedure 2.1. Submitting Information to Support with YaST

The following procedure assumes that you have already created a supportconfig archive, but have not uploaded it yet. Make sure to have included your contact information in the archive as described in Section 2.1.3, “Creating a Supportconfig Archive with YaST”, Step 4. For instructions on how to generate and submit a supportconfig archive in one go, see Section 2.1.3, “Creating a Supportconfig Archive with YaST”.

  1. Start YaST and open the Support module.

  2. Click Upload.

  3. In Package with log files specify the path to the existing supportconfig archive or Browse for it.

  4. YaST automatically proposes an upload server. If you want to modify it, refer to Section 2.1.2, “Upload Targets” for details of which upload servers are available.

    Proceed with Next.

  5. Click Finish.

Procedure 2.2. 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. For instructions on how to generate and submit a supportconfig archive in one go, see Section 2.1.3, “Creating a Supportconfig Archive with YaST”.

  1. Servers with Internet connectivity:

    1. To use the default upload target, run: 

      supportconfig -ur 12345678901

    2. For the secure upload target, use the following: 

      supportconfig -ar 12345678901

  2. Servers without Internet connectivity

    1. Run the following: 

      supportconfig -r 12345678901

    2. Manually upload the /var/log/nts_SR12345678901*tbz archive to one of our FTP servers. Which one to use depends on your location in the world. For an overview, see Section 2.1.2, “Upload Targets”.

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

2.3. 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 SUSE Linux Enterprise 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. Unsupported Kernel modules are included in an extra RPM package (kernel-FLAVOR-extra) and will not be loaded by default (FLAVOR=default|xen|...). In addition, these unsupported modules are not available in the installer, and the kernel-FLAVOR-extra package is not part of the SUSE Linux Enterprise media.

  • Kernel modules not provided under a license compatible to the license of the Linux Kernel will also taint the Kernel. For details, see /usr/src/linux/Documentation/sysctl/kernel.txt and the state of /proc/sys/kernel/tainted.

2.3.1. Technical Background

  • Linux Kernel: The value of /proc/sys/kernel/unsupported defaults to 2 on SUSE Linux Enterprise 11 SP4 (do not warn in syslog when loading unsupported modules). This default is used in the installer as well as in the installed system. See /usr/src/linux/Documentation/sysctl/kernel.txt for more information.

  • 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 2.3.2, “Working with Unsupported Modules”.

    [Note]

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

2.3.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, edit /etc/modprobe.d/unsupported-modules.conf and change the value of the variable allow_unsupported_modules to 1. If an unsupported module is needed in the initrd, do not forget to run mkinitrd 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 modprobe man page.

  • During installation, unsupported modules may be added through driver update disks, and they will be loaded. To enforce loading of unsupported modules during boot and afterward, use the Kernel command line option oem-modules. While installing and initializing the module-init-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 still is to disallow unsupported modules.

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

2.4. For More Information

Find more information about gathering system information in the following documents:

SUSE Linux Enterprise Desktop Administration Guide 11 SP4

SUSE Linux Enterprise Desktop DocumentationAdministration Guide > Support and Common Tasks > ◀ ▶