Reads /proc, /sys, and common CLI tools (lscpu, lsblk, lspci, lsusb) to
print a YAML block matching data/schema.json: device model (DMI on x86,
/proc/device-tree/model on ARM SBCs), form factor (best-effort — battery
presence, DMI chassis type, device-tree presence), CPU, RAM, root storage
type/size, WiFi chip (PCI, then USB, then falls back to driver name rather
than guessing wrong), ethernet. Fields it can't detect (archy_version,
install_method, status) are left as clearly-marked TODOs rather than
guessed. Local-only — no network calls, changes nothing.
Tested for real on this box (a QEMU VM): correctly identified it as a VM,
correctly fell back to "other" with a TODO for form_factor rather than
guessing, output validated as parseable YAML. Passes shellcheck clean.
Linked from the homepage, report.html, and CONTRIBUTING.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gitea 1.27.1 on this instance silently ignores the ?template= param for
.github/ISSUE_TEMPLATE/hardware-report.yml — the structured fields never
render, just a blank title/body editor (confirmed live: same URL that's
supposed to load the form shows nothing). Rather than debug Gitea's YAML
issue-forms support, site/report.html is a plain form matching the schema
that builds a title + markdown body (with a ready-to-merge YAML block) and
opens Gitea's issues/new with them pre-filled via query params, which does
work on this instance (verified live).
Verified the full round trip in a real browser: filled the form, submitted,
confirmed the opened Gitea tab has the correct title and a body containing
valid YAML matching every field. Did not actually click "Create Issue" —
no reason to leave a test issue on the tracker.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ssmithxandClaude Sonnet 5