Skip to content

The machine — Dell OptiPlex 7050, hostname Plex, 192.168.5.15

A desktop pressed into service as a NAS: one chassis fan, four 3.5″ drives on an add-in SATA card, 40 GB RAM (DIMM1/2/4 8 GB Corsair, DIMM3 16 GB, since 2026-09-25), a 512 GB NVMe root, on a CyberPower UPS since 2026-11-02 (USB 0764:0501; firmware reports CP685AVRa, 390 W nominal; ~54 min at 15% load). NUT standalone: upsc cp1500@localhost, configs /etc/nut/ (pre-setup backup /etc/nut/backup-20261102-185259), script ~/maintenance/ups-2026-10/nut-setup.sh. Shuts down at low battery (10% / 300 s), then cuts UPS outlets so the box restarts on mains return (BIOS AC-recovery not verified). Pushes via /usr/local/sbin/ups-notify → ntfy. Ubuntu 24.04 with a GNOME desktop session still running (user services live under it).

Shape

  • OS: Ubuntu 24.04 LTS, kernel 7.0.0-31-generic (09-08). Boots: 09-01 19:53 → 09-05 15:55 (power cycle) → 09-08 06:35 (reboot).
  • Network: enp0s31f6 192.168.5.15/22. LAN names *.lan via Pi-hole DNS → NPM reverse proxy. SSH ssh://angel@192.168.5.15 (password auth off via sf / 99-hardening.conf; keys only). WireGuard via wg-easy. cockpit.lan:9090 is linked from homer; not verified here.
  • Memory: ~1.6 GB real use by containers; free shows ~300 MB because qbittorrent + page cache hold ~11 GB reclaimable. Swap 4 GB /swap.img; swappiness fixed by mf. Claude Code's background-Bash memory supervisor kills long jobs on this box because it reads free — run long things in the foreground or via cron.
  • Root disk: 468 GB, 196 GB used (containers' configs, precious/ 92 GB, ~/.claude, snaps). NVMe: 5 % used, 0 media errors, 54 of 73 power cycles unsafe → item 20.
  • Thermals: ambient ~32 °C at the board; parity rested 31–34 °C, data disks 38–42 °C, since item 10.
  • System services that matter: docker, cron, ssh, hd-idle, smartmontools, pmlogger/sysstat (metrics), wg-docker-watchdog.timer, rescue-watchdog.timer, snapraid-*.timer. User services (angel, lingering): claude-hub, claude-remote, codex-builder-tunnel, garmin-tunnel.
  • Snap: firefox, vlc, firmware-updater, gnome runtimes — desktop leftovers, not load-bearing.

Why this shape

It was the computer that was there. Every hardware item in the plan (14 fan, 19 second parity, 20 UPS) is a consequence of that.

Connected to

If you change this

  • BIOS AC Recovery is already on. The box boots by itself when power returns (owner, 2026-10-26).
  • Power off without sudo: polkit allows angel org.freedesktop.login1.power-off, so shutdown -h HH:MM works from an agent shell (pkcheck rc=0, 2026-10-26).
  • Power off / reboot: write a ~/disk-map-<date>.txt first (pattern in the 09-08 one); confirm no sync/rescue/precious job is running; after boot findmnt all five mounts, lsblk -dn -o NAME,SIZE,SERIAL, snapraid status before any sync; expect one rescue-watchdog alert.
  • Hits on a reboot: device letters (smartd.conf uses them) · Persistent=true timers fire missed runs at boot (sync, scrub, watchdog).
  • Does not hit: UUID mounts, by-id hd-idle, container configs.

Surfaces

Surface Role
Homepage (~/homepage, replaced Homer 2026-10-18; via NPM) link dashboard incl. Glances, Cockpit, Portainer
Claude Code from /home/angel this map

See

  • Source: ~/disk-map-20260908.txt (the pre-shutdown state note) · last -x reboot · ~/.local/bin/mf (memory explanation)

RAM upgrade inspection — 2026-09-22

Live read-only inventory reports OptiPlex 7050, board 0NW6H5, SMBIOS chassis type 3 (Desktop), and 16 GiB installed RAM (Linux MemTotal approximately 15.48 GiB usable). About 3.1 GiB was available before the Android rehearsal; all 4 GiB swap was allocated. Allocation alone does not prove active swapping.

User-supplied sudo dmidecode --type 17 output on 2026-09-22 confirms: - DIMM1, DIMM2 and DIMM4: empty. - DIMM3: one 16 GB DDR4 unbuffered desktop DIMM, rank 1, 64-bit total/data width. - Module reported speed 2667 MT/s; configured speed 2400 MT/s at 1.2 V. - Part number is blank; exact module model is unknown. No serial retained here.

This confirms the four-slot desktop memory configuration, not Micro SODIMMs. The proposed 32 GB upgrade can retain the current module and add one compatible 16 GB non-ECC DDR4 UDIMM with JEDEC 2400 MT/s support. Exact product and paired slot placement still require compatibility/manual verification before purchase and installation. No purchase or physical change authorized by this inventory.

Dell's 7050 technical specifications list four DDR4 UDIMM slots and 64 GB maximum for Tower/SFF, versus two DDR4 SODIMM slots and 32 GB maximum for Micro. DDR4-2400 operates at 2133 MHz with 6th-generation processors. Confirm exact module compatibility and paired slot placement before selecting parts. Source support for the limits is Dell, not marketplace compatibility claims.

RAM upgrade — modules in hand, 2026-09-25

Angel has a Corsair Vengeance LPX CMK16GX4M2B3200C16 kit on the shelf: 2 × 8 GB DDR4-3200 CL16-18-18-36, 1.35 V XMP, non-ECC UDIMM. That reaches the same 32 GB as the "add one 16 GB module" plan above, at no cost and with one advantage — it fills two slots instead of one, so the two channels can hold 16 GB each and the box leaves single-channel operation, which is what a lone DIMM3 module means today.

Now After
Installed 1 × 16 GB (DIMM3) 1 × 16 GB + 2 × 8 GB
Total 16 GB 32 GB
Channels single dual (16 GB per channel)
Clock 2400 MT/s 2400 MT/s — unchanged

The 3200 rating is irrelevant here and that is fine. Kaby Lake's controller tops out at DDR4-2400, and Dell's BIOS exposes no XMP, so the kit falls back to its JEDEC profile at 2400 MT/s / 1.2 V — precisely what the existing 2667-rated module already does (Configured Memory Speed: 2400 MT/s). Mixed capacities and mixed brands are supported; all modules settle at the slowest common timing, which is the same timing either way.

Placement: DIMM2 and DIMM4, leaving the 16 GB in DIMM3. That balances the channels if the pairing is (1,3)/(2,4), the usual Dell four-slot layout. Board silkscreen wins over this note; the gain is a couple of percent and is not worth a second teardown to chase.

Why it is now worth doing rather than merely nice. /proc/pressure/memory still reads 0.00 — nothing is stalling — but swap is at 4.4 MiB free of 4 GiB, 99.9 % consumed. There is no reserve. Pressure stays at zero right up until it does not, and with swap full the kernel's only remaining move is the OOM killer, which takes whichever container is largest at that moment rather than whichever matters least. The upgrade buys back the margin, not speed.

This settles the migrate-or-upgrade question recorded in embeddedera-infrastructure-split: add the RAM, do not buy a machine. A second box remains arguable on maintenance-independence grounds — keeping the shop off the same host as the media stack — but no longer on capacity grounds.

Update MemTotal and the shape line above once the sticks are in.

RAM upgrade — installed, 2026-09-25

Linux sees 40 GiB (MemTotal 40931348 kB), not the planned 32 GB, so the installed set differs from the table above. Boots at 20:07/20:09/20:13 saw 32/24/32 GiB and ended without a shutdown sequence (modules being reseated); the 20:17 boot is the settled one. No EDAC/MCE errors. dmidecode -t 17: DIMM1 8 GB, DIMM2 8 GB, DIMM4 8 GB (all Corsair CMK16GX4M2B3200C16), DIMM3 16 GB (no part number). If channels pair (1,3)/(2,4): 24 GB + 16 GB, so Intel flex mode, 32 GB dual-channel and 8 GB single-channel. Accepted, no action. Play emulator profile boot_and_idle_pass, boot 30 s, host available 28.5 GiB. Swap 0 B used after boot.

Network incident — 2026-11-03

Read-only investigation at ~17:25 EST; no network/service configuration changed. Last boot was 2026-11-02 18:59 (boot ID 402f626c0e244bd99f5e17f028233c2e, kernel 7.0.0-42-generic). Previous evening shutdown was explicitly labelled “UPS install: clean power-off”; later reboots completed. No reboot, suspend, Ethernet carrier loss, or NUT shutdown recorded during today's outage.

  • ~10:36: outgoing remote-control/Nord service TCP connections started timing out; NetworkManager downgraded internet connectivity at 10:39:37. Physical Ethernet and DHCP remained up. Pi-hole still received LAN queries and logged successful upstream replies through 12:55:30. Original cause remains unknown; available evidence cannot distinguish upstream/router trouble from host traffic-path trouble. Host firewall is observe-only; Nord host VPN is now disconnected with firewall, routing, kill switch and auto-connect disabled.
  • 12:55:30: GNOME Shell (PID 2138, uid 1000) requested Ethernet disconnect; DHCP/default route was removed. At 12:55:49 NetworkManager assumed an externally configured connection named enp0s31f6, UUID 076194a8-f112-423e-9bb2-330d416eb09b. Subsequent logs report network unreachable until recovery. Owner reports enabling router DNS to restore household access, then selecting another wired connection on Plex to restore its internet. Treat UI changes as recovery attempts, not proof of the initial cause.
  • 17:16:15: GNOME Shell activated the saved netplan-enp0s31f6 profile (d4735e4b-9bfa-3052-b1c4-ef3302803c9a); DHCP restored 192.168.5.15/22 and default gateway 192.168.4.1. Profile has autoconnect=yes and ipv4.method=auto.

Verified afterwards: router ping 2/2; direct Pi-hole UDP/TCP DNS NOERROR; Cloudflare 1.1.1.1/1.0.0.1 DNS replies; external HTTPS 200; no failed system units; Pi-hole up since yesterday 18:59 with restart policy unless-stopped; UPS OL/100% battery. Pi-hole container health checks only local pi.hole, so healthy does not establish upstream reachability. Router DHCP currently advertises public DNS 8.8.8.8 and 4.2.2.1 to Plex; no router settings inspected or changed by this investigation. Household resilience requires DNS independent of this host (public DNS or another physical resolver); two resolvers on Plex would share the same host/network failure.

Evidence: journalctl --list-boots, boot 0 NetworkManager/nordvpnd/kernel/ nut-monitor journals; docker inspect pihole; Pi-hole /var/log/pihole/pihole.log; nmcli connection show, ip route, /etc/hostfw.nft, direct dig/curl/ping.

Deeper investigation — 2026-11-03 ~17:37 EST

  • APT primary logs confirm a large owner-invoked apt upgrade yesterday 18:35–18:41, including kernel 7.0.0-38 → -42, NetworkManager 1.46.0-1ubuntu2.4 → 1ubuntu2.8, Netplan 1.1.2-2~ubuntu24.04.2 → 1.1.2-8ubuntu1~24.04.3, Docker 29.0.3 → 29.9.2, NordVPN 4.2.3 → 6.0.2. Today before the failure: unattended upgrades only removed unused -34 kernel packages at 06:56–06:57; apt-daily refreshed metadata 09:48 without installing packages. Snap's 06:24 check found no updates. ChatGPT installation 17:18 was after network recovery. No package installation coincides with failure.
  • Kuma SQLite read-only query establishes external HTTPS 200 at 10:35:34, first timed-out poll timestamp 10:36:34, declared down 10:40:10, recovered 17:16:41. Other external TCP clients also timed out around 10:36.
  • Sysstat sample 10:30:01–10:40:01: physical enp0s31f6 TX 10,277.93 KiB/s (~84.2 Mbps, ~6.3 GB transmitted in 600 s). Host veth1f7ef89 RX 10,198.98 KiB/s accounts for almost all that transmission. Its bridge FDB maps peer MAC 12:6d:93:c8:2e:82 to Gluetun (172.18.0.24); Gluetun has run continuously since yesterday 18:59. qBittorrent shares that container's network namespace (verified inspect). This establishes the traffic source as the torrent/VPN namespace, not a host backup or LAN file copy.
  • Upload surge is the strongest temporal lead, not a proven root cause. Physical TX fell to 39 KiB/s over 10:40–10:50, yet outgoing HTTPS remained broken. A brief congestion episode alone does not explain persistent failure. No destination packet capture, WAN capacity, router NAT/security events, or process-level traffic history is available. Requested owner's eero evidence and subscribed upload speed. No bandwidth or peer limits changed.
  • NIC error rates were zero; CPU ~60–70% idle, RAM ~28 GB available. No conntrack-full, OOM, driver reset, or carrier-loss journal evidence at onset. No sudo calls 09:00–13:00. Host firewall file remains observe-only; no hostfw reload since boot. Nord logs show no VPN connect/settings change at onset, only lost service connectivity. These checks reduce possibilities; they do not rule out every transient kernel/router or firewall condition.

  • Independent bounded evidence review ran on subscription Claude Sonnet 5.5 (claude-sonnet-5-5), one turn, all built-in tools and MCP disabled. Primary reproduced interface attribution and timeline independently. PCP historical collection stopped Oct26; sysstat retained only ten-minute network samples. Current DNS and external HTTPS retested successfully; no service/network settings modified during investigation.

  • 2026-11-03 prevention follow-up: owner approved and applied 1 MiB/s qBittorrent upload cap in both normal/alternate modes; UDP/overhead included. Live API readback verified, share/time limits still off; only qBittorrent briefly restarted. DNS/HTTPS checked healthy. Details/rollback in media-stack card.