FreeBSD 15.1-BETA3 DRM/i915 Upgrade Runbook
Host: thinkpadt480s | Date: 2026-05-17 | Status: DRM resolved, Plasma Wayland session pending
…Host: thinkpadt480s | Date: 2026-05-17 | Status: DRM resolved, Plasma Wayland session pending
…After upgrading to FreeBSD 15.1-BETA3 and getting DRM 6.12 working see:freebsd-15.1-drm-i915-runbook.md, Plasma Wayland would not start through SDDM. Logging in via SDDM’s greeter bounced back to the login screen with no error output. wayland-session.log was empty. XFCE (X11) worked fine through SDDM.
Session activation failed in this configuration. ck-list-sessions showed:
$ ck-list-sessions | grep active
active = FALSE
When a session is not marked active, kwin_wayland cannot acquire DRM device access : /dev/dri/* access fails, libseat/seatd integration may not work, and the Wayland compositor exits immediately, often with no log output. This matches the symptom exactly.
Host: thinkpadt480s | Date: 2026-05-15 | Status: Deployed and running
battery-sleep.sh is a small cron script that suspends FreeBSD to RAM when the battery drops to a threshold (default 20%). It is a companion to the sysutils/battery-shutdown port — that script shuts down at critical levels (~5 minutes remaining); this one sleeps earlier so the battery is not drained while the machine sits unattended.
Host: thinkpadt480s | Date: 2026-05-10 | Status: Deployed and running
blight is a backlight idle ‘daemon’ I made to use on KDE Plasma/Wayland on FreeBSD 15 because I needed something to dim the screen. It blanks the screen after a configurable idle timeout, suspends on battery after extended idle, and restores brightness on any input activity : no D-Bus, no logind, no powerdevil, no device polling. It is a shell script wrapping swayidle, which speaks the org_kde_kwin_idle Wayland protocol directly to KWin.
This is a rewrite. The original was a Python daemon that polled input devices directly. That approach had fundamental problems on FreeBSD and was replaced entirely with a sh wrapper around swayidle.
On 2026-04-06 at approximately 09:38 EDT, the Kea DHCP service on pfSense (26.03-RELEASE) stopped serving leases on all interfaces. The root cause was a corruption of the <dhcpd> block in /cf/conf/config.xml, which caused pfSense to generate an empty Kea interfaces list. Service was restored by activating a previous ZFS boot environment.
| Time (EDT) | Event |
|---|---|
| 08:54 | config.xml drops ~15KB — <dhcpd> block wiped (config-1775480086.xml > config-1775480087.xml) |
| 08:54–09:37 | Multiple config saves at reduced size; pfSense regenerates Kea config with empty interfaces each time |
| 09:38 | Kea begins logging DHCPSRV_NO_SOCKETS_OPEN; DHCP stops serving leases |
| 09:38–09:41 | Kea restarts repeatedly, fails each time |
| ~09:45 | Operator detects outage; accesses box via WireGuard VPN |
| ~10:00 | Investigation begins |
| ~10:30 | Root cause identified: empty <dhcpd> in config.xml |
| ~10:45 | Config restore from backup attempted; Kea config generator continues producing empty interfaces |
| ~11:00 | ZFS boot environment rollback to default_20260405014509 initiated |
| ~11:10 | Service restored |
A pfSense package operation (pfBlockerNG or Suricata reload/apply) triggered a config write at 08:54 that silently cleared the entire <dhcpd> section from /cf/conf/config.xml. This is a pfSense 26.x bug: package-initiated config saves can clobber unrelated service configuration blocks.
This is the build-and-break log for bringing a previously unstable TrueNAS/FreeBSD box back to a usable state after months of ugly crash behavior under VM load.
The short version:
nvme2 / nda2) timing out and detaching under load(Mac Pro 2013 / Non-Secure Enclave Macs)
This guide applies only to pre-T2 Macs (e.g., Mac Pro Late 2013).
These machines:
This will remove the local iCloud association without deleting the Apple ID account itself.
On pre-T2 Macs:
Removing the local databases clears the association from macOS.
…Every good storage failure starts innocently.
Plug in a brand-new Samsung T7.
Select it in Time Machine.
Click “Use Disk.”
Allow macOS to format the drive automatically.
Let the backup run. It may even complete once — maybe even a few more times.
Then it fails with a generic error:
“An error occurred while preparing the backup.”
Time Machine consistently failed during the “Preparing backup” phase on macOS 26.3 (Tahoe).
…
Grafana overview dashboard for TrueNAS SCALE: CPU/load, memory + ARC, ZFS pool usage, SMART status, and network/disk activity at a glance.
This document is the exact build log for bringing up a production-grade Nextcloud instance inside a Bastille jail on TrashProBSD (FreeBSD 14.3-RELEASE) using: