A user who rode the beta channel and later switched back to stable
keeps a leftover beta_version.txt under /usr/local/share/proxmenux/.
The `menu` launcher's beta-mode update check (`check_updates_beta`)
short-circuits when that file isn't present, but it stays put across
stable installs and updates today, so the user keeps seeing the
"Beta update available" prompt on top of the legitimate stable one
even though they're no longer on the beta channel.
Drop the marker on every stable install/update, in both the update
path (around the `cp ./version.txt` near the scripts-tree wipe) and
the fresh-install path (the symmetric block lower in the file).
The comment about which files survive a scripts-tree wipe is
updated to no longer mention beta_version.txt, since that's exactly
what we're removing.
If the user re-opts into the beta program, install_proxmenux_beta
re-creates the file — this only clears stale state that the user no
longer has any way to update from anyway.
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>
- Check if AppImage exists before attempting installation
- Display clear error message when AppImage is not found
- Update config to track installation failure state
- Restructured installer to use local repository files instead of remote downloads for improved reliability
- Added comprehensive logging functions (spinner, type_text, msg_* helpers) and dual logo support for SSH/noVNC terminals
- Implemented AppImage version detection, SHA256 verification, and systemd service management for ProxMenux Monitor
- Updated metadata to reflect toolkit positioning and added contributor attribution
- Changed from local script loading to cloning repository into temporary directory
- Added cleanup function with trap to ensure temporary files are removed on exit
- Added git as a required dependency for the installation process
- Replaced remote file downloads with local file copying for more reliable installation
- Added proper cleanup of existing monitor service before reinstallation
- Enhanced error handling and logging for monitor service startup
- Improved SHA256 verification for monitor AppImage
- Added copying of install script and all utility scripts to base directory
- Updated progress messages to be more descriptive and accurate
- Increased monitor
MacRimi
cod378
MacRimiandGitHub