PR #223 shipped the install_proxmenux.sh unit-rewrite fix together
with a version bump to 1.2.2.1 and a matching CHANGELOG entry.
With both the fix (#223) and the menu self-heal (#224) already in
main the bump turns out to be unnecessary for recovery:
* Users on v1.2.1 stable updating now pull the corrected installer
from main and arrive at v1.2.2 working.
* Users stuck on a broken v1.2.2 get repaired by
`auto_repair_monitor_unit` on every menu launch.
* Users on a healthy v1.2.2 had nothing to fix.
Leaving 1.2.2.1 published would force a no-op update prompt across
every healthy v1.2.2 install. Revert version.txt to 1.2.2 and drop
the v1.2.2.1 CHANGELOG section (EN+ES) so the public release notes
stay clean.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The v1.2.2 install layout extracts the AppImage into
/usr/local/share/proxmenux/monitor-app/ and runs AppRun out of that
directory — but install_proxmenux_monitor's update branch only
called create_monitor_service on fresh installs, leaving the inherited
unit's `ExecStart=/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage`
in place. That path used to be the FUSE-mounted AppImage entry point,
which v1.2.2 deliberately replaced to clear a Wazuh rule-521 false
positive on /tmp/.mount_*. On PVE 9.x / Debian 13 the bare AppImage
fails to exec straight away (status=203/EXEC) so the service entered
the activating loop reported in #222 and never came back up.
Always rewrite the unit before the post-update `systemctl start` —
idempotent for installs whose unit is already correct, recovering
for those whose isn't. The new helper
`_proxmenux_rewrite_monitor_unit_for_apprun` mirrors the unit body
the fresh-install path emits in `create_monitor_service`, with the
same template-from-repo / inline-fallback fork, so both paths
converge on the same content.
Reproduced and validated on PVE 9.x lab:
before:
Process: ExecStart=/usr/local/share/proxmenux/ProxMenux-Monitor.AppImage
(code=exited, status=203/EXEC)
Active: activating (auto-restart)
after:
ExecStart=/usr/local/share/proxmenux/monitor-app/AppRun
Active: active (running)
Bumps version.txt to 1.2.2.1 so the existing menu update path picks
this up automatically. For users already stuck on a broken v1.2.2,
re-running the installer manually applies the same fix:
bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)"
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Final ingredient of the v1.2.2 stable release: flip version.txt from
1.2.1 to 1.2.2 so the stable channel's update notifier picks it up
on every running install, ship the consolidated v1.2.2 entry on both
CHANGELOG.md (English) and lang/es/CHANGELOG.md (Spanish), and add
the GitHub link to Jonatan Castro on the contributors page.
CHANGELOG.md entry (and its ES mirror) consolidates the four v1.2.1.x
betas into a single stable note grouped by theme — Health Monitor
configurability, Apprise full feature parity, LXC update detection,
Coral TPU latest upstream drivers, performance optimizations (smartctl
scheduler, fail2ban cache, lxc-info /proc), HTTPS terminal handshake,
PVE 9.x kernel update detection, NVIDIA installer improvements, i18n
documentation site — plus an Acknowledgments section crediting
@jcastro (5 direct commits), @pespinel (1 commit) and @ghosthvj
(field reports that shaped the GPU + Coral work).
contributors/page.tsx: Contributor interface now carries an optional
`githubUrl`; when set, the displayed name is wrapped in an
ExternalLink to that URL (target=_blank). Jonatan Castro's entry gets
`githubUrl: https://github.com/jcastro` so users can reach his repos
from the testers grid.
After this PR merges:
- Users running `menu` will be offered the 1.2.2 upgrade
- proxmenux.com/en/changelog and /es/changelog ship the new entry
(deploy.yml triggers because CHANGELOG.md, lang/** and web/** are
all touched)
- Jonatan Castro's name on the contributors page becomes clickable
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
MacRimi