Portainer and the agent are written as Quadlet .container units, which
need Podman 4.4. Debian 12 ships 4.3.1, so systemctl start portainer
failed with "Unit portainer.service not found". Without Quadlet both
prompts are skipped with a warning.
* fix(truenas-vm): let a failed ISO lookup reach its own error
When download.truenas.com did not answer, the lookup handed an empty
path to an associative array (bad array subscript) and the pipeline
failed under pipefail, so the run ended with exit 1 at the SELECTED_ISO
line instead of the "Could not find a stable ISO" message. The index
fetch now fails on HTTP errors and retries, empty lines are skipped, and
the assignment no longer aborts on an empty result.
* fix(truenas-vm): use the engine's retry flags for the ISO index
* fix(proxmox-mail-gateway): take the repo suite from the container
The install hardcoded trixie, so a Debian 12 container got the PMG 9
repository and pmg-api could not resolve its trixie dependencies (held
broken packages). Suite and key now follow the container's codename;
bookworm still has PMG 8 with proxmox-mailgateway-container.
* fix(proxmox-mail-gateway): read the codename inline
* fix(immich): take the watchfiles wheel and retry GeoNames longer
The v3.3.5 lock pins watchfiles 0.21.0, which has no wheel for the
Python 3.13 machine-learning venv, so every ML install downloaded a Rust
toolchain and compiled it. Where static.rust-lang.org reset the
connection, uv sync failed three times. --upgrade-package watchfiles
takes 1.3.0, an abi3 wheel; only uvicorn's reload mode uses it.
download.geonames.org dropped connections on 11-03/04 and the first file
failed after three 10 s connects; those four calls now retry six times
with a 30 s connect timeout.
* Immich: bump release version to v3.3.6
v3.3.6 disables onnxruntime's telemetry in immich_ml, which runs from
source here, so nothing else changes. The lock still pins watchfiles
0.21.0, so the wheel upgrade stays.
The compose file from main now uses ARCANE_ENCRYPTION_KEY and
ARCANE_PROJECTS_DIRECTORY, which the latest image (2.17.3) does not read,
so it panicked on a missing ENCRYPTION_KEY. Arcane 3 in turn refuses to
start when only the old names are set. Install and update now keep both
names in compose.yaml, which also carries existing installs over to 3.
The .env was never referenced by the compose file, but compose parses it,
and the unanchored ENCRYPTION_KEY sed turned the renamed line into
ARCANE_#ENCRYPTION_KEY and broke every install. New installs no longer
download it; update repairs the broken line.
The FreeBSD image boots in under a minute when both NICs get DHCP, but
dhclient waits 60 seconds on each NIC without a DHCP server, which is the
normal case for a firewall's LAN before setup. On vx-pve an isolated LAN
took 110 seconds; the reporter of #18464 measured 210. The keys then went
into the boot output. The image prints its login prompt on the serial
console as well, so the script now reads serial0 and continues when it
appears, up to 15 minutes, or waits the old 3 minutes if the console
cannot be read.
Tududi 2.0.0 dropped SQLite and refuses to start next to a populated 1.x
database. New installs set up PostgreSQL and let start.sh create the
schema; db:init would sync the tables without SequelizeMeta and make
db-prepare treat the database as an old 1.x one. Installs without
DATABASE_URL stay on 1.15.0, the final SQLite release, which also brings
back installs that already updated to 2.0.0.
Uploads lived in backend/uploads, which CLEAN_INSTALL wiped on every
update; they move to /opt/tududi-uploads.
n8n-nodes-base 2.46.0 moved @napi-rs/canvas-linux-arm64-musl and
-linux-x64-musl from optional into hard dependencies. npm enforces
os/cpu/libc on those, and no combination satisfies both arm64 and x64,
so every install fails with EBADPLATFORM. n8n 2.46.4 reached the latest
tag on 2026-11-03 and the failures started four minutes later.
--force skips the platform check. The matching gnu binary is still
installed through @napi-rs/canvas's own optional dependencies, so canvas
keeps working.
* Wiki.js: install 3.x
Wiki.js 3 lives in requarks/wiki, needs Node.js 26 and creates its own ltree and pg_trgm extensions in the wiki schema, and starts with node --no-experimental-webstorage backend. dataPath moves out of the app folder, which every update replaces; the admin password is generated and saved to ~/wikijs.creds. Updates follow upstream's guide and put Puppeteer back when it was installed. 2.x containers keep getting 2.x updates from requarks/wiki-v2, since 3.x cannot upgrade them in place, and are told how to export and import.
* Refactor credential output to use heredoc syntax
close-invalid-pr-template.yml now comments and labels (missing pr template,
stale) instead of closing immediately, clears itself once fixed. stale_pr_close.yml
gains the engagement-gated/keep-open/maintainer-reset behavior already used in
DevScripts, so a template-stale PR only closes via its own re-check.
request-script.yml discussion template gets an optional Justification field;
a new workflow verifies stars/age against GitHub for the submitted repo and
either does nothing (eligible), labels investigation (ineligible + justified),
or closes the discussion (ineligible, no justification).
Moved the AI Assistance section to the end of pull_request_template.md.
vzdump and pct restore ran with their output thrown away, so a failed
backup only said "Backup failed for container N" (exit 235). That is the
second most common update-apps failure and none of them can be told
apart. Keep the output in the run log and put its error line in the
message, e.g. "CT is locked (backup)".
var_backup_storage was matched with grep -w, so "truenas" passed when
only "truenas-backup" exists and vzdump then failed on a storage that
does not exist. Match the whole name, and list the valid ones in the
error instead of a spinner line after it.
Name the app in "Update failed for container N", so a failed update
says which app's update failed. Declining the start dialog now exits 0
like the other tools instead of failing with whiptail's 1.
* OpenWrt VM: read the stable release from downloads.openwrt.org
The version came from a line of text on the openwrt.org wiki front page.
One host got that page without the line three times in a row while
others resolved fine at the same moment, and the run ended with exit 115
before anything was downloaded. .versions.json on the download server
is what the OpenWrt firmware selector reads and names the stable release
explicitly.
* Update vm/openwrt-vm.sh
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
---------
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
clear exits 1 for a TERM the host has no terminfo entry for, such as
xterm-ghostty or xterm-kitty over SSH, and when TERM is unset under cron.
The tools that run under errexit died on it in header_info within a
second, before showing anything, which telemetry counts as
"exit_code=1 | General error" with no step for update-lxcs, update-repo,
fstrim, clean-lxcs, execute and storage-share-helper.
Fall back to the escape sequence the engine's _cs_clear uses.
Both whiptail prompts ran bare under errexit, so No on the first question
or Cancel in the template list ended in the error handler and was reported
as a failed run (3 of 5 failures in three days).
Monitor-All is now stopped right before the download instead of at the
start, so leaving at a prompt no longer leaves it stopped.
The user was the first passwd entry with a UID from 1000 up. On a Proxmox
host with Ceph that is ceph (UID 64045, shell nologin), and su - ceph fails
with "This account is currently not available". Accounts without a login
shell are skipped now.
apt update on a host with the enterprise repository and no subscription exits
100 on the 401. apt_update_safe retries, says why and carries on, as the other
scripts already do since #17462.
The script ran its own apt-get update before installing
libguestfs-tools, so one broken or stale repository on the host (a 404
for a hand-added proxmox.com or debian.org entry) ended the run with
exit 100. vm_prepare_cloud_image installs the tools itself and carries
on when an update fails, so the install can still succeed from the
repositories that did update.
Cinephage depends on camoufox instead of camoufox-js, whose bin is called camoufox, so the install stopped at "node_modules/.bin/camoufox-js: No such file or directory" (6 runs in three days).
- VectorChord moved to supervc-stack/VectorChord. With the GitHub API
rate limited, core reads the release from github.com, finds no asset
under the old name and stops with "No suitable .deb asset found".
- mise installed every tool in Immich's mise.toml. Java (for the Dart
OpenAPI generator), terragrunt and opentofu are not needed for the
plugin build, and the Java index timed out on slow links.
- GeoNames failed after the 1-3 h library build; it now downloads first.
- Stop on x86-64 CPUs without SSE4.2: the web build ends there with
"Illegal instruction" after the libraries are built.
The script replaced the engine's error_handler with one that sent the
failed command as the exit code, so every failure reached telemetry as
exit 199 "exit code not reported", without the failed command or
category. Its signal traps sent words instead of codes the same way.
It also ran its own unguarded apt-get update for libguestfs-tools, so a
host with the enterprise repository and no subscription (401) stopped
there. vm_prepare_cloud_image installs the tools itself, tolerating a
repository that fails to update.
The container menu lists stopped containers too, and pct exec on one exits
255: 12 of 41 failures in three days. Start it the way add-netbird-lxc does
and wait for its default route.
The install runs under bash, which an Alpine container from the template does
not have; lxc-attach then exits 127 before the Alpine branch is reached.
Install bash there first, and stop with a clear message on any OS other than
Debian, Ubuntu or Alpine instead of failing on apt-get.
WGDashboard builds its frontend with Vite during the install, and at 512 MB the kernel killed node: "Failed to compile frontend", then wg-dashboard would not start (11 runs in three days). The build finishes at 1 GB.
* Zabbix: install on Debian 12 again
The install and the update fetched Zabbix's release package for Debian 13 and php8.4-pgsql, so a Debian 12 container stopped with "Unable to locate package php8.4-pgsql" (12 runs in three days). Zabbix publishes 7.0 and 7.4 for Debian 12 too: take the container's Debian version and the distribution's php-pgsql.
* Zabbix: leave the update as it was
The update refuses Debian 12 on purpose, so its release URL stays as it was.
Nothing checked that the host is a Backup Server. On a PVE host the
first step stopped only because tar found no /etc/proxmox-backup (exit
2); answering "no" to that backup would have gone on to delete
/etc/apt/sources.list.d/*.list, add the PBS repositories and
dist-upgrade. Stop with the same message post-pbs-install uses.
community-scripts-pr-app[bot]