T

Julien LutranandClaude Opus 5 81d22c5daf nas+nuc: cold boot verified; record what clearing the metadata errors took

Both hosts were powered off and brought back from a cold start, which is
the first real test of everything built on 2026-08-30.

nas: both pools imported from /etc/zfs/zpool.cache, all instances
autostarted, NFS exports republished, 0 failed units. nuc: /dev/dri
present with 0 i915 warnings (booted with the display unplugged), NFS
auto-remounted, VAAPI transcode at 9.5x realtime.

Records the ordering that actually cleared tank's inherited
<metadata>:<0x0> and <0x3d>: a scrub alone found 0 errors and repaired 0B
but left them, and a plain `zpool clear` afterwards did not drop them —
ZFS flushes the persistent error log on a scrub run *after* the clear.
That matters beyond tidiness, because while those entries stand
`zpool status -x` reports the pool unhealthy forever and zpool-health.sh
cannot signal anything new.

Two kiosk corrections, both from observed behaviour:

- the Pioneer DAC being switched off is the most likely cause of
  "video, no sound" — asound.conf pins the ALSA default to it by card
  name, so `default` fails to open outright and mpv falls back to null
  silently. Adds the one-line aplay check.
- hotplugging the display makes cage exit once and Restart=on-failure
  recovers it ~5s later. Do NOT restart it by hand; check
  ActiveEnterTimestamp against the hotplug time first.

Also flags that the OS mirror is still untested with a disk physically
unplugged — it is a guess until then.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-31 10:16:44 +02:00

archer-c7

plakar-s3-data: seed done except seafile-fs (EINTR livelock, excluded)

2026-08-24 00:07:01 +02:00

ks2

docs: follow the storage move from nuc/USB to nas/SATA

2026-08-31 09:32:29 +02:00

ks4

docs: follow the storage move from nuc/USB to nas/SATA

2026-08-31 09:32:29 +02:00

nas

nas+nuc: cold boot verified; record what clearing the metadata errors took

2026-08-31 10:16:44 +02:00

nuc

nas+nuc: cold boot verified; record what clearing the metadata errors took

2026-08-31 10:16:44 +02:00

backup-strategy.md

docs: follow the storage move from nuc/USB to nas/SATA

2026-08-31 09:32:29 +02:00

new-container.md

doc: instance leg to S3 shelved; ks2 push is the interim off-site leg

2026-08-28 16:17:11 +02:00

README.md

nas: new storage host on A1SAi-2750F — 4 TB off USB onto SATA

2026-08-30 23:53:30 +02:00

README.md

Personal infrastructure notes

Two repositories back this setup: doc (this one) and scripts (the cron drivers and their config files, deployed to /root/scripts on each host).

Start here:

backup-strategy.md — what is backed up, by which tool, on what schedule, and how to restore.
new-container.md — conventions for adding a service to ks4 (and getting it backed up automatically).

Tech notes

nuc/ — home lab on nuc: host, iGPU instances
nas/ — storage + backup host nas (Supermicro A1SAi-2750F): the 4 TB on direct SATA, media over NFS, backup pools
ks4/ — prod server ks4 at OVH: host, services, network flows
ks2/ — legacy backup server being decommissioned
archer-c7/ — home router (TP-Link Archer C7 v5 running on OpenWrt)

Conventions

One markdown file per topic in the correct subdir, containing the full implementation notes, configuration, and troubleshooting notes.
Containers are built from Debian/Ubuntu images and configured exclusively through incus exec/incus config so the doc is the single source of truth — rebuilding = re-running the script.
Adding a service to ks4: follow new-container.md (no Docker in containers — incus runs OCI images natively and incus-compose handles stacks; data paths go into scripts/restic-paths).