My Home Lab Documentation

Documentation for my home lab CI/CD setup

View the Project on GitHub Auzlex/my-home-lab

← Back to Home

Maintenance Log

This page documents issues, problems, and maintenance activities that occur during the operation of the home lab. Each entry includes the date, problem description, diagnosis steps, resolution, and follow-up notes.

January 25, 2026 - Updated Pi-hole Gravity and Added Meta Quest Blocklists

Problem Description

Performed a Pi-hole gravity update and added DNS blocklists to prevent Meta Quest Pro devices from contacting Meta services, including firmware update and advertising endpoints. The Meta Quest Pro is discontinued, and updates are intentionally blocked at the DNS level.

Diagnosis Steps

  1. Ran a Pi-hole gravity update to refresh all blocklists: 
    pihole -g
  2. Added the Meta Quest firmware update blocklist: 
    https://raw.githubusercontent.com/ibrah3m/pihole-meta-quest-blocklist/main/hosts-firmware
  3. Added the Meta Quest ads blocklist: 
    https://raw.githubusercontent.com/ibrah3m/pihole-meta-quest-blocklist/main/hosts-ads
  4. Confirmed domains were blocked via Pi-hole query logs when the Meta Quest Pro attempted outbound connections.

Follow-up Notes

  • Monitor Pi-hole logs to ensure Meta-related domains remain blocked.
  • Review blocklists periodically for updates or changes.
  • Be aware that blocking firmware endpoints may affect certain online features or services.

January 21, 2026 - Enforced Pi-hole DNS on All Nodes via Device Configuration including IPv6

Problem Description

Ensured ENLIL, LORIC, AUREL, and Casper Raspberry Pi nodes are using the ENLIL Pi-hole as their DNS server directly on the devices rather than relying on the router settings.

Diagnosis Steps

  1. Checked current DNS settings on all nodes: 
    nmcli device show
  2. Applied Pi-hole DNS directly to each connection profile using nmcli: 
    sudo nmcli connection modify connection ipv4.dns "192.168.1.125" ipv4.ignore-auto-dns yes ipv6.ignore-aut-dns yes ipv4.dns "2a00:23c7:593:6501:ba27:ebff:fe0f:e3f2"
  3. Verified on each device to see Pi-hole as primary DNS: 
    nmcli connection show target_name
  4. Confirmed all nodes resolved domains correctly and queries appeared in Pi-hole logs.

Follow-up Notes

  • Monitor Pi-hole query logs to ensure all devices consistently use it for DNS resolution.
  • Document any new connection profiles that may appear to ensure they also point to Pi-hole.
  • Verify Docker containers respect the device DNS settings for consistency.

January 19, 2026 - Configured LORIC and AUREL to Use ENLIL Pi-hole DNS ipv4 only

Problem Description

Changed the DNS resolving on Raspberry Pi nodes to target the ENLIL Pi-hole hosted on 192.168.1.125.

Diagnosis Steps

  1. Verified current network connections: 
    nmcli connection show
  2. Updated LORIC’s Wi-Fi connection to use Pi-hole: 
    sudo nmcli connection modify BT-RJATFG ipv4.dns "192.168.1.125" ipv4.ignore-auto-dns yes && sudo nmcli connection up BT-RJATFG && nmcli connection show BT-RJATFG

  3. Noted that our home network is on BT, which prevents directly overriding DNS for all devices. Devices currently need to be manually pointed to the Pi-hole.

  4. Observed connection names:
    • LORIC: BT-RJATFG
    • AUREL: netplan-wlan0-BT-RJATFG (likely caused by LORIC losing Wi-Fi randomly; exact cause unknown)
  5. Checked Docker containers, which may ignore host DNS configuration: 
    docker run --rm alpine cat /etc/resolv.conf

This ensures that containers respect the Pi-hole DNS.

  1. Updated devices LORIC and AUREL to follow Pi-hole settings.

Follow-up Notes

  • Monitor DNS queries via Pi-hole to confirm proper resolution and fallback behavior.
  • Consider applying similar DNS configuration to Casper node next.
  • Watch for unexpected network drops that may cause new connection profiles like netplan-wlan0-BT-RJATFG.
  • Document Docker container DNS behavior for future reference.

January 18, 2026 - ENLIL Pi-hole Deployment and Initial Blocklist Tuning

Problem Description

Deployment of Pi-hole on ENLIL (Raspberry Pi 1 Model B) as a dedicated network DNS and filtering node.

Diagnosis Steps

Verified Pi-hole operation via web interface and query logs.

Findings:

  • Pi-hole was successfully serving DNS requests.
  • Traffic was being filtered as expected with no immediate false positives observed.

Resolution

  1. Installed and configured Pi-hole on ENLIL.

  2. Added blocklists sourced from Firebog

    • Selected two lists from each category:
      • Suspicious Lists
      • Advertising Lists
      • Tracking and Telemetry Lists
      • Malicious Lists

  3. Ran a manual Gravity update using the Pi-hole web interface.

  4. Added manual blocking for Facebook-related domains.

  5. Set upstream DNS provider to Cloudflare (temporary).

Follow-up Notes

  • Rule of thumb followed: fewer lists is better to reduce false positives.
  • Continue monitoring query logs for breakage or over-blocking.
  • Revisit upstream DNS choice later if needed.
  • Gradually tune blocklists instead of adding more.

January 17, 2026 - /etc/hosts File Resetting After Reboot

Problem Description

The /etc/hosts file was being reset after system reboots, losing custom DNS resolutions including 192.168.1.124 entries.

Diagnosis Steps

Investigated the cause of hosts file resetting:

  1. Checked cloud-init configuration: 
    cat /etc/cloud/cloud.cfg
  2. Examined hosts template file: 
    cat /etc/cloud/templates/hosts.debian.tmpl

Findings: Cloud-init was managing /etc/hosts and overwriting custom entries on each boot.

Resolution

Disabled cloud-init management of /etc/hosts and updated the template:

  1. Edited cloud-init configuration: 
    sudo nano /etc/cloud/cloud.cfg

    Set: manage_etc_hosts: false

  2. Updated hosts template to include DNS resolution: 
    sudo nano /etc/cloud/templates/hosts.debian.tmpl
  3. Rebooted system to verify changes persist: 
    sudo reboot

The /etc/hosts file now retains custom entries across reboots.

Follow-up Notes

  • Double-check that 192.168.1.124 actually resolves after a reboot.
  • Look at the other Pis to make sure they don’t have the same cloud-init issue.
  • Keep a note of this fix for future setups so it doesn’t catch you off guard.
  • Watch for any weird behavior from cloud-init in the coming weeks.

January 17, 2026 - LORIC WiFi Connection Issue & Runner Offline

Problem Description

LORIC (Raspberry Pi 3 B+ orchestration node) did not respond after a reboot. The device was unreachable over the network, and the Gitea runner service on it was offline.

Diagnosis Steps

  1. Connected Ethernet cable directly to LORIC to establish connectivity and investigate: 
    ip a
  2. Examined wireless interface status: 
    ifconfig wlan0

Findings:

  • The Raspberry Pi had forgotten the WiFi SSID and had no active wireless connection.
  • Even after Ethernet connectivity was restored, the Gitea runner service failed to start due to DNS resolution issues.

Resolution

  1. Reconfigured WiFi settings using Raspberry Pi configuration tool: 
    sudo raspi-config
    • Select System Options > Wireless LAN
    • Enter correct SSID and passphrase
    • Save and reboot
  2. Fixed local DNS resolution to allow the runner service to start: 
    sudo nano /etc/hosts

    Added entries for all relevant nodes.

  3. Restarted Gitea runner: 
    sudo systemctl restart gitea-runner
sudo systemctl status gitea-runner

LORIC reconnected to the network and the runner service resumed normal operation.

Follow-up Notes

  • Keep an eye on LORIC’s WiFi over the next few days to make sure it stays stable.
  • Make sure all Pi nodes have persistent DNS entries so the runner can always find what it needs.
  • For critical services, consider keeping a backup Ethernet connection ready.
  • Watch the runner logs for any future failures that might be network-related.