Homelab on Margrop Blog

PhotoPrism Stuck for 5 Minutes on First Boot? A Postmortem on PHOTOPRISM_INIT=intel

Sat, 13 Jun 2026 08:30:00 +0800

TL;DR (The Short Version)

The PHOTOPRISM_INIT: "intel" line in PhotoPrism’s Plus Docker image is not just a flag to enable Intel hardware acceleration at runtime — it’s a one-shot system-level installer that runs apt-get dist-upgrade against archive.ubuntu.com and then installs 8 Intel/VA-API packages before the main process is allowed to start. On a fresh container this takes 5–10 minutes (sometimes more), during which nothing inside the container listens on port 2342.

Meanwhile: docker ps says Up, Portainer is green, ss -ltn on the host shows :2342 LISTEN — but your browser gets ERR_CONNECTION_RESET / Connection reset by peer. Because host-side docker-proxy accepts the connection and then tries to forward to a port inside the container that has no listener, the kernel sends back an RST.

Fix: just remove or empty that one line. If you already pass /dev/dri/renderD128 via devices:, the host’s drivers and userland libraries are perfectly usable from the container — there’s nothing to “install” in there.

Seamless Homelab Networking: Deploying Tailscale on Ubuntu 26.04 for Effortless Remote Access

Tue, 26 May 2026 14:00:00 +0800

The Short Version

Cross-carrier connectivity, lack of public IPv4 addresses, and multi-device connection management have always been the ultimate pain points for Homelab enthusiasts and enterprise sysadmins alike. This article provides a comprehensive, step-by-step guide on how to cleanly and securely install and configure the latest version of Tailscale on the newly released Ubuntu 26.04 (Resolute Raccoon) using the modern APT Keyring standards. Beyond a clean command-line install walkthrough, we delve into the architectural design of Tailscale, Subnet Router routing, and Exit Node proxying to establish a seamless, encrypted mesh network linking your home Synology NAS, Proxmox VE hypervisors, remote laptops, and mobile devices.

All setups and commands documented here have been rigorously tested on a clean Ubuntu 26.04 (Resolute Raccoon) environment. To prioritize safety and avoid leakage, all internal IP addresses, access tokens, routing tables, and server domains have been fully masked using generic placeholders.

Proxmox VE 9.2 Is Out: Not Just a New Kernel, but a Cluster That Can Start Balancing Itself

Sat, 23 May 2026 12:46:00 +0800

Short version

Proxmox VE 9.2 was officially released on May 21, 2026. On the surface it is a platform refresh: Debian 13.5 Trixie, Linux kernel 7.0, QEMU 11.0, LXC 7.0, ZFS 2.4, and updated Ceph options. The more interesting story is operational: dynamic load balancing through CRS, safer HA maintenance with arm/disarm, a much stronger SDN fabric story, web-based custom CPU model management, and many smaller fixes around guests, storage, security, and automation.

If you run a single-node homelab, Proxmox VE 9.2 may not feel dramatic on day one. If you operate a multi-node cluster with HA resources, Ceph, software-defined networking, custom CPU compatibility requirements, Windows secure boot, external automation, or strict maintenance windows, this release deserves a careful read.

This article summarizes the official Proxmox VE 9.2 release and adds an operator’s view: what changed, what problem each change addresses, what to test before upgrading, and when it is reasonable to wait. All hostnames, addresses, cluster names, accounts, and command outputs are placeholders. No private environment details are included.

Upgrading PVE 8 to 9 Without Brute Force: Let an Agent Drive It, or Follow This Manual Checklist

Tue, 12 May 2026 19:00:00 +0800

Short version

Upgrading Proxmox VE 8 to 9 is not just copying a few commands. It is a major system upgrade from Debian Bookworm to Trixie, from PVE 8.4 to PVE 9.x, with kernel, storage, networking, Ceph, and HA behavior in the blast radius. The fastest practical path is to let Codex, Claude, OpenClaw, HermesAgent, or a similar Agent handle checks, command sequencing, logging, and post-upgrade verification. The human operator still needs to approve repository changes, package removals, configuration prompts, reboot timing, and recovery decisions. If you prefer doing everything by hand, the second half of this article gives a concrete manual checklist.

This article is for two groups of operators. The first group already uses Agents over SSH and wants a scoped one-sentence task for upgrading PVE. The second group prefers typing every command manually and wants a clear, ordered procedure with the main risk points called out.

All hostnames, addresses, repositories, tokens, and accounts in this article are placeholders. Replace values such as <PVE_NODE>, <BACKUP_TARGET>, and <ADMIN_CONSOLE> with your own environment. Before touching a production host, read the official Proxmox documentation and verify that your backups are restorable.

Adding Proxmox VE local-lvm Usage and Link-Speed Monitoring to Uptime Kuma

Tue, 05 May 2026 17:20:00 +0800

Short version

Proxmox VE local-lvm is usually an LVM-thin pool, not a normal mounted directory, so df -h is not enough to catch it before it becomes full. Network link speed is another quiet failure mode: services may stay online while a NAS or router uplink falls back to 100 Mb/s and turns large file transfers into a crawl. A practical fix is to feed both checks into the Uptime Kuma you already use: expose a small HTTP health endpoint for local-lvm, and push link-speed status from the Proxmox host with an ethtool script.

This article walks through the design, the problems in a naive implementation, improved scripts, systemd units, Uptime Kuma configuration, verification steps, and safety notes. All addresses, tokens, host names, and environment-specific values are placeholders. Replace <PVE_HOST>, <KUMA_URL>, <PUSH_TOKEN>, and <INTERFACE> with values from your own environment.