[Starosdev]

Summary

Some Hitachi and Toshiba drives answer an auto-detected smartctl query with no identity, SMART support is: Unavailable and no attributes. Scrutiny renders that as a failed disk with zero metrics. The documented remedy is to pin the device type in collector.yaml; for most of these drives that type is sat, which already reached smartctl. A configured type of scsi or ata did not.

All three smartctl call sites (detection --info, collection --xall, FARM log) carried a hand-copied guard:

if len(deviceType) > 0 && deviceType != "scsi" && deviceType != "ata" {
    args = append(args, "--device", deviceType)
}

The guard is correct for a type that came from smartctl --scan: container scans routinely mislabel ATA disks as SCSI, and forcing -d scsi on one loses its ATA attributes. It is wrong for a type the user wrote down, but models.Device carries no provenance, so the two were indistinguishable. The comparison was also exact-case, so type: 'ATA' was passed through while type: 'ata' was dropped.

Changes

• New detect.AppendDeviceTypeArgs is now the only place a device type becomes smartctl arguments. All three call sites route through it, so they cannot drift apart.
• A type configured for that device path in collector.yaml is passed verbatim, including scsi and ata. A type that is not configured keeps the existing suppression, now trimmed and case-insensitive.
• Provenance is resolved per call from Config.GetDeviceOverrides() (already on the interface, memoized). It cannot be a field on models.Device: the device type round-trips through /api/devices/register before Collect reads it back, so a collector-only field would not survive.
• nvme is unchanged and still passed through.

Behavior change on upgrade

A type: 'scsi' or type: 'ata' entry that was a silent no-op in earlier releases now takes effect. For a drive that was working through auto-detection, that can lose attributes. The troubleshooting doc calls this out and tells users to delete the entry if they want auto-detection. Worth repeating in the release notes.

Tests

go test ./collector/... passes. New coverage:

• detect_test.go: configured sat reaches the --info argv and populates model, serial, WWN and smart_support.available; the auto-detected response for the same drive yields the empty identity that produces the false failure; configured scsi is now passed; a configured device that inherits a scanned scsi still suppresses it; an uppercase scanned SCSI is suppressed.
• TestDetect_AppendDeviceTypeArgs: table over the resolution rules, including a type configured for a different device path.
• metrics_collect_test.go: configured sat reaches both the --xall and FARM calls; configured scsi is passed; a scanned scsi with nothing configured produces neither --device.
• Two new fixtures under collector/pkg/detect/testdata/.

Docs

• docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md: new section on drives reported as failed with zero SMART values, with the smartctl -a vs smartctl -a -d sat diagnosis and the upgrade note.
• example.collector.yaml: states that a configured type is passed verbatim.

Fixes #664

[Starosdev]

Merged (2026-07-28)

Changes Made

1. Single builder for the smartctl --device argument

   • New detect.AppendDeviceTypeArgs replaces the guard that was hand-copied into the detection (--info), collection (--xall) and FARM call sites
   • The three sites could previously drift apart, which is how the comma-splitting asymmetry in fix(collector): preserve jmb39x-q device type and accept usable SMART JSON #663 survived as long as it did

2. A configured device type is now passed verbatim

   • A type written in the devices section of collector.yaml reaches smartctl exactly as written, including scsi and ata
   • Previously those two were dropped, so a Hitachi or Toshiba drive pinned to type: 'scsi' silently fell back to auto-detection: the false-failure, zero-metric case in the issue

3. Scan-derived types keep the old behavior

   • A type that only came from smartctl --scan is still suppressed when it is scsi or ata, because container scans routinely mislabel ATA disks as SCSI and forcing -d scsi loses the ATA attributes
   • The comparison is now trimmed and case-insensitive, so type: 'ATA' no longer behaves differently from type: 'ata'
   • Provenance is resolved per call from Config.GetDeviceOverrides(), not from a field on models.Device: the device type round-trips through /api/devices/register before Collect reads it back, so a struct field would not survive

4. Docs

   • New troubleshooting section for drives reported as failed with zero SMART values, with the smartctl -a vs smartctl -a -d sat diagnosis
   • example.collector.yaml states the passthrough rule

Upgrade note

A type: 'scsi' or type: 'ata' entry that was a silent no-op in earlier releases now takes effect. For a drive that was working through auto-detection, that can lose attributes. Remove the entry to restore auto-detection. This belongs in the release notes.

PR	#678
Issue	#664
Branch	develop
Docker	ghcr.io/starosdev/scrutiny:develop