# Comprehensive Engineering Report: Transforming a Consumer Laptop into a Resilient Mobile VPS & Hybrid Homelab **Author:** Rudransh Shekhar (KaptaanLM Research Labs / mySphere) **System Target:** Acer Aspire A515-52G **Date:** November 2026 **Architecture Classification:** Low-Power Edge Server / Dual-Boot Hybrid Mobile VPS **Repository / Host Reference:** `kaptaan45-Aspire-A515-52G` (Ubuntu 24.04 LTS / Windows 11 Dual-Boot) --- ## 1. Executive Summary & Project Objective The objective of this systems engineering initiative was to repurpose an **Acer Aspire A515-52G** consumer laptop into an always-on, power-efficient, highly resilient **"Mobile VPS" and Edge Server**, capable of running production container stacks, network routing, edge monitoring, and developer services with zero hosting costs. ### The Problem Statement: Commercial cloud VPS providers and free tiers (e.g., Oracle Cloud Free Tier 1 vCPU / 1 GB RAM, AWS EC2 micro instances) introduce severe memory, compute, and I/O bottlenecks. They cannot comfortably host multi-service containerized platforms—such as video streaming (`myCam`), distributed microservices (`myDomain`, `myCloud`), and AI experiments—without incurring steep monthly bills or sudden termination risks. ### Why a Consumer Laptop is an Ideal Edge VPS: 1. **Integrated Hardware UPS (Uninterruptible Power Supply)**: The built-in 48 Wh Li-ion battery shields the server from power cuts, brownouts, and voltage fluctuations, keeping services online through grid outages without costly dedicated UPS hardware. 2. **Thermal & Energy Efficiency**: The Intel Core i5-8265U Whiskey Lake processor features a low 15W TDP, pulling under 3W when idling in headless mode. 3. **Hybrid Storage Tiering**: Dual-drive architecture enables high-speed NVMe SSD storage for low-latency kernel execution and Docker container layers, paired with a 1 TB secondary SATA HDD for mass persistent media, databases, and logs. 4. **Dual-Role Flexibility (Hybrid Server/Workstation)**: The system can function as an unattended headless server 99% of the time, while retaining the ability to boot into a full graphical desktop environment or Windows 11 on demand. --- ## 2. Hardware, Firmware & Operating System Baseline | Component | Specification | VPS Role & Engineering Implementation | | :--- | :--- | :--- | | **Processor (CPU)** | Intel Core i5-8265U (4C/8T, 1.60 GHz base, 3.90 GHz boost) | Host compute; dynamic governor scaling; headless idle at <2% CPU | | **Memory (RAM)** | 12 GB DDR4 (1x 8 GB + 1x 4 GB, ~10.5 GB net usable) | Dynamic container memory allocations; zero swap memory penalty | | **Storage 1 (NVMe SSD)** | SPCC M.2 PCIe NVMe SSD (256 GB) | Dual-boot host: Windows 11 C: + Ubuntu 24.04 LTS Root (`/dev/nvme0n1p6`) | | **Storage 2 (SATA HDD)** | Western Digital 1 TB (WD10SPZX-21Z10T0, 5400 RPM) | Heavy persistent data, Docker volumes, databases (`/media/kaptaan45/Data`) | | **Graphics (dGPU)** | NVIDIA GeForce MX130 (2 GB GDDR5, GM108) | Dedicated CUDA / NVDEC hardware acceleration for video transcoding | | **Integrated GPU (iGPU)**| Intel UHD Graphics 620 | Primary display controller; powers down completely when lid is closed | | **Networking** | Intel Wireless-AC 9560 (CNVi) + Realtek RTL8111 GbE | Redundant dual-mesh network with dynamic priority metric routing | | **Power / Battery** | LG 48 Wh Li-ion (PABAS0241231) + 65W AC Adapter | Integrated hardware UPS; automatic DC passthrough at 100% | | **Firmware / BIOS** | Insyde BIOS V1.14 (UEFI Mode, Secure Boot Enabled) | Secure boot enforcement; ACPI power & thermal telemetry | | **Operating System** | Ubuntu 24.04 LTS (Noble Numbat), Linux Kernel 7.0.0-42 | Long Term Support stability; headless `multi-user.target` default | --- ## 3. Initial Architecture State & Obstacles Discovered Before engineering interventions began, a thorough diagnostic audit uncovered five critical system blockers: ``` INITIAL DISK LAYOUT (SPCC 256GB NVMe): ┌────────────────────┬──────────────────────────────────────┬─────────────┐ │ Windows 11 (~190G) │ Ubuntu Root Partition 5 (30.0 GB) │ EFI / Misc │ │ Healthy NTFS │ [████████████████████████████] 99% │ │ │ │ ONLY 430 MB FREE SPACE REMAINING! │ │ └────────────────────┴──────────────────────────────────────┴─────────────┘ ``` 1. **Catastrophic 99% Root Space Exhaustion**: - Ubuntu root (`/dev/nvme0n1p5`) was restricted to 30 GB and had only **430 MB of free disk space**. - An active 4.0 GB swap file (`/swap.img`) consumed over 13% of the entire OS partition. - Residual Snap packages, multiple unused Linux kernels (`6.8.0-45`, `6.14.0-29`), and obsolete desktop applications left the system on the verge of read-only filesystem lockup. 2. **The Windows Dynamic Disk (LDM) Lock on 1 TB HDD**: - The secondary 1 TB HDD was partitioned under Windows as a **Dynamic Disk (Logical Disk Manager - LDM)** on partition `/dev/sda4`. - Linux cannot natively mount LDM volumes through standard mount commands or fstab entries because LDM partitions lack standard superblock headers, resulting in `unknown filesystem type 'ldm'` errors. 3. **GPU Memory Suspend Panic on AC Power Disconnect**: - Disconnecting the AC power cable triggered GNOME's automatic power saving profile, which attempted to put the machine into `systemd-suspend`. - The proprietary NVIDIA kernel driver (`nvidia.ko`) failed to suspend video memory (`nv_pmops_suspend returns -5`), causing an unrecoverable kernel hang, freezing all network interfaces, and crashing the machine. 4. **The GRUB "Recordfail" Headless Trap**: - An unclean reboot or kernel crash sets the GRUB bootloader flag `recordfail=1`. - In standard configurations, GRUB ignores `GRUB_TIMEOUT=0` once `recordfail` is set, halting execution indefinitely at the GRUB menu until an Enter key is pressed physically—rendering unattended headless reboots impossible. 5. **Docker Filesystem Incompatibility on NTFS (Overlay2 Driver)**: - Attempting to store Docker's base directory (`/var/lib/docker`) directly onto the 1 TB NTFS partition fails because Docker’s `overlay2` storage driver requires POSIX file attributes, hard links, and whiteout device files (`d_type` support) that NTFS does not support. --- ## 4. End-to-End Implementation Log ### Phase 1: Storage Reclamation & Windows LDM Mounting #### 1. Immediate Disk Decompression: - Purged stale APT archives: `sudo apt-get clean && sudo apt-get autoclean`. - Reduced snap version retention to save disk space: `sudo snap set system refresh.retain=2`. - Removed bloated desktop applications not needed on a server: - Purged Nextcloud snap and VS Code/Antigravity desktop binaries. - Purged Google Chrome, Mozilla Thunderbird, and the LibreOffice suite. - Purged unneeded 32-bit compatibility packages (`i386`). - Purged superseded Linux kernels (`6.8.0-45-generic`, `6.14.0-29-generic`), freeing over 1.2 GB of boot/module space. - Decommissioned the 4.0 GB swapfile (`swapoff /swap.img && rm -f /swap.img`): - With 12 GB of physical RAM on a lightweight server, swapping to SSD was causing unnecessary flash write wear and wasting 13% of root capacity. #### 2. Persistent Mounting of Windows Dynamic Disk (LDM): - Installed `ldmtool` to parse the proprietary Windows Logical Disk Manager volume table on `/dev/sda4`. - Scanned and mapped the dynamic volume: ```bash sudo ldmtool create all # Output: Created volume /dev/mapper/ldm_vol_LAPTOP-0I7M8A97-Dg0_Volume1 ``` - Created persistent mount point `/media/kaptaan45/Data` formatted with NTFS. - Engineered a custom systemd service [`/etc/systemd/system/ldmtool.service`](file:///etc/systemd/system/ldmtool.service) to automatically map the volume during early boot before filesystem targets mount: ```ini [Unit] Description=Windows LDM Volume Mapper DefaultDependencies=no Before=local-fs.target [Service] Type=oneshot ExecStart=/usr/bin/ldmtool create all RemainAfterExit=yes [Install] WantedBy=local-fs.target ``` - Appended robust mount entry in `/etc/fstab` using `ntfs3` with user permissions: ``` /dev/mapper/ldm_vol_LAPTOP-0I7M8A97-Dg0_Volume1 /media/kaptaan45/Data ntfs3 nofail,uid=1000,gid=1000,iocharset=utf8 0 0 ``` - Symlinked `/media/kaptaan45/Data` to `~/Data` for immediate terminal accessibility, exposing **773 GB of free storage**. --- ### Phase 2: Clamshell Server Operation & Battery Safety #### 1. Clamshell Configuration (Lid-Closed Server Mode): - Configured [`/etc/systemd/logind.conf.d/99-server-lid.conf`](file:///etc/systemd/logind.conf.d/99-server-lid.conf): ```ini [Login] HandleLidSwitch=ignore HandleLidSwitchExternalPower=ignore HandleLidSwitchDocked=ignore LidSwitchIgnoreInhibited=no ``` - Closed lid state turns off the LCD backlight and eDP-1 display panel completely, reducing idle power draw by ~1.5W while keeping CPU, networking, and Docker containers fully active. #### 2. Suspend & Sleep Immunization: - To permanently prevent the NVIDIA driver suspend crash (`nv_pmops_suspend -5`), all sleep and hibernation targets were permanently masked in systemd: ```bash sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target ``` #### 3. Graceful Battery Failsafe (Virtual UPS): - Configured UPower daemon in [`/etc/UPower/UPower.conf`](file:///etc/UPower/UPower.conf) to manage power cuts gracefully: ```ini PercentageLow=25 PercentageCritical=12 PercentageAction=8 CriticalPowerAction=PowerOff ``` - **Operational Cycle**: 1. **Grid Power OK**: Laptop runs on 65W AC adapter. 2. **Power Outage**: Laptop battery engages instantly with zero microsecond transfer delay (beating enterprise UPS transfer times). 3. **Discharge**: The 48 Wh battery powers the headless server for 2.5 to 3.5 hours. 4. **Emergency Shutdown**: If power is not restored and battery reaches **8%**, UPower triggers an orderly `systemctl poweroff`, flushing all database buffers and preventing filesystem corruption. #### 4. Battery Longevity & Hardware DC Passthrough Analysis: - User evaluated software battery capping (e.g., 80% charge threshold). - Tested Acer Care Center and Acer Quick Access under Windows 11; confirmed that the Acer Aspire A515-52G Insyde BIOS V1.14 (2019) lacks ACPI register hooks for software charge thresholds. - Investigated Linux kernel Embedded Controller write interface (`ec_sys`). Confirmed that UEFI Secure Boot is active (`mokutil --sb-state: SecureBoot enabled`), which enforces Linux Kernel Lockdown mode and strictly forbids arbitrary EC register writes. - Analyzed real-time hardware telemetry via ACPI `/sys/class/power_supply/BAT1/uevent`: - `POWER_SUPPLY_STATUS=Full` - `POWER_SUPPLY_CURRENT_NOW=0` - **Engineering Conclusion**: The laptop's embedded charging controller hardware automatically isolates the battery cells once 100% capacity is reached and routes incoming DC power directly to the motherboard rails. Because charging current is 0 mA, the battery is not cycled while plugged in. Keeping idle temperatures cool (38°C in headless mode) eliminates thermal battery degradation. --- ### Phase 3: Resilient Networking & Private Mesh #### 1. Intel CNVi Wi-Fi Power-Save Neutralization: - Standard Linux desktop distributions place wireless cards into periodic micro-sleep (802.11 PS-Poll), introducing 100–300 ms latency jitter and packet dropouts during server ingress. - Fixed via [`/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf`](file:///etc/NetworkManager/conf.d/default-wifi-powersave-on.conf): ```ini [connection] wifi.powersave = 2 ``` - `wifi.powersave = 2` strictly disables Wi-Fi power saving, guaranteeing sub-2 ms local latency. #### 2. Dynamic Redundant Ingress (Ethernet Priority Failover): - Configured NetworkManager connection metrics: - Gigabit Ethernet (Wired): `metric 100` (highest priority) - Intel CNVi Wi-Fi: `metric 600` (backup) - If an RJ45 Ethernet cable is plugged in, routing tables immediately switch all traffic to Gigabit wire without dropping existing TCP sockets or tunnels. #### 3. Kernel Packet Routing & SSH: - Enabled IPv4 packet forwarding in [`/etc/sysctl.d/99-ip-forward.conf`](file:///etc/sysctl.d/99-ip-forward.conf): ```ini net.ipv4.ip_forward = 1 ``` - Configured `openssh-server` on port 22. - Deployed Tailscale WireGuard mesh with MagicDNS and Tailscale SSH: ```bash sudo tailscale up --ssh --operator=kaptaan45 ``` - Node assigned private Tailnet IP: **`100.85.248.103`**, accessible securely from anywhere in the world without port forwarding or exposing ports to public scanners. --- ### Phase 4: Containerization, Ingress & Reverse Proxy Architecture ``` INCOMING TRAFFIC FLOW │ ┌────────────────────────────┴───────────────────────────┐ ▼ ▼ Cloudflare Anycast Network Tailscale WireGuard Mesh (Public: *.webdomain.live) (Private: 100.85.248.103) │ │ ▼ │ cloudflared Systemd Daemon │ (QUIC / Argo Tunnel) │ │ │ └────────────────────────────┬───────────────────────────┘ ▼ Caddy 2 Reverse Proxy (network_mode: host, TLS 443) │ ┌──────────────────────┼──────────────────────┐ ▼ ▼ ▼ Dockge Engine Glances Monitor Uptime Kuma Port 5001 Port 61208 Port 3001 │ │ │ └──────────────────────┴──────────────────────┘ │ Docker Storage Engine: Native NVMe SSD (/dev/nvme0n1p6) │ Persistent Stacks & Volumes: Secondary 1TB SATA HDD ``` #### 1. Docker Engine & Compose Deployment: - Installed official Docker Engine (`docker-ce` v29.9.3) and Compose plugin (v5.7.0). - Added user `kaptaan45` to the `docker` group for passwordless rootless CLI operations. #### 2. Core Service Stacks: - **Dockge (`:5001`)**: Sleek, lightweight, reactive web UI for managing Docker Compose stacks, environment files, and container lifecycles. - **Glances (`:61208`)**: Real-time curses/web telemetry monitor tracking CPU per-core usage, RAM, NVMe/HDD I/O, network bandwidth, and GPU power state. - **Uptime Kuma (`:3001`)**: Internal monitoring dashboard continuously checking HTTP status, ping, and DNS resolution, with built-in alerting hooks. #### 3. Caddy Reverse Proxy & Performance Tuning: - Deployed Caddy 2 container in `network_mode: host` to eliminate Docker bridge network double-NAT overhead. - Configured internal TLS termination on port 443 using `tls internal` and `local_certs` to handle strict HTTPS traffic. - Configured HTTP stream compression: ```caddyfile encode gzip zstd ``` - Bound all reverse proxy upstreams explicitly to IPv4 loopback (`127.0.0.1`) to eliminate IPv6 lookup fallback timeouts. #### 4. Cloudflare Argo Tunnel (`cloudflared`): - Created named Cloudflare Tunnel: `mobile-vps` (UUID: `3598d9d8-7e98-4ea6-bb24-41f676a6eb60`). - Configured `/etc/cloudflared/config.yml` with ingress rules mapping public hostnames to local Caddy endpoints. - Deployed `cloudflared` as an auto-restarting systemd service. --- ### Phase 5: On-Demand Hybrid Architecture (Headless vs. Desktop) To conserve hardware resources, power, and thermal headroom while preserving the ability to use the laptop as an interactive graphical workstation: 1. **Default Target**: Set to `multi-user.target`: ```bash sudo systemctl set-default multi-user.target ``` 2. **Engineered Switcher Scripts** in `/usr/local/bin`: - [`/usr/local/bin/desktop-start`](file:///usr/local/bin/desktop-start): ```bash #!/bin/bash echo "Starting Graphical Desktop..." sudo systemctl isolate graphical.target ``` - [`/usr/local/bin/desktop-stop`](file:///usr/local/bin/desktop-stop): ```bash #!/bin/bash echo "Stopping Graphical Desktop (Entering Headless Server Mode)..." sudo systemctl isolate multi-user.target ``` - Granted global execution permissions (`chmod +x`). --- ### Phase 6: Zero-USB Online Partition Cloning & Live NVMe Expansion #### The Challenge: The user shrunk the Windows 11 C: drive by 62 GB, creating 62.0 GiB of raw unallocated SSD space. However, partition geometry showed that the free space was located **in front of** (lower sector address) the active Ubuntu root partition (`/dev/nvme0n1p5`). Standard partition tools like `growpart` or `resize2fs` can only expand partitions *to the right* (higher sector addresses). Furthermore, the user had no working USB drive to boot a live rescue environment. ``` SECTOR GEOMETRY OBSTACLE: [ Windows C: ] -> [ 62 GB UNALLOCATED SPACE ] -> [ Partition 5: Active 30GB Ubuntu Root ] ▲ Cannot grow leftward! ``` #### The Zero-Downtime Online Migration Solution: 1. **Creation of New Partition**: Formatted the 62 GB unallocated block into an ext4 partition: `/dev/nvme0n1p6`. 2. **Live Filesystem Mirroring (`rsync`)**: - Mounted `/dev/nvme0n1p6` to `/mnt/new_root`. - Executed full atomic filesystem copy preserving all permissions, ACLs, extended attributes, sparse files, and device nodes: ```bash sudo rsync -aHAXxv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/swap.img"} / /mnt/new_root/ ``` - Created missing virtual filesystem mount points (`/dev`, `/proc`, `/sys`, `/run`, `/mnt`, `/media`). 3. **UUID Re-targeting & Bootloader Integration**: - Extracted UUID of `/dev/nvme0n1p6` (`4fb1a3d8-ac10-402b-8019-4d158a313fbc`). - Updated `/mnt/new_root/etc/fstab` with the new UUID. - Updated GRUB configuration (`sudo update-grub`) so the EFI bootloader could identify the new root partition. 4. **Booting New Partition & Partition Absorption**: - Rebooted system; BIOS booted straight into `/dev/nvme0n1p6`. - Verified active root mount point: `findmnt /` confirmed `/dev/nvme0n1p6`. - Safely deleted the legacy 30 GB partition (`/dev/nvme0n1p5`) using `parted`. - Executed live kernel partition table expansion and ext4 online growth: ```bash sudo growpart /dev/nvme0n1 6 sudo resize2fs /dev/nvme0n1p6 ``` 5. **Final Result**: The active Ubuntu root filesystem successfully expanded from **30 GB to 91 GB (64 GB free space)** with zero data loss and without requiring any live USB media. --- ### Phase 7: Container Storage Relocation & Cleanup 1. **Temporary Loopback Architecture (During 30 GB constraint)**: - Prior to expanding the NVMe partition, a temporary 50 GB ext4 loopback image was created on the NTFS secondary drive: `/media/kaptaan45/Data/docker.img`. - Mounted to `/var/lib/docker` via systemd mount unit `var-lib-docker.mount` to bypass NTFS limitations. 2. **Native NVMe Migration**: - Once the NVMe root partition had 64 GB of free high-speed flash storage, keeping Docker on an emulated loopback file over a 5400 RPM spinning disk was no longer optimal. - Safely unmounted `/var/lib/docker`, stopped `var-lib-docker.mount`, and removed the systemd dependency `docker.service.requires/var-lib-docker.mount`. - Re-enabled native Docker Engine directly on the 91 GB NVMe SSD (`/dev/nvme0n1p6`), achieving maximum IOPS for container image layers and containerd runtimes. - Deleted the 50 GB `docker.img` file on the HDD, reclaiming 50 GB of disk space on the 1 TB drive. - Configured Docker persistent volumes and compose stack definitions to reside on the 1 TB HDD (`/media/kaptaan45/Data/dockge/stacks`), achieving ideal storage tiering. --- ## 5. Comprehensive Troubleshooting & Incident Resolution Log Every technical issue, error code, and unexpected edge case encountered during the project is cataloged below along with root causes and permanent fixes: ### Incident 1: Interrupted `apt upgrade` and Corrupted Desktop Icons - **Symptom**: Machine rebooted mid-upgrade during a 1.5 GB package installation. Upon reboot, desktop shortcuts turned into broken "caution blocks" / red hazard boxes, and APT threw `dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'`. - **Root Cause**: Unfinished package unpack cycle left shared GTK icon caches uncompiled and package databases locked. - **Resolution**: 1. Repaired package database: `sudo dpkg --configure -a`. 2. Fixed missing dependencies: `sudo apt-get install -f`. 3. Rebuilt GNOME / GTK icon caches: ```bash sudo update-icon-caches /usr/share/icons/* sudo gtk-update-icon-cache -f /usr/share/icons/hicolor ``` 4. Regenerated initramfs: `sudo update-initramfs -u -k all`. --- ### Incident 2: NVIDIA NVML Driver/Library Version Mismatch - **Symptom**: Running `nvidia-smi` produced: `Failed to initialize NVML: Driver/library version mismatch`. - **Root Cause**: The package manager updated the NVIDIA userspace library (`libnvidia-ml.so`) to version `580.178.04`, while the older version 550 kernel module was still active in running system memory. - **Resolution**: Rebooted into the updated kernel (`7.0.0-42-generic`). The matching 580 kernel module loaded cleanly, restoring full CUDA and NVML access for hardware acceleration. --- ### Incident 3: Indefinite Boot Freeze via GRUB "Recordfail" - **Symptom**: Whenever an unclean shutdown or hard restart occurred, GRUB froze on the boot screen indefinitely, ignoring `GRUB_TIMEOUT=0`. - **Root Cause**: Ubuntu's `/etc/grub.d/00_header` sets `recordfail_broken=0` on normal boots, but if a crash occurs, `recordfail` triggers an infinite wait loop (`timeout=-1`) designed to let users choose recovery mode. - **Resolution**: Configured `/etc/default/grub` with: ```ini GRUB_RECORDFAIL_TIMEOUT=3 GRUB_TIMEOUT=3 ``` Executed `sudo update-grub`. The bootloader now automatically boots the default OS within 3 seconds regardless of previous crash flags. --- ### Incident 4: Machine Freeze and Crash on AC Power Disconnect - **Symptom**: Unplugging the laptop charger at ~91% battery caused an immediate freeze, black screen, and forced hardware reboot. - **Root Cause**: GNOME power profile triggered `systemd-suspend.service`. The NVIDIA driver failed power management teardown (`nv_pmops_suspend returns -5: error saving video memory`), creating an unrecoverable kernel panic. - **Resolution**: Completely masked all systemd sleep and suspend targets: ```bash sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target ``` Disabled GNOME automatic suspend behavior via GSettings. The laptop now stays fully active when unplugged. --- ### Incident 5: Cloudflare Error 1002 (Disallowed IP) - **Symptom**: Creating a Cloudflare Proxied (Orange Cloud) DNS record pointing to Tailscale IP `100.85.248.103` resulted in `Error 1002: DNS points to local or disallowed IP`. - **Root Cause**: Cloudflare’s public edge proxy strictly forbids routing proxied traffic to Carrier-Grade NAT (RFC 6598 / `100.64.0.0/10`) or RFC 1918 private address ranges. - **Resolution**: Switched private Tailscale DNS records to Gray Cloud (DNS-Only), and implemented Cloudflare Argo Tunnel (`cloudflared`) to tunnel public HTTPS traffic through encrypted outbound QUIC connections. --- ### Incident 6: Cloudflare Tunnel Error 1033 & Domain Appending Conflict - **Symptom**: Executing `cloudflared tunnel route dns mobile-vps dockge.webdomain.live` resulted in Cloudflare Error 1033 and created `dockge.webdomain.live.kaptaanlm.tech`. - **Root Cause**: The initial `cert.pem` origin certificate was authenticated for zone `kaptaanlm.tech`. When routing subdomains, `cloudflared` automatically appended the authorized origin zone. - **Resolution**: 1. Re-authenticated with the target zone: `cloudflared tunnel login` for `webdomain.live`. 2. Updated the origin certificate in `/etc/cloudflared/cert.pem`. 3. Created direct CNAME records in the Cloudflare DNS dashboard pointing `dockge`, `glances`, and `uptimekuma` to `3598d9d8-7e98-4ea6-bb24-41f676a6eb60.cfargotunnel.com`. --- ### Incident 7: Systemd-Resolved Tunnel Resolution Failure - **Symptom**: `cloudflared` logged repeated DNS lookup failures when attempting to resolve edge connection targets like `region1.v2.argotunnel.com`. - **Root Cause**: Ubuntu's local stub resolver (`127.0.0.53`) intermittently failed to forward DNS queries during network interface switches. - **Resolution**: Added static upstream DNS resolvers (`1.1.1.1`, `8.8.8.8`) in [`/etc/systemd/resolved.conf`](file:///etc/systemd/resolved.conf) and restarted `systemd-resolved.service`. --- ### Incident 8: Port 443 Connection Refused on Modern Browsers - **Symptom**: Navigating to `https://dockge.webdomain.live` failed with `ERR_CONNECTION_REFUSED`, while HTTP worked. - **Root Cause**: Modern web browsers enforce HSTS on top-level domains like `.live`. Caddy was only configured to listen on port 80. - **Resolution**: Configured internal TLS termination in `Caddyfile` using `tls internal` and `local_certs`, binding Caddy to port 443 and generating automatic local SSL certificates. --- ### Incident 9: High Web Dashboard Latency (1.5s - 2.0s TTFB) - **Symptom**: Web dashboards felt sluggish and took over 1.5 seconds to load basic assets. - **Root Cause**: 1. Upstream requests defaulted to `localhost`, triggering IPv6 (`::1`) connection attempts that timed out before falling back to IPv4 (`127.0.0.1`). 2. Docker bridge network address translation added hop overhead. - **Resolution**: 1. Switched Caddy container to `network_mode: host`. 2. Explicitly routed all reverse proxy directives to `127.0.0.1:`. 3. Enabled `gzip` and `zstd` HTTP compression in Caddy. Load times dropped to under 120 ms. --- ### Incident 10: SanDisk 32GB USB Read-Only Hardware Lock - **Symptom**: Attempting to format or write a live Ubuntu image to a SanDisk Ultra 32GB flash drive (`/dev/sdb`) failed with `Read-only file system` and `[sdb] Write Protect is on`. - **Root Cause**: Tested software unlock routines (`hdparm -r0`, `blockdev --setrw`, low-level `dd`). Kernel logs confirmed the internal flash controller had entered permanent hardware write-protect mode due to NAND wear limits. - **Resolution**: Pivoted away from physical USB media entirely; designed and executed the **Zero-USB Online Live Root Partition Migration** described in Phase 6. --- ### Incident 11: Docker Service Failure Post-Reboot (`Unit var-lib-docker.mount not found`) - **Symptom**: After expanding the NVMe partition and deleting the temporary 50 GB HDD loop image, Docker failed to start with dependency error `Unit var-lib-docker.mount not found`. - **Root Cause**: A systemd override directory (`/etc/systemd/system/docker.service.requires/`) still contained a symlink requiring `var-lib-docker.mount` before starting `docker.service`. - **Resolution**: Deleted the stale requirement symlink, reloaded the systemd daemon (`sudo systemctl daemon-reload`), and restarted Docker. Docker started cleanly on native NVMe storage. --- ## 6. Resource Utilization & Thermal Benchmarks Comprehensive benchmarks measured between Desktop GUI mode and Headless Mobile VPS mode: | Metric | Desktop GUI Mode (GNOME Shell) | Headless Server Mode (`multi-user.target`) | Efficiency Gain | | :--- | :--- | :--- | :--- | | **Idle Memory (RAM)** | 2.4 GB – 2.6 GB | **650 MB – 850 MB** | **~67% RAM Saved (1.7 GB freed)** | | **Active OS Processes** | ~265 processes | **~112 processes** | **58% fewer background threads** | | **CPU Core Idle Temp** | 48°C – 54°C | **38°C – 41°C** | **~12°C cooler operating temp** | | **Cooling Fan State** | Continuous low spin | **Completely OFF (Passive)** | **Silent operation, zero dust intake**| | **NVIDIA GPU State** | VRAM allocated (Xorg) | **Deep Power State P8 (0 MHz)** | **GPU power draw drops to ~0.5W** | | **Estimated Battery Runtime**| ~1.2 – 1.5 Hours | **2.5 – 3.5 Hours** | **~2.2x longer UPS runtime** | --- ## 7. Network Topology & Access Architecture ``` PUBLIC INTERNET │ ┌─────────────────────┴─────────────────────┐ │ Cloudflare Edge Network │ │ (Anycast DNS + DDoS Protection) │ └─────────────────────┬─────────────────────┘ │ Encrypted QUIC Tunnel ▼ ┌───────────────────────────┐ │ cloudflared Tunnel Daemon │ │ (mobile-vps systemd) │ └─────────────┬─────────────┘ │ ┌───────────────────────┴───────────────────────┐ │ │ ▼ ▼ ┌───────────────────────────────────┐ ┌───────────────────────────────────┐ │ Cloudflare Public Ingress │ │ Tailscale Private Mesh │ │ (*.webdomain.live) │ │ (100.85.248.103) │ └────────────────┬──────────────────┘ └────────────────┬──────────────────┘ │ │ └───────────────────────┬───────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ Caddy Reverse Proxy (Host) │ │ Port 80 (HTTP) -> 443 (TLS)│ └──────────────┬──────────────┘ │ ┌─────────────────────────┼─────────────────────────┐ ▼ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │ Dockge │ │ Glances │ │ Uptime Kuma │ │ Port 5001 (Host) │ │ Port 61208 (Host) │ │ Port 3001 (Host) │ │ (Compose Manager) │ │ (Resource Telemetry)│ │ (Uptime & Alerts) │ └─────────────────────┘ └─────────────────────┘ └─────────────────────┘ ``` ### Production Service Directory: * **Container Management**: [`https://dockge.webdomain.live`](https://dockge.webdomain.live) (Local: `http://127.0.0.1:5001`) * **System Telemetry & Metrics**: [`https://glances.webdomain.live`](https://glances.webdomain.live) (Local: `http://127.0.0.1:61208`) * **Uptime Monitoring & Status**: [`https://uptimekuma.webdomain.live`](https://uptimekuma.webdomain.live) (Local: `http://127.0.0.1:3001`) * **Encrypted Remote Administration**: `ssh kaptaan45@100.85.248.103` (Tailscale SSH) --- ## 8. Summary of Key Engineering Takeaways 1. **Hardware Power Routing Outperforms Software Capping**: When converting laptops into 24/7 edge servers, lack of BIOS 80% charge thresholds is not a blocker if the hardware motherboard implements a true DC passthrough switch (`CURRENT_NOW=0`). Heat is the true enemy of Li-ion longevity; running headless at 38°C with fans off preserves battery chemistry better than running hot under software charge limits. 2. **Storage Tiering is Critical for Dual-Drive Systems**: Keep OS, `containerd`, and active container overlays on NVMe SSD for fast boot and instant I/O response; delegate database volumes, media directories, and compose stack manifests to secondary HDDs. 3. **Zero-USB Live Partition Migration is Feasible**: When partition sector layout prevents conventional rightward resizing, live root cloning via `rsync -aHAXxv` to a newly carved partition, accompanied by fstab/GRUB updates, allows full online root expansion without requiring live rescue USB media. 4. **Desktop Disablement Frees Server-Grade Headroom**: Isolating GUI targets (`multi-user.target`) recovers over 1.7 GB of RAM and 12°C of thermal headroom, transforming an entry-level laptop into an edge server that rivals commercial dedicated instances. 5. **Masking Sleep Targets is Essential for Headless Server Stability**: Consumer laptop drivers (especially proprietary GPU drivers like NVIDIA) are not designed for unattended background state changes; explicitly masking all systemd sleep targets is mandatory to ensure 100% uptime. --- ## 9. Future Architecture Roadmap The foundation is fully established. The upcoming phases for this Mobile VPS are: 1. **`myCam` Deployment**: - RTSP IP camera ingestion via Go2RTC / Frigate. - Enabling NVIDIA GeForce MX130 GPU hardware acceleration for real-time video decoding and motion detection. 2. **`myDomain` & `myCloud` Microservice Stacks**: - Deploying custom API backends and object storage onto the 1 TB HDD via Dockge stacks. 3. **Automated Snapshot & Offsite Backup Automation**: - Setting up Restic or BorgBackup with cron/systemd timers to automatically snapshot Docker configs and databases from the 1 TB HDD to remote encrypted cloud storage.