How to Install and Use sosreport in Ubuntu to Generate System Diagnostic and Support Reports

When troubleshooting enterprise Linux server outages, kernel crashes, network degradation, or hardware anomalies, gathering disparate log files, kernel rings, and configuration parameters manually is time-consuming and prone to human error. In enterprise environments, Canonical and Red Hat rely on sosreport (provided by the sos package). sosreport is an automated diagnostic utility that inspects the operating system, executes auditing plugins, redacts sensitive customer credentials, and packages system telemetry into a single compressed archive for deep post-mortem analysis.

What sosreport Collects from Ubuntu

sosreport employs a modular architecture featuring dozens of pre-configured plugins tailored for Ubuntu systems:

• Hardware & Architecture: Dumps PCI devices, USB controllers, CPU microcode versions, DMI/SMBIOS records, and storage drive telemetry.
• Kernel & Modules: Captures dmesg kernel rings, loaded kernel modules (lsmod), sysctl tuning parameters, and memory states.
• Storage & Filesystems: Audits block device topologies, mount points, LVM volume configurations, mdadm RAID statuses, and ZFS pools.
• Networking: Collects IP addressing, routing tables, firewall rules (UFW and iptables), Netplan YAML specifications, and interface statistics.
• Systemd & Services: Documents running unit statuses, failed services, and systemd journal logs.
• Privacy & Data Obfuscation: Automatically strips passwords, private cryptographic keys, and sensitive tokens from collected configuration files.

Installing the sos Package on Ubuntu

On modern Ubuntu releases (including Ubuntu 20.04 LTS, 22.04 LTS, and 24.04 LTS), the tool is maintained within the standard universe repository under the sosreport package alias:

1. Open your terminal and refresh your APT package lists:

   sudo apt update

2. Install the sosreport package:

   sudo apt install -y sosreport

3. Verify the installation and review active plugins:

   sos report -l

Generating a Comprehensive Diagnostic Report

Because gathering low-level system logs requires reading protected kernel and root files, running the report requires superuser privileges:

sudo sos report

During the interactive initiation phase:

1. sosreport displays a disclaimer noting that configuration data will be archived. Press Enter to proceed.
2. You will be prompted to enter a customer case number or administrator ID. Enter an identifier or press Enter to skip.
3. The utility will systematically execute its plugin suite across CPU, memory, networking, and systemd components. Progress is shown in real time.
4. Once complete, sosreport writes a compressed archive (typically a .tar.xz file) along with an SHA-256 checksum file to the /tmp directory:

   /tmp/sosreport-ubuntu-server-2026-10-15-abcdef.tar.xz

Running Non-Interactive Reports in Automation Scripts

If you need to trigger a diagnostic report automatically from a monitoring alert or Ansible playbook, execute the command in non-interactive batch mode:

sudo sos report --batch --name "incident-node-01" --tmp-dir /var/log/diagnostics/

Command Flag	Function	Use Case
--batch	Bypasses all interactive user prompts, answering yes to disclaimers automatically.	Automated incident response scripts and cron jobs.
--name	Appends a custom host or ticket tag to the generated filename.	Multi-server fleet fleet triage and ticket organisation.
--only-plugins	Restricts collection to specific subsystem plugins (e.g. networking,kernel).	Targeted debugging without generating massive multi-gigabyte files.
--clean	Performs aggressive IP address, hostname, and MAC address anonymisation.	External vendor audits and public bug reports.

Inspecting and Extracting the Generated Report

To inspect the report locally before sharing it with support engineers:

mkdir ~/report-audit && cd ~/report-audit
tar -xf /tmp/sosreport-ubuntu-server-*.tar.xz
ls -la

Inside the extracted directory, examine sos_reports/manifest.json for execution metadata and browse subsystem folders like etc/, proc/, and var/log/ to inspect exact server states captured at the time of the incident.