Thermal Runaway Caused by PT3 Recording Server Fan Failure and Emergency Evacuation of Key Containers
I have been operating an ASRock Beebox equipped with a PT3 tuner for many years as both a recording server and a host for various services. However, due to age-related wear and tear, the cooling fan has begun producing a loud, harsh noise.
Introduction to the Mini PC Recording Server Built with ASRock Beebox + PT3
Up until now, I tried to extend its lifespan by implementing a fan control script to keep the rotation speed down to the bare minimum.
However, the fan has finally stopped spinning altogether. Because the heat inside the compact chassis could no longer be expelled, the CPU temperature spiked during high loads or recording processes. This led to frequent system freezes and forced reboots caused by kernel panics triggered by thermal runaway.
Upon dismantling the unit to check the fan model number, I found it was “BSB05505HP-SM (DC05V 0.40A)". I ordered a compatible replacement fan, but it will take a few days to arrive.
https://amzn.to/4gQpihFSeparating Hardware-Dependent Functions and Evacuating to an Idle Machine
If I were to keep running the Beebox as-is until the replacement fan arrives, it could lead to permanent thermal damage to the motherboard and the PT3 itself. Therefore, I decided to review all running services and separate functions tied to physical devices from other general-purpose services.
Since the PT3 recording function is directly tied to the hardware, it will remain on the Beebox side, maintaining an operating state that keeps heat generation to an absolute minimum. On the other hand, I made the decision to urgently evacuate critical container groups directly tied to daily operations and data synchronization—such as the web server, n8n, DAViCal, and Gitea—to alternative hardware.
For the evacuation target, I repurposed a Surface Pro 5, which had previously been set up with Harvester but lost its use case due to a lack of resources.
I reinitialized the Surface Pro 5, installed Ubuntu 26.04, and redeployed it as a lightweight container host.
Challenges in Reconnecting Cloud HA VPNs and Redesigning the Network
This migration involved more than just copying containers; there were several infrastructure design challenges to address.
First was the risk of shutting down the home LAN infrastructure. Stopping dnsmasq (DNS/DHCP), which was running on the Beebox, would have caused all devices on the home LAN to lose communication, so a safe disconnection procedure was required.
Second was rebuilding the WireGuard VPN topology. The setup adopts a topology where an HA configuration on Oracle Cloud Infrastructure (OCI)—consisting of MAIN and SUB servers—independently connects to the Beebox and Surface on the premises. Because independent VPN connections had to be established from each cloud site to each local machine, I needed to accurately generate and deploy a total of four keys (two pre-shared keys, plus public and private keys).
Third was migrating the environment from Docker to Podman (podman-compose). Since it would run on the same LAN as the Beebox, I needed to rebuild the network settings while avoiding IP address overlaps defined in the existing docker-compose.yml.
Service Evacuation and Migration to the Podman Environment
Stopping dnsmasq and Migrating to the Wi-Fi Router’s DHCP Function
To prevent the entire home LAN from being affected if the Beebox crashed, I stopped dnsmasq on the Beebox and reverted the processing to the Wi-Fi router’s standard DHCP function. This maintained home network communications even during server maintenance.
Key Generation and VPN Activation Using a WireGuard Container
To generate WireGuard key pairs and shared keys without polluting the host environment, I temporarily spun up a WireGuard container with a local mount and used the tools inside the container to batch-generate the keys.
# Generate keys inside a temporary container and output them to the local directory podman run --rm -v $(pwd)/wireguard_keys:/keys:Z docker.io/linuxserver/wireguard sh -c "wg genkey > /keys/privatekey && wg pubkey < /keys/privatekey > /keys/publickey && wg genpsk > /keys/presharedkey_main && wg genpsk > /keys/presharedkey_sub"
Using the generated keys, I created the configuration file on the Surface Pro 5 side and established independent tunnels to OCI-MAIN and OCI-SUB.
[Interface] PrivateKey = [Surface Private Key] Address = 10.x.x.x/24 # Settings for OCI-MAIN [Peer] PublicKey = [OCI-MAIN Public Key] PresharedKey = [presharedkey_main] Endpoint = [OCI-MAIN IP]:51820 AllowedIPs = 10.x.y.0/24 PersistentKeepalive = 25 # Settings for OCI-SUB [Peer] PublicKey = [OCI-SUB Public Key] PresharedKey = [presharedkey_sub] Endpoint = [OCI-SUB IP]:51820 AllowedIPs = 10.x.z.0/24 PersistentKeepalive = 25
Synchronizing Configurations and Volume Data via rsync
I synchronized the target service container configurations and persistent volumes from the Beebox to the Surface Pro 5 using rsync.
# Transfer configuration files and persistent volumes rsync -avz -e ssh /opt/services/ root@[Surface IP]:/opt/services/
Starting Containers with podman-compose
On the Surface side, I ran Podman as the root user. Operating with root privileges avoided permission errors caused by binding privileged ports or file permissions, thereby speeding up the process.
I updated the IP definitions within each service’s docker-compose.yml to avoid overlapping with the Beebox’s IP, and launched everything at once using podman-compose.
# Start containers in each service directory cd /opt/services/web-stack podman-compose up -d
Minimizing Server Load and Achieving Stable Operation
As a result of evacuating the primary containers (Web, n8n, DAViCal, Gitea) to the Surface Pro 5, the CPU load on the Beebox dropped to an absolute minimum. Even with the fan stopped, kernel panics caused by thermal runaway completely ceased.
Furthermore, communication with the HA configuration servers on OCI was maintained normally via the new WireGuard tunnels, and externally integrated services recovered with minimal downtime. By utilizing the idle Surface Pro 5, I successfully established an environment that safely balances recording standby and service provisioning until the replacement fan arrives from AliExpress.
Meanwhile, the Beebox unit itself continues to run on a legacy, antique-like environment of CentOS 7. Along with hardware recovery via this fan replacement work, I am also planning to upgrade the OS environment to the latest Ubuntu 26.04.
https://amzn.to/3UUoXBXConclusion
I urgently evacuated key container groups from the PT3 recording machine—which was suffering from thermal runaway due to a stopped fan—to an idle Surface Pro 5. To preserve the home LAN, I reverted dnsmasq back to the router and rebuilt the WireGuard tunnels to OCI using keys generated in a temporary container. By migrating Web, n8n, DAViCal, and Gitea using podman-compose under root privileges while avoiding IP collisions, the Beebox’s load decreased and kernel panics were resolved, successfully establishing a stable operational setup until the replacement fan arrives.