The dead end: no error, just nothing

The Super I/O chip on these Tiny-series boards is a Nuvoton NCT6683, and the matching kernel driver is nct6683 (part of lm-sensors). Normally you modprobe nct6683, run sensors-detect, and get fan1/fan2 readings for free. Here, modprobe nct6683 returned cleanly, but sensors still showed no fan entry:

modprobe nct6683
sensors
# coretemp-isa-0000 and peci entries present, no nct6683 block at all
dmesg | grep -i nct6683
# (nothing)

No error message, no log line, nothing in dmesg — the module just wasn’t registering a device. That absence of any error is the tell: this isn’t a missing-driver problem, it’s a driver that loaded and then quietly declined to attach to the hardware.

The cause: an EC firmware/vendor check

The nct6683 driver does a sanity check against the embedded controller’s firmware build ID before it will bind — it’s a safety measure, since writing to the wrong registers on an unrecognized EC build can do bad things. This M900 Tiny’s EC firmware build (1.0 build 12/30/15) isn’t in the driver’s list of known-good builds, so the check fails and the driver bails out with ENODEV before ever creating the sensor device — silently, since this is treated as “unsupported hardware,” not an error condition.

The driver exposes an escape hatch for exactly this: a force module parameter that skips the vendor/build check and binds anyway.

modprobe -r nct6683
modprobe nct6683 force=1
sensors

With force=1, sensors immediately reports a new block with fan2 reading a baseline of roughly 980 RPM, alongside the existing coretemp/PECI entries.

Making it persistent

A manual modprobe force=1 doesn’t survive a reboot, and doesn’t help if nct6683 isn’t in the auto-loaded module list at all. Two small config files fix both:

# Force the parameter every time the module loads
echo "options nct6683 force=1" > /etc/modprobe.d/nct6683.conf

# Make sure the module actually loads at boot
echo "nct6683" >> /etc/modules

update-initramfs -u
reboot

After the reboot, sensors shows fan2 without any manual intervention — same as it would if the driver’s built-in check had recognized the board in the first place.

Reference

If a Super I/O sensor driver loads without error but produces zero fan/temp entries and dmesg is silent, a vendor or firmware-build allowlist check inside the driver — not a missing driver — is worth suspecting before anything else.

This guide was written by Claude, an AI assistant made by Anthropic, based on a hands-on troubleshooting session working through this exact problem.

The problem: it grew past “I just know”

For a while, the mental model of the network lived entirely in my head. That works until a switch port flaps, a VM migrates, or a device gets a new IP, and you find out about it by symptom rather than by signal — the “why is the Wi-Fi pod offline” question that turns into twenty minutes of SSHing into things to check link status one port at a time.

The fix was to stop treating the network as a black box and start treating it like the rest of my infrastructure: observable, documented, and — where it’s safe to do so — automatable.

A small internal webapp

The centerpiece is a small internal dashboard with a handful of tabs:

• Topology — a live, auto-generated map of the LAN: router, switches, and every device, drawn from an actual scan rather than a diagram someone has to remember to update.
• Graph — the same topology, but as an actual graph database (Neo4j) rebuilt from scratch every 15 minutes. It’s deliberately current-state only, not a history store — every sync wipes and rebuilds the graph, so a query always reflects what’s plugged in right now. The tab embeds the real Neo4j Browser so I can run ad-hoc Cypher queries against my own LAN (“what’s connected to this switch port,” “show me every device with no hostname”) instead of grepping through ARP tables.
• Monitoring — Grafana/Prometheus, for the metrics side of things.
• Switch — port status and traffic for the managed switches, without opening their web UIs.
• Syslog — the one that ended up mattering most in practice.

Syslog: making the logs actually watch something

Every host on the network already ships logs to a central syslog collector — hundreds of sources’ worth. The problem was that nothing was reading them. The answer to “why did the WiFi pod drop” was sitting in a switch’s log the whole time (a port link-down event), completely unwatched.

The Syslog tab adds two things on top of the raw collector: a searchable, multi-host log viewer (term/regex filters, time ranges — with hundreds of sources and a lot of history, filtering has to happen server-side, not in the browser), and user-defined notification rules. A small engine runs every minute, tails only the new bytes each watched log has grown by, matches them against the rules, and — on a match, respecting a per-rule cooldown so one flapping port doesn’t turn into a hundred pages — fires a webhook into Home Assistant, which turns it into a phone notification.

It’s a small feature, but it’s the difference between “the network told me something broke” and “I noticed something was broken.”

Giving Claude Code supervised hands on the network

The more interesting piece, for me, was building an MCP (Model Context Protocol) layer so Claude Code can act on the network directly instead of me relaying show command output back and forth by hand. There’s a small set of MCP servers, each scoped to one thing:

• One that talks to the router — reads configuration and running state, and can apply changes (like adding a static host mapping) over SSH.
• One that reads switch port status and traffic over SNMP.
• One that lists and controls VMs/containers on the Proxmox cluster via its API.
• One that reads the centralized logs.
• A generic SSH connector for anything else on the LAN.

The point isn’t “let an AI reconfigure my network unsupervised” — it’s narrowing the interface. Each server exposes a specific, reviewable set of actions instead of a raw shell, so when I’m working through something like a VLAN migration or a switch swap with Claude Code, it can genuinely read the live state of the router and switches and reason about port assignments and firewall rules against what’s actually deployed — not against my possibly-stale mental model of it — while every actual change still goes through review before it’s applied.

The VLAN problem consumer mesh WiFi can’t solve

The most concrete recent project this stack enabled: putting IoT devices and IP cameras on their own isolated VLAN, firewalled off from the trusted network, while leaving everything else alone.

The obvious approach — tag a dedicated SSID to a VLAN on the existing mesh WiFi — turned out to be a dead end. Consumer-tier mesh systems generally don’t support mapping individual SSIDs to VLANs; that’s an enterprise-AP feature. Rather than replace a perfectly good mesh system, the fix was to add a couple of cheap, dedicated access points running OpenWrt, configured as dumb bridges rather than routers: no DHCP, no routing, no firewall of their own, just WiFi bridged straight onto a switch port that’s hard-set to the IoT VLAN. The switch does all the VLAN tagging; the access point doesn’t need to know VLANs exist at all.

On the router side, that VLAN gets its own subnet, its own DHCP scope, and a firewall policy that defaults to drop everything inbound except:

• established/related traffic (so replies to connections IoT devices themselves initiated still work),
• a narrow allow rule for the one thing that has to reach in — MQTT traffic to the home-automation host, so IoT devices can publish to it,
• and outbound internet access, since these devices still need it for NTP, firmware updates, and cloud features.

Everything else from the IoT VLAN toward the trusted network is dropped by default. Traffic in the other direction (trusted → IoT) stays unrestricted, since it’s the automation/monitoring hosts polling into the IoT VLAN, not the reverse, that needs to keep working.

The one wrinkle worth calling out for anyone doing this themselves: mDNS and similar local-discovery protocols don’t cross VLAN boundaries. Anything that relies on discovery (some smart-home integrations) needs a static IP/reservation instead of “just works” auto-discovery once it’s segmented.

Naming things like infrastructure, not like guesses

A smaller but satisfying piece of this: formalizing a DNS naming standard. Some of my hostnames dated back to a previous job’s naming convention (CLLI codes, if you know, you know) and had long since stopped meaning anything to anyone but me. The new standard is boring on purpose — a short role code plus a number for physical hosts (router, switch, storage, etc.), the purpose itself as the name for single-role VMs, and a separate tier of service aliases that point at whichever host currently provides a service and move with it if that ever changes. It’s a small thing, but “the name tells you what it is” pays for itself every time you’re debugging at 11pm.

Where this leaves things

None of this is exotic — a graph database, a syslog watcher, some MCP servers, and a VLAN. What made it worth doing was treating a home network like it deserves the same basic care as any other system I run: know what’s on it, get told when it breaks, and keep the blast radius of any one compromised device small. The AI-copilot layer is the part I’d call genuinely new — not because it does anything a human couldn’t, but because it turns “let me SSH into six things to check” into a conversation grounded in what the network actually looks like right now.

The end state: a Pi 5 (pi5-2) serving NTP to the LAN, disciplined by a u-blox NEO-series GPS module. The GPS’s NMEA sentences over serial say which second it is; a PPS (pulse-per-second) line on GPIO18 says exactly when that second starts. chrony locks onto the PPS pulse as its primary source, and the whole LAN gets genuine stratum-1 time.

Hardware

• Raspberry Pi 5
• A cheap u-blox NEO-6M/7M/8M GPS breakout board
• An outdoor active GPS antenna (added later — more on why below)

Wiring to the GPIO header:

The first debugging lesson, before any software was involved: if the module’s status LED never blinks, check the power pin voltage before anything else. A GPS module that looks “dead” is very often just under-powered.

Software setup

The UART on the GPIO header defaults to being the serial console/login shell, so that has to be freed up first:

raspi-config nonint do_serial_cons 1   # disable login shell over serial
raspi-config nonint do_serial_hw 0     # enable the UART hardware (adds
                                        # dtparam=uart0=on on Pi 5)
reboot                                 # required for the overlay to apply

Then install the two pieces that do the actual work:

apt install gpsd gpsd-clients chrony

gpsd talks to the GPS module and parses its NMEA output; chrony is the NTP daemon that turns that (plus PPS, later) into disciplined system time and serves it to the LAN.

Point gpsd at the device in /etc/default/gpsd:

DEVICES="/dev/ttyAMA0"
GPSD_OPTIONS="-n"

And give chrony a GPS refclock in /etc/chrony/conf.d/gps.conf:

refclock SHM 0 refid NMEA precision 0.05 poll 3 filter 8 offset 0.142
allow 192.168.1.0/24
local stratum 10

Then systemctl enable --now gpsd.socket gpsd.service chrony.

That looks simple. Getting there wasn’t — two gotchas ate most of the debugging time, and neither is obvious from the standard docs.

Gotcha #1: /dev/serial0 is a trap on the Pi 5

The conventional wisdom is “use /dev/serial0, it’s the stable alias for the GPIO UART.” On this Pi 5 + Bookworm image, that’s wrong. serial0 resolves to ttyAMA10 — the SoC’s internal PL011 UART, not the RP1 UART actually wired to the GPIO14/15 header pins. The header UART is ttyAMA0.

This is a nasty one to debug because every surface-level check says it should work: the device exists, gpsd can open it without error, and pinctrl shows the pins correctly muxed to TXD0/RXD0. It just silently receives zero bytes, because it’s listening to a UART with nothing physically connected to it.

I confirmed it by comparing /sys/class/tty/ttyAMA*/device/of_node against /proc/device-tree/aliases/serial0 (they pointed at different device-tree nodes), and with a physical loopback test — a jumper wire between pins 8 and 10, then writing and reading /dev/ttyAMA0 directly to prove the header UART was the one actually moving bytes.

Fix: use /dev/ttyAMA0, not /dev/serial0, on this board.

Gotcha #2: gpsd’s chrony SOCK integration is PPS-only

gpsd ships wired up to feed chrony directly over a Unix socket at /run/chrony.<device>.sock (chrony creates the socket; gpsd connects to it as a client, which is the opposite of what the naming suggests). It looks like the obvious modern integration path. On a module with no PPS wire yet, it just doesn’t work — refclock SOCK /run/chrony.ttyAMA0.sock sits at reachability 0 forever, with no error logged anywhere.

Digging through the strings in the gpsd binary turned up the reason: "PPS:%s using chrony socket ..." — that path only activates once gpsd has a PPS source. No PPS wire, no socket traffic, ever, silently.

Fix: use the older refclock SHM 0 interface, which gpsd always populates with coarse NMEA/UBX-derived time regardless of whether PPS is present. That’s the refclock SHM 0 refid NMEA ... line above.

Calibrating the NMEA offset

Without PPS, NMEA time arrives late over the serial link by a fixed amount — on this setup, a very stable +142ms (std dev under 2ms once the outdoor antenna gave a solid fix). That’s calibrated out with the offset parameter:

1. Let chrony run with a good GPS fix for a few minutes.
2. Read the Offset column for the GPS source in chronyc sourcestats — its offset relative to the NTP-disciplined system clock.
3. Put that value (in seconds, same sign) on the refclock SHM line’s offset parameter and restart chrony.
4. Verify with chronyc sources: the GPS offset should now sit within a few milliseconds of the pool servers.

The precision 0.05 on that line claims a conservative ±50ms error bar — small enough that chrony selects GPS as primary, large enough that if the NMEA latency ever drifts substantially, the pool servers out-vote it and chrony marks it a falseticker instead of quietly following bad time.

Indoors, the module struggled to get a fix at all. An outdoor active antenna fixed that — a solid fix on ~10 satellites is what made everything past this point (including PPS) practical.

Reading chronyc sources

If you haven’t stared at chrony output before, the symbols are worth knowing:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#- NMEA                          0   3   377     2   +1234us[+1230us] +/- 50ms
^* time.pool.example.org         2   6   377    23   -123us[ -089us] +/-  12ms
^+ ntp2.pool.example.org         2   6   377    41   +456us[ +460us] +/-  15ms

• # marks a reference clock (GPS); ^ marks a network peer.
• * is the currently selected source; + is a candidate in agreement; - is reachable but not currently selected/combined.
• The trailing +/- Nms is chrony’s estimated error bound for that source — this is what the precision setting on a refclock line ultimately informs.

The PPS upgrade

NMEA-only gets you agreement with the pool to a couple of milliseconds, but the true accuracy is only as good as that +142ms latency is stable — and it can shift if gpsd, the sentence mix, or the module changes. PPS fixes this properly: it’s a hardware pulse on the exact top of each second, so sub-second timing stops depending on a measured constant entirely. The NMEA sentence still supplies which second it is; PPS supplies the precise edge within it.

1. Enable the PPS overlay. In /boot/firmware/config.txt (Bookworm’s path — not /boot/config.txt):

dtoverlay=pps-gpio,gpiopin=18

reboot for the overlay to load. GPIO18 is just the convention dtoverlay=pps-gpio defaults to; any free GPIO works if gpiopin= matches the wire.

2. Confirm the kernel sees pulses:

apt install pps-tools
lsmod | grep pps_gpio          # pps_gpio module loaded
dmesg | grep pps                # "new PPS source pps@12" + "Registered IRQ"
ppstest /dev/pps-gps            # one "assert" line per second, timed

If ppstest prints nothing, either the module has no fix yet (most NEO boards don’t pulse PPS without one) or the wiring/gpiopin is wrong.

3. Gotcha: /dev/ppsN numbering is a boot-time race. On the Pi 5, the Ethernet controller’s PTP clock (ptp0) and the GPIO PPS both register as /dev/pps*, and which number each gets depends on probe order at boot. On this box the GPIO PPS came up as pps0 and the Ethernet PTP clock as pps1 — the opposite of what I’d first assumed, and the opposite of how it had been before adding PPS. Trusting a bare device number risks chrony silently locking onto the Ethernet PTP clock after a reboot: no error, just quietly wrong time.

The fix is to match on the stable device-tree name instead of the number, via a udev rule (/etc/udev/rules.d/10-pps-gps.rules):

SUBSYSTEM=="pps", ATTR{name}=="pps@12.-1", SYMLINK+="pps-gps"

Then udevadm control --reload-rules && udevadm trigger --subsystem-match=pps, and confirm /dev/pps-gps points at whichever ppsN is actually the GPIO source. Check the name on your own board with cat /sys/class/pps/pps*/name — the GPIO one is the pps@NN entry, the Ethernet one is ptp0.

4. Add the PPS refclock to chrony. Keep the existing NMEA line (it still supplies the integer second) and add a native PPS refclock locked to it, in /etc/chrony/conf.d/gps.conf:

refclock SHM 0 refid NMEA precision 0.05 poll 3 filter 8 offset 0.142
refclock PPS /dev/pps-gps refid PPS lock NMEA precision 1e-7 poll 3 prefer

• lock NMEA tells chrony to take the ambiguous PPS second-number from the NMEA refclock — so the calibrated offset 0.142 still matters, just for a much looser reason: it only needs to land NMEA within ±0.2s of the pulse to keep the lock, and 142ms is comfortably inside that.
• prefer makes PPS the source chrony actually steers to; the pool servers and NMEA become agreement/sanity checks rather than the trusted source.
• precision 1e-7 (~100ns) tells chrony this is a high-quality source, so it gets weighted well above NMEA and the pool.

Restart chrony. In chronyc sources -v, PPS should now be the selected source (#*) with an estimated error in the hundreds of nanoseconds, NMEA reachable but not combined (#-, it’s just supplying the lock), and the pool servers as agreement checks (^-). journalctl -u chrony logs Selected source PPS.

Simpler alternative: once PPS is wired, gpsd’s SOCK integration from gotcha #2 finally has a PPS source to report, so refclock SOCK /run/chrony.ttyAMA0.sock refid GPS precision 1e-7 prefer works too, letting gpsd handle the PPS plumbing. I kept the native refclock PPS line instead — it’s explicit about the NMEA lock, doesn’t depend on gpsd’s internal PPS handling, and sidesteps needing gpsd to pick the correct device. SOCK is one line if you’d rather use it.

Where accuracy ended up

The calibrated NMEA constant went from “the thing being trusted” to a wide safety margin that only has to hold the PPS second-lock — a much easier job than being the actual accuracy source.

Verifying it’s all working

gpspipe -w -n 20        # raw gpsd JSON: satellites, fix mode, position
cgps -s                  # live satellite dashboard
ppstest /dev/pps-gps     # confirm PPS pulses (one assert/sec) reach the kernel
chronyc sources -v       # confirm PPS is selected (#*), NMEA reachable (#-)
chronyc sourcestats

If chronyc sources shows #* next to PPS, the whole chain — antenna, module, kernel PPS, chrony — is doing its job, and every other device on the LAN syncing against this Pi is getting time that isn’t waiting on an internet connection to be right.

It also documents the specific mistakes that commonly break this install, so you can avoid them.

Applies to: Debian 12 (Bookworm), Optimus laptops with Intel iGPU + NVIDIA dGPU. Examples use an NVIDIA T600 Laptop GPU (Turing, TU117) at PCI address 01:00.0. Adjust the PCI address to match your hardware (find it with lspci | grep -i nvidia).

Before you start: know your starting state

Before installing anything, confirm what the system is actually running. This avoids fighting a half-configured driver. Run:

lspci -k -s 01:00.0                # which kernel driver is bound to the GPU?
lsmod | grep -E 'nvidia|nouveau'   # which modules are loaded right now?
dpkg -l | grep -i nvidia           # any NVIDIA packages already installed?
ls -la /etc/X11/xorg.conf          # is there a leftover X config? (there should NOT be)

On a fresh system you will typically see the open-source nouveau driver bound to the card, no NVIDIA packages installed, and no /etc/X11/xorg.conf. That is the clean baseline this guide assumes.

If /etc/X11/xorg.conf exists, deal with it first. A stale X config — usually left behind by a previous nvidia-xconfig run — is the single most common reason a “clean” reinstall still produces a black screen. Move it out of the way: sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak. On a PRIME/Optimus laptop you want no hand-written xorg.conf at all.

Step 1 — Enable the non-free repositories

The NVIDIA driver lives in Debian’s non-free component. Check your sources:

cat /etc/apt/sources.list

Each Bookworm line should include contrib non-free non-free-firmware. For example:

deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware

If your system uses the newer deb822 format instead, you’ll have a .sources file under /etc/apt/sources.list.d/; add contrib non-free non-free-firmware to its Components: line rather than editing sources.list.

Step 2 — Install kernel headers and the driver

The kernel headers are not optional. Without them, DKMS has nothing to build the NVIDIA kernel module against, and the install will silently do nothing — you’ll reboot and still be on nouveau with no obvious error. Install the headers first, then the driver:

sudo apt update
sudo apt install linux-headers-amd64
sudo apt install nvidia-driver mesa-utils

The nvidia-driver metapackage pulls in nvidia-kernel-dkms and builds the module during installation. mesa-utils gives you glxinfo for verification later.

Watch the two messages that appear during install — both are normal and neither is an error. They’re explained next.

“Conflicting nouveau kernel module loaded”

The installer warns that nouveau is currently loaded and conflicts with the NVIDIA module. This is expected: nouveau is driving the card in your running session and can’t be swapped out live. The install adds a modprobe blacklist for nouveau; the switch happens on reboot. Just acknowledge the dialog and let the install finish.

DKMS builds for the current kernel and may “skip” an old one

If you recently ran a system upgrade, you may have more than one kernel installed. DKMS builds the module for your current/newest kernel and may report skipping an older one:

Building for 6.1.0-XX-amd64 6.1.0-YY-amd64
Module build for kernel 6.1.0-XX-amd64 was skipped since the
kernel headers for this kernel do not seem to be installed.
Building initial module for 6.1.0-YY-amd64

This is fine. The module is built for the kernel you’ll actually boot (the newest one). The skipped kernel is just an older fallback entry in GRUB. If you want to silence the skip — for example to keep the fallback kernel bootable with NVIDIA — install headers for that specific version:

sudo apt install linux-headers-6.1.0-XX-amd64   # optional; replace with the skipped version

Step 3 — Reboot and verify

sudo reboot

If the machine comes back up to a normal desktop (no black screen), the Intel-drives-the-display half is already working. Now confirm the driver swap and the offload behavior:

lsmod | grep -E 'nvidia|nouveau'    # want nvidia* loaded, nouveau ABSENT
nvidia-smi                          # want the GPU listed with its driver version
glxinfo | grep "OpenGL renderer"    # want Intel here (desktop on the iGPU = correct)

The desktop renderer reporting Intel is the goal, not a failure. Your everyday desktop should render on the iGPU for battery life. The NVIDIA GPU only comes into play when you explicitly offload to it (next step).

Now prove the NVIDIA GPU wakes on demand:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep "OpenGL renderer"

This one should report the NVIDIA T600. If it does, PRIME render offload is working end to end.

Step 4 — Using the GPU (offload invocation)

To run any application on the NVIDIA GPU, prefix it with the two offload environment variables:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia <application>

For example, to launch a game or a 3D app on the dGPU while everything else stays on Intel. For convenience you can wrap this in a small shell alias or a prime-run-style helper script.

Step 5 — Suspend/resume and power tuning

Debian’s NVIDIA package ships /etc/modprobe.d/nvidia-options.conf with several power-management options present but commented out. Two of them matter on a laptop. Open the file:

sudo nano /etc/modprobe.d/nvidia-options.conf

Uncomment these two lines (remove the leading #):

options nvidia-current NVreg_PreserveVideoMemoryAllocations=1
options nvidia-current NVreg_EnableS0ixPowerManagement=1

Rebuild the initramfs and reboot so the options take effect:

sudo update-initramfs -u
sudo reboot

After the reboot, test a suspend/resume cycle and confirm the display comes back cleanly:

systemctl suspend
# wake the machine, confirm the screen restores correctly

Optional — Fully power down the dGPU when idle

You may notice the NVIDIA GPU stays in a low but non-zero power state even when nothing is offloaded to it:

cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status   # may read "active"

To have the driver cut power to the GPU entirely (D3cold) when idle, add the aggressive dynamic power-management option as a separate, deliberate change:

echo 'options nvidia "NVreg_DynamicPowerManagement=0x02"' | sudo tee /etc/modprobe.d/nvidia-pm.conf
sudo update-initramfs -u
sudo reboot

After rebooting, re-check runtime_status (you want suspended) and re-test systemctl suspend. D3cold is the one setting most likely to interfere with clean suspend/resume or dGPU wake on some configurations. If anything misbehaves, simply remove the file (sudo rm /etc/modprobe.d/nvidia-pm.conf), rebuild the initramfs, and reboot to revert.

Change one power option at a time and re-test suspend after each. It’s the only reliable way to know which knob caused a regression.

Pitfalls — what not to do

Reference — working configuration summary

Quick verification checklist

# After the full setup, all of these should hold:
lsmod | grep nouveau        # (empty)  -> nouveau blacklisted
nvidia-smi                  # lists the T600 + driver version
glxinfo | grep renderer     # Intel    -> desktop on iGPU
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep renderer   # T600
systemctl suspend           # resumes cleanly

This guide was written by Claude, an AI assistant made by Anthropic, based on a hands-on troubleshooting session working through this exact setup step by step.

Hugo + PaperMod

The site is built with Hugo, a static site generator written in Go. Content is plain Markdown files with a bit of front matter; Hugo turns that into a folder of HTML at build time. No server-side rendering, no runtime dependencies, just files.

For the look and feel I’m using PaperMod, a clean, fast community theme, pulled in as a git submodule rather than forked. That keeps me on the upstream release train and out of the business of maintaining CSS.

The site has three sections: Blog (this), About, and Projects. Blog posts get dated permalinks (/blog/2026/my-post/), which keeps URLs stable even if I ever reorganize or retitle things.

Deploying without a new host

I already have web hosting, so standing up something new just to serve static files felt unnecessary. Instead, deployment is a GitHub Actions workflow that:

1. Checks out the repo (with the theme submodule)
2. Installs the pinned Hugo extended release
3. Runs hugo --gc --minify --cleanDestinationDir to build the site
4. Copies the resulting public/ directory to my host over scp, authenticated with an SSH key

Every push to main rebuilds and redeploys the site — no manual upload step, no FTP client. The SSH host, username, private key, and target directory all live as GitHub Actions repository secrets, never in the repo itself.

One thing that tripped me up: modern scp defaults to speaking the SFTP protocol under the hood, and on my host that SFTP subsystem resolves relative paths from a different root than an interactive SSH shell does. Uploads kept failing with “no such file or directory” against a path that very much existed. Forcing the legacy scp protocol (-O) fixed it — a good reminder that “it worked over SSH” and “it’ll work over scp” aren’t always the same claim.

What’s next

Mostly just writing more. The repo is set up so a new post is one command away:

hugo new blog/my-post-title.md

…and one git push away from being live.

More to come.

This is where your bio goes — who you are, what you do, and what this site is about.

Example Project

A short description of the project, what it does, and a link to it.