LXC update process doesn't start

[Pyromane]

Hello,

a few day ago, I set up Meshmonitor LXC following the instructions:
https://github.com/Yeraze/meshmonitor/blob/main/docs/deployment/PROXMOX_LXC_GUIDE.md#quick-start

Currently, the Meshmonitor in the container is running version v4.10.2, but v4.11.0 is already available
Now I’d like to update it and followed the instructions at https://github.com/Yeraze/meshmonitor/blob/main/docs/deployment/PROXMOX_LXC_GUIDE.md#automated-update-recommended,
but I’m only getting the following output:

root@pve04:/opt# wget https://raw.githubusercontent.com/Yeraze/meshmonitor/main/lxc/update.sh
--2026-06-20 09:43:09--  https://raw.githubusercontent.com/Yeraze/meshmonitor/main/lxc/update.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.110.133, 185.199.108.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.110.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 23293 (23K) [text/plain]
Saving to: ‘update.sh’

update.sh                100%[===============================>]  22.75K  --.-KB/s    in 0.002s  

2026-06-20 09:43:10 (10.5 MB/s) - ‘update.sh’ saved [23293/23293]

root@pve04:/opt# chmod +x update.sh
root@pve04:/opt# ./update.sh --ctid 111
[+] Auto-detecting latest MeshMonitor release...
[+] Latest release: v4.11.0
root@pve04:/opt#

111 is the ID of the MeshMonitor container
No changes are apparent either on the Proxmox Host 9.2.3 or in the LXC

Could someone please point me in the right direction? Thanks!

[BeerMan81]

Hi,

Its not always so easy to update the LXC. I have a script that does this for u. I worked with AI to help with the docs and scripts. There is a bit of setup on the front side, git clone etc. but once deployed you have a easy way to update and rollback.

https://gist.github.com/BeerMan81

[BeerMan81]

Also, it has some switches available like help, dry run etc..

[Pyromane]

Thank you very much for the detailed instructions and the update routine; I'll test them later using a clone of the VM.

[BeerMan81]

Now I have read both scripts in full. Here is the corrected, accurate comparison based solely on the actual code.

---

The lxc/update.sh script is a Proxmox-host–side "destroy and recreate the LXC from a new template" updater, while the BeerMan meshmonitor-update-script.sh is an in-place "git pull + rebuild" updater that runs inside the OS — and notably also works with the official LXC template deployment. They solve different problems and have very different safety and rollback characteristics.

What each script is designed for

lxc/update.sh (Yeraze repo)

• Intended environment: Proxmox VE host (run as root on the hypervisor), managing a MeshMonitor LXC created from the official MeshMonitor LXC template.

• Update mechanism:

  • Auto-detects the latest GitHub release or accepts an explicit --version.

  • Reads the existing CT's pct config to capture: cores, memory, swap, rootfs size, storage pool, bridge, and net0 IP.

  • Optionally takes a Proxmox snapshot before any destructive action (TAKE_SNAPSHOT=1 by default).

  • Backs up /data and /etc/meshmonitor/meshmonitor.env to /root/meshmonitor-lxc-backups/ on the host.

  • Stops the CT, destroys it (pct destroy), downloads the new LXC template, recreates the CT with the same resource profile, and restores the /data and env file into the new container.

  • Restarts meshmonitor and meshmonitor-apprise systemd services inside the new CT.

• Usage examples (from the script header):

  • ./update.sh --ctid 100 → auto-detect latest release.

  • ./update.sh --ctid 100 --version 4.6.5 → pin explicit version.

  • CTID=100 CONFIRM=YES_DESTROY ./update.sh → non-interactive, cron-friendly.

  • ./update.sh --ctid 100 --network dhcp or --custom-ip 192.168.1.50/24,gw=192.168.1.1 → override network at update time.

• Design philosophy: Treat the LXC as an immutable image. On every upgrade, rebuild from a clean template and restore only the explicitly defined persistent state (/data and /etc/meshmonitor/meshmonitor.env). The OS, systemd units, and application binaries come entirely from the new template.

meshmonitor-update-script.sh (BeerMan gist, v0.30)

• Intended environment: Any OS-level deployment of MeshMonitor installed via git clone, including the official LXC template (default: /opt/meshmonitor), bare-metal, or VMs. Explicitly detects and refuses to run in Docker.

• Auto-detected install paths (searched in order): /opt/meshmonitor, /var/lib/meshmonitor/meshmonitor, /var/lib/meshmonitor, /home/meshmonitor/meshmonitor, current directory.

• Update mechanism:

  • Acquires a flock-based run lock (/var/run/meshmonitor-update.lock) to prevent concurrent executions.

  • Detects the app user (owner of the install dir) and runs all git commands as that user to avoid Git 2.35+ "dubious ownership" errors on Debian 12.

  • Detects all running systemd services (meshmonitor, meshmonitor-apprise).

  • Detects PORT and DATA_DIR from the active EnvironmentFile declared in the systemd unit, falling back to /etc/meshmonitor/meshmonitor.env.

  • Creates a timestamped backup tarball (kept up to 5) of: the data directory (/data or $INSTALL_DIR/data or DATA_DIR from env), meshmonitor.env, and systemd service files. Saves the current git commit hash to last-commit.txt. Warns loudly if the tarball is suspiciously small (< 50 KB), indicating the database was likely not captured.

  • Stops services, stashes any local git modifications, runs git pull origin main + git submodule update, pops the stash after pull.

  • Copies updated lxc/systemd/meshmonitor.service and meshmonitor-apprise.service from the repo into /etc/systemd/system/ and runs systemctl daemon-reload.

  • Clears any stale Puppeteer browser cache (introduced in MeshMonitor 4.7.x) to prevent the "folder exists but chrome executable missing" error.

  • Runs npm install --legacy-peer-deps (with PUPPETEER_SKIP_DOWNLOAD=true), npm run build, and npm run build:server with a configurable Node.js heap cap.

  • Restores ownership of the install directory to the original app user/group.

  • Starts services and runs an HTTP health check on the app port (up to 30 seconds).

  • Emits explicit migration warnings when crossing major versions (e.g., v2.20.0 multi-source changes, v4.0.0 DB schema migrations).

• Additional CLI modes:

  • --dry-run / -n: Print every action that would be taken, change nothing.

  • --rollback / -r: Restore from the most recent backup tarball with a scoped menu (everything, code only, or data only). Always requires typing yes in full — -y does not bypass it.

  • --status / -s: Truly read-only snapshot using git ls-remote (no local writes); shows installed version, local commit, remote commit, and service states.

  • --list-backups / -l: Lists all available backup tarballs with sizes and dates.

  • --debug / -d: Enables set -x tracing and saves a timestamped log to the backup directory.

  • Supports combined short flags: -rn (preview rollback), -yn, -dny, etc.

• Self-install behavior: On first run from a non-system path, it offers to install itself to /usr/local/bin/meshmonitor-update so you can call it from anywhere.

• Design philosophy: In-place, git-driven update that treats the underlying OS and container as stable. Focuses on safely updating application code and Node dependencies, with first-class backup, rollback, health-checking, and dry-run observability.

Key behavioral differences

Deployment coupling

• lxc/update.sh is tightly coupled to the Proxmox host: it calls pct config, pct stop, pct destroy, and pct create — none of which exist inside a container. It must run on the hypervisor.

• The BeerMan script runs inside the OS (LXC, VM, or bare metal) and never touches the hypervisor. It only needs systemctl, git, and npm.

Update scope

• lxc/update.sh replaces the entire container rootfs from a fresh template: new OS image, new binaries, new systemd units — everything. Only /data and /etc/meshmonitor/meshmonitor.env survive.

• The BeerMan script updates only the MeshMonitor application and its Node dependencies via git pull + npm rebuild. The base OS, installed packages, and container configuration are entirely untouched. It also updates the systemd unit files from within the repo (lxc/systemd/) on each run.

Rollback model

  | Yeraze lxc/update.sh | BeerMan meshmonitor-update-script.sh -- | -- | -- Rollback mechanism | Proxmox snapshot + host-side file backups in /root/meshmonitor-lxc-backups/ | Timestamped tarball + saved git commit hash; --rollback flag with scoped restore menu Rollback granularity | Full CT restore from snapshot | Choose: everything, code only, or data only Rollback trigger | Manual Proxmox snapshot restore | meshmonitor-update --rollback Backups retained | Operator-managed (configurable days, default: never prune) | Last 5 tarballs (configurable)

Configuration and data preservation

• lxc/update.sh preserves /data and /etc/meshmonitor/meshmonitor.env by extracting them before CT destruction and injecting them into the new container. Everything else in the old CT is gone.

• The BeerMan script leaves all data in place. It backs it up before touching anything, runs the update, and restores ownership afterward. State never leaves the machine.

Network and CT resources

• lxc/update.sh introspects pct config to reapply cores, memory, swap, rootfs size, storage pool, bridge, and the net0 IP/gateway when recreating the CT. Flags like --network dhcp or --custom-ip let you override at update time.

• The BeerMan script never touches Proxmox, network bridges, or CT resource allocation — it has no host context at all.

Error handling and safety

Both scripts use set -euo pipefail. Their safety mechanisms operate at different layers:

• lxc/update.sh: Validates all inputs (CTID format, version semver, IP CIDR format, root password hash format) to prevent shell injection. Takes a Proxmox snapshot before destructive steps. Creates host-side file backups of /data and env before CT destruction. If template download or CT recreation fails, backups and snapshot remain intact on the host.

• BeerMan script: Uses flock to prevent concurrent runs. Stashes local git modifications before pulling so git pull never fails due to local edits (and re-applies the stash afterward). Verifies build and build:server scripts exist in package.json before stopping services. Health-checks the app on HTTP after restart. Posts specific warnings for major version migrations that require manual review. Rollback always requires explicit yes confirmation regardless of --yes flag.

Which should you use?

From a "pets vs. cattle" perspective:

• Use lxc/update.sh when your MeshMonitor LXC is cattle: you make no OS-level customizations inside the container, trust the upstream template fully, and want the cleanest possible upgrade path where every release starts from a known-good OS image. Ideal for set-it-and-forget-it deployments.

• Use the BeerMan script when you want in-place, git-aware updates without ever destroying the container — whether you're on the official LXC template, a VM, or bare metal. You get granular rollback, dry-run previews, health checks, and migration guidance, all without Proxmox involvement.

For a Proxmox homelab using the official LXC template with no OS-level customizations, either approach is valid. The Yeraze script guarantees a clean OS on every upgrade; the BeerMan script gives you more operational control and observability during the update process without the risk of container recreation.

[Pyromane]

Thank you very much for the detailed answer and the explanation of the differences!

I downloaded the LXC template https://github.com/Yeraze/meshmonitor/releases/download/v4.10.2/meshmonitor-4.10.2-amd64.tar.gz from the Releases section and created the LXC container using that template.

[Yeraze]

Nice work! Interested in submitting that as an official contribution to the github?

I don't have LXC so I can't test it here, but willing to host and share it if you want.

[BeerMan81]

@Yeraze Yes I have considered this. I’ve iterated on the script numerous times since 3.1.x to ensure updates went smoothly. Eventually I came to the conclusion that my simple script needed more rigor and that’s where AI directed me to the GIST route where a lot of effort was put into generalizing the code for the masses.

One consideration is the initial migration from development-provided LXC to GitHub-linked version has not been fully tested beyond my initial struggles in the 3.x days.

I would like get that piece automated from the current LXC to GitHub-linked version. My AI deployment methods are not as sophisticated as yours. I’ll work on and ensure a from-scratch approach is rigorous enough for a pull-request.

[BeerMan81]

@Pyromane Try this migration script. if you have a bare metal install or LXC, this will migrate to a git-linked version. it works for me and docs are updated there. https://gist.github.com/BeerMan81/06c562c32582b14ab7437dfb2ad8cbd0 . I would like some feedback.

[Pyromane]

--dry-run ran without any problems

The actual update process didn't finish after more than four hours, so I canceled it. (CPU, RAM, and SWAP were at full capacity the whole time.)

I would restore the Snapi to its state before the update attempt and then restart the update attempt with the -d parameter.

[BeerMan81]

@Pyromane Thanks for testing! The dry-run passing is great. The 4-hour run with maxed resources is almost certainly a RAM issue — npm run build needs significant Node.js heap for the TypeScript compilation. Could you share what RAM your LXC has? The script should auto-detect it and cap the heap accordingly. If you want to retry, try adding more RAM to the container first (2GB minimum, 4GB recommended). Also worth checking journalctl -u meshmonitor after to see if the build actually completed before the timeout.