Welcome to SUSE Technical Support !
The SUSE Technical Support organization creates a lot of detailed information which is publicly available to our customers, that allow for self-support in many problem scenarios, but also provides a series of tools, utilities and best practices that will assist our technical support engineers in working on the complex issues once these are reported to our technical support team.
In this TID (Technical Information Document) we aim to share that information in such a fashion so that we can minimize the turn-around times to resolve any reported problems.
The SUSE Technical Support Handbook
You may have found this TID as a link from that same SUSE Technical Support Handbook, or found this TID directly in our knowledgebase.
The SUSE Technical Support Handbook contains a lot of generic support related details, but also how-to information on using SUSE Customer Center to create a Service Request, reaching out to SUSE Technical Support, escalate a ticket, etc etc.
The SUSE Technical Support Handbook can be found here : https://www.suse.com/support/handbook/
The SUSE Technical Support FAQ
This contains detailed information for example on SUSE's Support Offerings and Policies, Incident Process information but also details about the Chat system.
The support Frequently Asked Questions can be found here : https://www.suse.com/support/faq/
The SUSE Product Support Lifecycle
Another very important resource is the SUSE Product Support Lifecycle with information on for example when the 'General Support' phase for our products will end. This will determine if SUSE Technical Support is able to provide support for our product, or if this requires additional support offerings be purchased by our customers first.
The SUSE Product Support Lifecycle can be found here : https://www.suse.com/lifecycle/
When self-support for any encountered issues such as our SUSE Knowledgebase or our SUSE Support forums is not sufficient to resolve encountered problems, then please reach out to our SUSE Technical Support organization by opening a Service Request.
When opening a Service Request, provide the relevant details to the problem so that our Technical Support engineers have sufficient details to investigate the problem. The full set of questions we like to see answered are listed in the SUSE Technical Support Handbook under the section 'Information to include in your Incident'.
When opening a Service Request via the SUSE Customer Center, in order to allow the engineer to start the initial investigation, please see the details below.
Please provide answers to the following questions
Exactly WHAT is the problem?
- Which version of the SUSE product is (or products are) having the problem?
- Which service pack version is installed ?
- What problem is observed, and/or error messages (if any) are returned?
- What troubleshooting steps have already been performed?Exactly WHEN does the problem occur?
- When did the problem first occur?
- Were changes made prior to the problem occurring? If so, what (new installation of products, service packs, network changes, storage reconfiguration, and so forth, for example)?Exactly WHAT is the extent of the problem?
- Is a workaround available?
- What is the business impact of the problem? (How many users are affected?)
What kind of data is required by SUSE Technical Support
SUSE Technical Support uses various troubleshooting tools to investigate any issue, but we always start with asking for what we call a 'supportconfig'. This tool is part of the supportutils package. If required, this can also be manually downloaded and installed from the following SUSE Blog here.
In order to create a system overview report for SUSE Technical Support, please run (as the root user):
This tool will collect relevant system information and creates a compressed file in the '/var/log/' folder with the following file name:
Please make sure to always run the most recent version of supportutils that is available for better results, and please attach this file to the service request directly via the SCC portal. If outbound FTP traffic has been allowed in the corporate firewall, the archive may get uploaded from the server directly to the service request by using the following command:
supportconfig -ur <12digit_SR_number>
Note : Much of the information required to work on any technical issues may be too large to attach to a Service Request though, and as such we prefer files larger than 40MB be uploaded to our SUSE FTP servers. Which US or EMEA FTP servers can be used for this, and how this can be done manually, is detailed in TID 7023007.
Note : The latest version of the supportconfig tool will also default to uploading files to a SUSE FTP server, and no longer defaults to the FTP protocol but defaults to the https:// protocol insteda. This is to overcome many restrictions that some customers may have placed on using FTP services.
For SUSE Expanded Support based systems, the supportconfig tool should not be used, but a so called 'sosreport' should be provided.
Kernel Core Dump capture
If a system crashes, the possibility of capturing a kernel core dump is given using kdump. Its configuration is explained in TID 3374462 - Configure kernel core dump capture.
A best practices document about providing kernel core dumps to SUSE Technical Support is available at TID 7010056 - Best practice for providing kernel core dumps to support incidents.
For SLES Expanded Support based system please consult the corresponding online documentation for RHEL5 or RHEL6 on configuring kdump.
Please note: kernel core dumps must have been written completely to the dump device. To ensure this is the case, set KDUMP_IMMEDIATE_REBOOT to "yes" in /etc/sysconfig/kdump and wait for the system to reboot itself. Note that cores can be very large, so this may take a while. Forcing a reboot manually could interrupt the writing and result in an incomplete core. If the dump is incomplete for whatever reason an analysis will not be possible.
Application Crash Dump capture
When individual services are crashing, this will usually create a file called core or core.<pid>. We typically require an application crash bundle that contains the binary that crashed and shared libraries. Details on how to capture this can be found here TID 7018642 - How to Use getappcore for SUSE Technical Support
Steps to trace system reboots
In certain situations it is possible that no crash messages can be found in /var/log/messages (especially in case of situations where the system management board reset the hardware). Please also check if /var/log/mcelog contains any reports.
If this is the case, a hardware check should be started in the first place, and all hardware components should get patched to the most recent BIOS / firmware level. If the system crashes more often without leaving evidence connect a second system via a serial connection as outlined in TID 3456486 - Configuring a Remote Serial Console for SLES.
When a SLE system is running on a virtualization platform, please share the details for that platform with us.
In case of hardware virtualization platforms such as VMWare, Citrix, etc. Please share details such as the platform version, VM details, etc
For any problems related to High Availability, please provide the HB report details when opening a Service Request.
Details on how to capture these details can be founds here : TID 7007262 - Usage of hb_report for SLES HAE.
For any problems related to pacemaker cluster in connection with SAP HANA, please provide the data as requested here :
SUSE Enterprise Storage (SES)
The rule of thumb for any issues experienced with a SES cluster is to provide the following :
- supportconfig from the Admin / DeepSea node.
- supportconfig from each of the node(s) hosting the service(s) with which problems are observed.
For example, if there is a problem with a specific OSD (Object Storage Daemon) e.g. the OSD crashes, generate and attach supportconfig files for the node hosting the specific OSD(s) and also from the Admin node.
SUSE Openstack Cloud (SOC)
The rule of thumb for any issues experienced with a SOC environment is to provide the following :
- supportconfig from the Admin node.
- supportconfig from all the Controller nodes.
- supportconfig from the Compute node(s) with which problems are observed.
SUSE Container as a Service Platform (CaaSP)
The rule of thumb for any issues experienced with a CaaSP setup is to provide the following :
- supportconfig from the Admin node.
- supportconfig from the Master nodes.
- For Velum related problems, a screenshot from the Velum interface on the admin node.