Skip to main content
This page explains which logs and context to provide when opening a support ticket for NVIDIA GPU infrastructure hosted by Nscale, without using the Nscale Log Gatherer package. The standard manual collection is:
  • The NVDebug Redfish/BMC support bundle, including generated files and reports, plus host logs when available and the NVDebug console log.
  • NVIDIA nvidia-bug-report.sh output.
Run commands with sudo or as root where possible so kernel, driver, hardware, and service logs are complete.

Before you collect logs

Collect logs as close to the failure time as possible. If the host is still running, collect logs before rebooting unless there is an operational reason to recover the system first. Include this context with every support request:

Severity guide

Use the severity that reflects actual business or service impact:

Dependencies

For the manual path:
  • Linux on the target NVIDIA GPU host or on a remote collection host that can reach the BMC and, when needed, the host OS.
  • sudo or root access is strongly recommended.
  • NVIDIA driver tooling, including nvidia-smi and ideally nvidia-bug-report.sh.
  • Python 3.12 and Python venv support for NVDebug.
  • curl or another approved method to download from GitHub.
  • unzip, tar, and gzip.
  • ipmitool for NVDebug IPMI-over-LAN collection.
  • BMC network access and credentials for the standard Nscale NVDebug bundle.
On Ubuntu, the usual setup is:
Do not install extra diagnostic tools unless Nscale Support specifically asks for them.

Create a working directory

Copy and paste this as one block. It creates the working directory and stores the path so later copy/paste blocks can find it.

Collect the NVDebug support bundle

NVDebug is NVIDIA’s diagnostic collection tool for NVIDIA server platforms. The downloadable GitHub project is named open-nvdebug; this guide refers to the tool as NVDebug. For the full vendor reference, see the NVIDIA NVDebug User Guide. For Nscale support cases, the important artifact is the generated NVDebug support bundle, not only the terminal output. The expected bundle contains both host-side logs and BMC/Redfish telemetry. Do not submit host-only or BMC-only collection unless absolutely necessary or Nscale Support explicitly asks for it. Why this guide asks for BMC details: NVDebug can run locally without BMC credentials, but that is a reduced host-local collection. NVIDIA documents that BMC-related collectors are skipped in that mode. For normal Nscale support, provide the BMC IP or hostname and credentials so the bundle includes Redfish/BMC and IPMI evidence. In most environments, the same BMC account is used for Redfish and IPMI access. Install ipmitool on the machine where NVDebug runs. In most cases, this is the affected host. Do not include this package or binary in the final support archive; it is only a runtime prerequisite for NVDebug’s IPMI-over-LAN collectors. sshpass is not required for the normal affected-host workflow in this guide. Nscale Support may ask for it only for a specific SSH-based collection path, such as some jumphost, BMC SSH, HMC SSH, proxy, or tunnel workflows. In most cases, run the next two commands on the affected host. The first command downloads NVDebug from the open-nvdebug GitHub repository and prepares it in a local Python virtual environment. The requirements.txt file is included in the downloaded open-nvdebug package and installs NVDebug’s Python dependencies. This guide uses nvdebug-v2.1.0-release; use a different release only if Nscale Support asks you to.

Download NVDebug and set up the environment

Run NVDebug and generate the support bundle

Run this block on the affected host. The affected host must be able to reach its BMC. This is the preferred collection path for most customers because NVDebug collects host logs locally and BMC/Redfish telemetry through the BMC details you enter. Do not paste passwords directly into the command line. The block below prompts for the required BMC/Redfish/IPMI details, creates the temporary NVDebug configuration automatically, runs NVDebug, and removes the temporary config file afterward.
Include the full generated NVDebug output directory and its matching console log: nvdebug-host-bmc/ plus nvdebug-host-bmc.stdout.txt, or nvdebug-jumphost/ plus nvdebug-jumphost.stdout.txt if you used the jumphost block. If NVDebug cannot collect both host logs and BMC/Redfish telemetry, include any nvdebug*.stdout.txt or Python error output and tell Nscale Support which access path failed.

Collect NVIDIA bug report

If nvidia-bug-report.sh creates nvidia-bug-report.log.gz, leave it in $LOGDIR so it is included in the final archive.

Add failure-specific logs

Targeted add-on commands

Run these only when the issue type matches or Nscale Support asks for them. Skip commands that are not available on the host and note that they were unavailable in the support request.
Active diagnostics: Run dcgmi diag -r 4 only when Nscale Support asks for it or when the host is available for a long-running active diagnostic.

GPU ECC, memory, row remapper, or page retirement

Unexpected reboot, power cycle, or host reset

NVMe, disk, filesystem, or RAID

System memory, CPU, MCE, EDAC, RAS, OOM, or host thermal

Create the archive

Attach the .tar.gz archive to tickets created in Jira with the context listed at the top of this page.

Alternative

Customers who approve the use of the packaged automated collector can use the Nscale Log Gatherer to collect the same diagnostic information in a single support bundle. Because the Nscale Log Gatherer is provided as a Python script, you can easily review its contents to verify exactly what data is collected before executing it.

Data notice

Support bundles may include hostnames, IP addresses, serial numbers, kernel logs, package versions, NVIDIA diagnostic output, BMC details, storage health data, and other operational metadata. Review the archive before sharing it if your environment requires data screening.