If you've been following the Celeste build series, you know that running a self-hosted AI agent on a Raspberry Pi is one of the most rewarding — and occasionally maddening — things you can do as a developer. The last 72 hours have been a masterclass in "what can go wrong, will go wrong." But also: what gets fixed, gets faster. Here's the full play-by-play.

The Raspberry Pi Upgrade (That Nobody Planned)

The short version: the Pi needed to come up to speed. We'd been running on a configuration that was starting to show its age — tighter disk space, slower package management, and a slow external USB drive that turned out to be causing more grief than we realized. The decision was made to do a full OS upgrade (Bullseye → Bookworm) and move some key directories off the external drive. The upgrade process itself was textbook Debian — painfully slow but stable. With 1,478 packages to pull down and update, we were looking at 20–40 minutes of sitting on our hands while the progress bar crawled across the screen. The key lesson here: don't interrupt a dist-upgrade mid-stream. We didn't, and it paid off.

The Disk Space Trap

We ran out of disk space mid-session — one of those classic "oh no" moments where you realize the external drive that seemed like a great idea is now the bottleneck for everything. The fix was clearing the npm cache and relocating the global install directory. Once that resolved, performance improved noticeably across the board. The Pi stopped feeling sluggish. Celeste's responses got snappier. Lesson learned: keep your AI agent's core files on fast internal storage.

Building the LAMP Stack for PHP Dev Work

One of the new additions this week: a full LAMP stack on the Pi, set up specifically for PHP 5.3 → PHP 8 conversion work and WordPress theme/plugin testing. The goal is to use the Pi as a local dev environment — build and test locally, then FTP the finished product to client servers. The install is straightforward on Bookworm:

sudo apt update
sudo apt install apache2 php php-mysql php-curl php-gd \
  php-mbstring php-xml php-zip mariadb-server phpmyadmin \
  php-imagick php-intl -y

MariaDB is the drop-in MySQL replacement used on Pi/Debian — works identically for WordPress and most PHP applications. For the PHP version switching needed in 5.x → 8.x migration work, update-alternatives lets you flip between installed PHP versions per project.

Why This Matters for the Workflow

Here's the practical upside: Celeste now has a local WordPress environment to interact with. Long-term this means she'll be able to draft posts, test theme changes, and preview landing pages — all on the Pi — before anything touches a live server. Combined with WP-CLI and an FTP client like lftp, this creates a tight local-to-production pipeline that doesn't require touching a paid hosting environment for every iteration.

The OpenClaw Config Wars

Here's the part nobody warns you about loudly enough in the documentation: OpenClaw updates frequently, and it breaks configs without mercy. In the last 72 hours alone we went through three separate upgrades — and each one required config surgery. The specific error that brought everything down this time:

channels.discord.streaming: Invalid input
(allowed: true, false, "off", "partial", "block", "progress")

Sounds simple. Wasn't. The config had the streaming value set as a JSON object {"mode": "off"} rather than the plain string "off" that a newer version of OpenClaw expected. Then a subsequent manual edit accidentally set it to the string "false" (with quotes) instead of the boolean false. Each fix had to be verified by reading the actual file on disk — not trusting what was shown in the UI.

• Problem 1 Streaming value was an object, not a string "streaming": {"mode": "off"} → needed to be "streaming": "off"
• Problem 2 String "false" vs boolean false Edited to "streaming": "false" (string) — still invalid. Needed false with no quotes.
• Problem 3 Python fix wrote to wrong path Script used /root/ path but config lived at /home/admin/ — file never got updated.
• Resolution Direct Python fix to correct absolute path python3 script targeting /home/admin/.openclaw/openclaw.json, setting streaming to Python False (serializes as JSON boolean false).

The service was stuck in a restart loop — 82+ failed restarts before we got the right fix in. The key diagnostic command that saved us:

sudo journalctl -u openclaw -n 100 --no-pager

When to Just Nuke It and Start Fresh

There comes a point in any debugging session where the accumulated state of a broken install becomes harder to fix than a clean reinstall. We hit that point. The npm global directory on the external drive had corrupted symlinks, the ENOTEMPTY error was blocking normal uninstall, and even sudo rm -rf couldn't remove a nested ARM binary package. The process that eventually worked:

# Stop the service first
sudo systemctl stop openclaw

# Find what's holding the directory open
lsof +D /path/to/openclaw/node_modules

# Kill any lingering processes
sudo pkill -f openclaw

# Force remove the stuck directory
sudo rm -rf /media/admin/sethdisk1/npm-global/lib/node_modules/openclaw

# Fresh install
npm install -g openclaw

"The anticipation of watching npm install hundreds of packages one by one is genuinely its own kind of suspense. But a clean install after a corrupted one feels like rebooting your whole day."

After the fresh install completed, OpenClaw came back up cleanly. The gateway bound to the LAN interface, the OpenBoard GUI loaded, and Celeste was back online. The performance improvement from having the install on internal storage (vs. the slow external drive) was immediately noticeable.

Where Celeste Stands Now

After 72 hours of upgrades, debugging, and infrastructure work, here's the current state of the lab: Celeste is running on Kimi K2.5 (Moonshot AI) as the primary backend, with Claude Sonnet 4 and GPT-5 Nano as fallbacks. The Discord gateway is live on the private #sethbot channel. The LAMP stack is ready for PHP development work. And the systemd service brings everything back automatically after reboots. The multi-provider model config means if Kimi runs out of API credits or has an outage, Celeste automatically falls through to the next provider. No babysitting required.