* fix(lxc-stack): use dist-upgrade and improve recovery prompt
When the host LXC stack is too old for a template, upgrading only
pve-container/lxc-pve can leave the Proxmox stack in an inconsistent state.
Use a full dist-upgrade instead.
Also refine the recovery prompt:
- [1] Upgrade LXC stack now
- [2] Older template fallback only when actually available
- [3] Ignore
- [4] Cancel
Do not auto-fallback to an older template after ignore/failure; honor the
user's explicit choice and stop with a clear error instead.
* chore(lxc-stack-prompt): clarify host dist-upgrade action in option 1
* Update build.func
* fix(lxc-stack): use host upgrade instead of dist-upgrade in recovery flow
* Enhance upgrade prompt with warning message
Added a warning message to inform users about the implications of running the host upgrade.
---------
Co-authored-by: Michel Roegl-Brunner <73236783+michelroegl-brunner@users.noreply.github.com>
* fix(mealie): restore start.sh before build steps to prevent broken container
When CLEAN_INSTALL=1 wipes /opt/mealie/* and a subsequent build step fails
(uv sync, yarn install, yarn generate - e.g. due to OOM or network error),
start.sh was never written because it was created at the very end of the
update function. On the next reboot systemd could not find the ExecStart
binary and the container was left in a permanently broken state.
Fix: move mealie.env restore and start.sh creation to immediately after
fetch_and_deploy_gh_release, before any build steps that can fail. This
ensures the service entry point is always present even if the build is
interrupted, allowing uv to self-heal on next startup.
Fixes: #13945
* fix(mealie): backup and restore start.sh alongside mealie.env
Instead of recreating start.sh from a heredoc after CLEAN_INSTALL wipes
/opt/mealie/*, simply back it up before the wipe and restore it together
with mealie.env. Simpler and avoids any drift between the hardcoded
heredoc and what was actually installed.
* fix(mealie): fallback heredoc if start.sh missing before backup
* fix(twingate-connector): perform real apt upgrade during update flow
The update path used ensure_dependencies, which only installs missing
packages and does not upgrade already installed ones. As a result, users
could see 'Updated successfully' even when a newer twingate-connector
version was available.
Switch update_script to a real package update flow:
- ensure apt is healthy
- refresh apt metadata
- install/upgrade twingate-connector via retry helper
- restart service
This aligns behavior with Twingate's documented upgrade process.
* Update twingate-connector.sh
In setup_nodejs() Scenario 1 (major version already matches), only npm
was refreshed - apt never upgraded the nodejs package itself. This left
existing LXCs stuck on older minor releases (e.g. 22.13.1) even though
NodeSource ships newer ones (e.g. 22.19+).
Fix: add pt-get install -y --only-upgrade nodejs before the npm pin
so the latest minor/patch from the already-configured NodeSource repo is
always installed.
Fixes: seerr update failing with ERR_PNPM_UNSUPPORTED_ENGINE because
seerr 3.2.0 requires Node >=22.19.0 but installed was v22.13.1 (#13955)
When PHS_SILENT and PHS_VERBOSE are both set, stop falling back to interactive mode. Changes prefer silent mode to keep automation safe and avoid blocking unattended/non-TTY updates. Only show a whiptail warning when both stdin/stdout are TTYs and whiptail is present, and ignore any whiptail errors. Added a brief comment and adjusted the fallback message accordingly.
community-scripts-pr-app[bot]