'trident diagnose' subcommand

[nbojanic]

Goal
Give trident users a single command they can run to generate a troubleshooting bundle to submit when reporting an issue. The bundle should contain the data necessary for a dev to debug/understand an issue with Trident.

This document outlines the info the command collects and the structure of the bundle it produces for design discussion.

---

Info collected

Item	Description
Datastore	Datastore SQLite databases--checks default, configured and temporary locations
Logs	Current background log file
Historical logs	Previous log files from datastore directory
Metrics	Metrics file
Trident version	Version string of the trident binary
Timestamp	Report generation time
Container detection	Whether trident is running in a container
Virtualization type	baremetal, qemu, or hyper-v (from dmi info)
Kernel version	Linux kernel release
Asset ID	Hardware identifier (UUID)
OS release	os-release
CPU count	Number of CPUs
Memory	Total memory in GiB
Disk info	Block device layout (from lsblk)
Host status	Current HostStatus

Not collected
COSI file content (image specification)

Bundle structure
The bundle produced by this command is a .tar.zst zst compressed tarball. Everything other than log, metrics and datastore files is serialized in report.json. The tarball has the following structure:

trident-diagnostics/
├── report.json
├── datastore.sqlite
├── datastore-tmp.sqlite
├── datastore-configured.sqlite
└── logs/
    ├── trident-full.log
    ├── trident-metrics.jsonl
    └── historical/
	    ├── trident-*.log
	    ├── trident-*-metrics.jsonl
        └── ...

tmp and configured datastore are only collected if those paths exist.

Privacy considerations
The diagnostics bundle contains system information. Users should review the bundle contents before sharing:

Data	Privacy Note
Host status	Contains system configuration and potentially user-specified settings
Asset ID	DMI UUID that uniquely identifies the machine
Logs	May include file paths and command output
Datastore	Contains deployment history and configuration state
Disk info	Reveals storage layout and device names

[frhuelsz]

Suggestion: add --full-dump or similar to also add all system journal and dmesg entries.

[frhuelsz]

Add /etc/fstab

[frhuelsz]

Output of df ?

[ayaegashi]

Add audit logs, i.e. /var/log/audit/audit.log (for SELinux) from both servicing OS and target OS

[frhuelsz]

+1 but perhaps feature flag it? not sure how much info this could expose

[ndubchak]

TPM 2.0 state: PCR values, keyslots, etc. Maybe systemd-pcrlock log and pcrlock.json contents, if it exists

[ndubchak]

If the Host Configuration contains healthChecks, collect status of systemd services?

[frhuelsz]

add: best effort attempt to get COSI metadata from the latest spec

[frhuelsz]

best effort systemctl status trident.service and journalctl -u trident.service

[ndubchak]

Output of mount?

[frhuelsz]

and findmount -J :)

[ndubchak]

btw there are multiple metrics files, one for each servicing, same as with the background log files

[frhuelsz]

from Brian: /sys/firmware/efi/efivars