Skip to content

docs(nas): the console readings — it is the drive, head 5, and the pool-state rule cannot see it - #565

Merged
Gerrrt merged 5 commits into
mainfrom
gerrrt/erebor-triage-readings-e4999a
Sep 20, 2026
Merged

Gerrrt merged 5 commits into
mainfrom
gerrrt/erebor-triage-readings-e4999a

Conversation

@Gerrrt

@Gerrrt Gerrrt commented Sep 20, 2026

Copy link
Copy Markdown
Owner

Step 1 of replace-the-nas-disk.md, read at the console on 2026-09-19 at 23:19 PDT, recorded where the runbook says readings go.

What the console said

  • It is the drive. zpool status counts 3 read / 99 write errors on the leaf; dmesg from 20:47 is Logical unit not ready and 60 s command timeouts, task aborts, a target reset that changed nothing, with no link resets and no CRC; SMART reads 850 pending / 850 offline-uncorrectable against 0 / 0 the day before, Command_Timeout normalised to 1, health still PASSED; FARM puts all 850 reallocation candidates on head 5. The eBay return is the answer.
  • The exporter came back on docker restart media-node-exporter in 46 ms, and InstanceDown resolved.
  • The kstat reads online with a FAULTED leaf. So ZpoolNotOnline (feat(nas): erebor lost a disk one day in — a rule that reads pool state, the runbook for the swap, and the record of what fired first #559) cannot see this fault, and since 23:27 PDT nothing in the estate pages for a mirror on one disk. The rule's comment now says exactly what it can and cannot see; the runbook's open list carries the two ways out (a TrueNAS alert service to a phone channel, or a textfile metric on smaug, smaug has no SMART and no patch state, and the mechanism every other host uses is a push it cannot make #483's argument), and erebor lost ZVTBSDL3 at lifetime hour 27, node_exporter hung nine minutes before the fault, and erebor/apps has no copy anywhere else #558 has the line.
  • The pair is behind a RAID card nobody recorded. lspci -nn reads a Broadcom / LSI MegaRAID SAS-3 3008 "Fury" (1000:005f, the SAS3008's MegaRAID personality) at 01:00.0, with both Exos under its host0 and the chipset's ata1ata5 link down at boot. hardware.md gets the card and stops crediting AHCI with keeping a controller out from between ZFS and its disks; build-the-nas.md §1's SATA2/SATA3 is corrected in place; the disk runbook's step 4 now checks that a replacement disk appears in lsblk at all, since a RAID card not in JBOD mode holds a fresh disk as Unconfigured Good. The driver's boot log then settled the mode: megaraid_sas, controller type iMR(0MB) (cacheless, no battery), subsystem 9340, JBOD sequence map enabled — the disks are JBOD pass-through, not virtual drives. The firmware version is the one reading still owed.

Files

docs/runbooks/replace-the-nas-disk.md (status block, step 4, open list), docs/hardware.md (smaug and Exos entries), docs/runbooks/build-the-nas.md (§1 correction), stacks/observability/prometheus/rules/host.rules.yaml (comment only; no rule change).

Refs #558, #483.

🤖 Generated with Claude Code

Gerrrt and others added 2 commits September 20, 2026 06:35
…ol-state rule cannot see it

Step 1 of replace-the-nas-disk.md read at the console on 2026-09-19 23:19
PDT: zpool status counts 3 read and 99 write errors on the leaf; dmesg is
"Logical unit not ready" and 60-second timeouts from 20:47 with no link
resets and no CRC; SMART reads 850 pending and 850 offline-uncorrectable
sectors against 0 and 0 the day before, Command_Timeout normalised to 1;
FARM puts all 850 on head 5. The drive, not the path — the return is the
answer.

The exporter came back on a restart, InstanceDown resolved, and the kstat
behind node_zfs_zpool_state reads online for erebor with a FAULTED leaf:
ZpoolNotOnline (#559) cannot see the fault that produced it, and nothing
in the estate now pages for a mirror on one disk. The rule's comment says
so; the runbook's open list carries the two ways out and one thing the
readings do not match the docs on — sdb enumerates under a SCSI host on
the PCIe slot, not the board's SATA2/SATA3.

Refs #558, #483.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Gerrrt and others added 3 commits September 20, 2026 06:52
…ever recorded, not the board's SATA2 and SATA3

lspci at the console on 2026-09-19: a Broadcom / LSI MegaRAID SAS-3 3008
"Fury" (1000:005f, the SAS3008's MegaRAID personality) at 01:00.0, with
both sda and sdb under its host0 and the chipset's ata1-ata5 reading link
down at boot. The AHCI setting hardware.md credits with keeping a
controller out from between ZFS and its disks protects the boot SSD and
nothing else, and build-the-nas.md §1's cabling was what was believed, not
what was cabled. Both say so now; the card has an entry; the disk runbook's
step 4 checks that a replacement appears in lsblk at all, because a RAID
card not in JBOD mode holds a fresh disk as Unconfigured Good. Firmware
and mode are the two readings still owed.

Refs #558.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…e driver's boot log

dmesg at the console: megaraid_sas 07.727.03.00-rc1, controller type
iMR(0MB), subsystem 1000:9340, Secure JBOD supported, JBOD sequence map
enabled — the disks are JBOD pass-through, not virtual drives, which is
why smartctl reaches them by their own model. No write cache and no
battery. The driver logged an interrupt disable/enable at 21:03:51 on
2026-09-19, the same second as the target reset in the fault's dmesg: the
controller resetting itself around a disk that had stopped answering. The
firmware version is the one reading still owed, from
/sys/class/scsi_host/host0/fw_ver.

Refs #558.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…off the POST banner at the swap

/sys/class/scsi_host/host0/fw_ver does not exist, read at the console on
2026-09-19; megaraid_sas exposes crash-dump and queue attributes there
and nothing about its firmware, and TrueNAS ships no storcli. The version
comes off the card's POST banner or its Ctrl-R controller properties, so
the hardware entry and the runbook now say it is owed from step 4, when
the machine is at POST for the swap anyway.

Refs #558.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Gerrrt
Gerrrt merged commit bd39edd into main Sep 20, 2026
3 checks passed
@Gerrrt
Gerrrt deleted the gerrrt/erebor-triage-readings-e4999a branch September 20, 2026 07:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant