* Immich: survive an interrupted update and a failing ML build
An update cancelled midway leaves /opt/immich/app empty, and the next run
died at once on cd /opt/immich/app/bin to enable maintenance mode (#17796).
Maintenance mode is now only toggled when immich-admin exists.
uv sync fetching the ml-models git dependency failed with "Could not resolve
host" behind DNS filters such as AdGuard while DNS itself worked (#17797);
running uv one download at a time got through. Retries now do that.
If machine learning still cannot be built, the update no longer stops with
maintenance mode on and every service down: it finishes, starts the web
service, puts the previous version back into ~/.immich so the next update
retries, and exits with an error. Updates are also announced as taking
5-15 minutes, since the first report came from cancelling one that looked
stuck.
* Immich: point immich-ml at the moved ml_start.sh and clear failed units
The update moves ml_start.sh into app/machine-learning, but only rewrote
immich-web's ExecStart, so older containers kept starting ML from
/opt/immich/ml_start.sh and failed with 203/EXEC. Rewrite immich-ml the same
way. A crash loop before the update can also leave both units rate-limited,
which makes the final restart fail; reset them first.
* Immich: pin v3.3.0 again
Reapplies #17759, reverted in #17767 because machine learning broke on 3.3.0; the fixes follow.
* Immich: run machine learning on Python 3.13
3.3.0 requires Python >=3.12 for machine learning and upstream builds both its CPU and OpenVINO images on 3.13. The CPU path still pinned 3.11, so uv sync failed on every update and install (#17762).
* Immich: stop when uv sync keeps failing
After three failed attempts the loop still reported the machine-learning step as done, so an update ended in "Updated successfully" with no usable venv and immich-ml failing on start. Exit with an error instead.
* Immich: only mention the HEIC patch when it applies
On 3.3.0 the sharp call it rewrites is gone, so every run printed "pattern not found, skipped" into the spinner line and then "Patched". Check for the pattern first and stay silent otherwise.
* BookOrbit: retry the client build when the bundler crashes
Since rolldown 1.2.8, vite build dies at random with SIGSEGV or SIGBUS
(rolldown#10860, closed upstream), which stopped the 3.3.0 update with exit
139 (#17753). Retry the client build up to three times before giving up.
The URLs came from the ML Dockerfile on main, which upstream moved into
scripts/install-intel-runtime.sh, so update failed on the grep and
OpenVINO installs found no packages.
* Scripts: close every msg_info block with msg_ok
Past-tense msg_info calls that should have been msg_ok, notices that opened a block before a prompt, and blocks without a closing msg_ok. These already left a stale spinner; with core's block stack they would resume it after every later msg_ok.
* Generate passwords with random_password
openssl rand -base64 | tr -dc | head -c returned fewer characters than asked for, and the unfiltered | cut variants put / and + into passwords that end up in DSNs and sed expressions. Secrets an app decodes as base64 are unchanged. Requires community-scripts/core#61.
* Keep data directories through CLEAN_INSTALL instead of copying them
create_backup copied uploads, storage and similar directories twice per update and needed their size again in free space. CLEAN_INSTALL_KEEP moves them aside instead. Only directories the upstream release does not ship, in scripts that restored right after the fetch. Requires community-scripts/core#61.
* Drop the 300s uv timeout overrides
setup_uv exports UV_HTTP_TIMEOUT=600 now; the scripts' 300 only lowered it. Requires community-scripts/core#61.
* immich: keep geodata linked and the build deps present on update
The update wipes $APP_DIR before redeploying, which takes the geodata
symlink the install created with it, and never puts it back. The app
then finds no reverse-geocoding data and the web UI does not come up.
The library recompile assumes headers that only reached the install
list later, so a container built before that fails at the first missing
one - LCMS2 in the reported case.
* immich: keep geodata linked and the build deps present on update
The update wipes $APP_DIR before redeploying, which takes the geodata
symlink the install created with it, and never puts it back. The app
then finds no reverse-geocoding data and the web UI does not come up.
The library recompile assumes headers that only reached the install
list later, so a container built before that fails at the first missing
one - LCMS2 in the reported case.
* Move the top 25 scripts onto the core engine
The engine work of the last few days reaches 30 of 561 ct scripts, about 5% of
ProxmoxVE traffic: retry on engine downloads, exit 227 instead of a misfiled
dpkg error, the umask fix that stops a hardened host producing containers apt
cannot resolve in, the TMPDIR guard, the toolchain restore. All of it has been
sitting where almost nobody runs it.
All eighteen at once rather than in waves. A slow rollout does not exercise the
paths only some scripts take, and broad exposure is what surfaces bugs -- a
deliberate call about release risk.
Checked before touching anything, because "migrate" meant far more than a line
swap last time:
- None of the eighteen has an alpine-* variant, so there is no merge to do.
- No script references misc/ outside its bootstrap line.
- Of the 61 functions that exist only in misc/, none is called by any of them.
So it is one line per script, and every head is now byte-identical to the ones
migrated earlier. With these, ProxmoxVE goes from 30 scripts on the core engine
to 48 -- and from roughly 5% of traffic to the majority, since these are the
ones people actually install.
Two to watch: immich sits at 44.7% success and vaultwarden at 42.1% before
this. If their numbers move, the engine is one of two changed variables rather
than the only one.
* Move update-apps onto the core engine
Entry 11 of the list and the only one that is not a ct script, so it was left
out of the previous commit. It is a host tool: it never used build.func at all,
it sources misc/core.func and misc/api.func directly.
The swap is therefore two lines rather than one, and worth checking rather than
assuming. It uses exactly five engine functions -- header_info,
init_tool_telemetry, msg_info, msg_ok, msg_error -- all present in the core, and
both files load standalone, which they had not had to do before: everywhere else
they arrive through build.func.
That completes the list. All 25 now run on the core engine.
Fixing this one matters beyond the migration: update-apps is what drives
unattended updates across every container on a host, and it is the path where
PHS_SILENT was being ignored (#16593). It now gets the engine that honours it.
also port apprise-api, archivebox. Update meilisearch function to support arm64.
invoiceshelf changes are an existing bug.
changes to kasm are required to get docker working, as old docker provided by setup_docker will not work. The --ignore-dep-failures is required as there is a bug in the install script.
Helmet's useDefaults adds upgrade-insecure-requests to the CSP,
which forces browsers to upgrade all HTTP requests to HTTPS.
Since most LXC users access Immich directly via HTTP, this breaks
the web UI completely (CORS errors, spinning logo).
Patch helmet.json after deploy to explicitly null out the directive,
keeping CSP benefits while allowing HTTP access.
Fixes#13597
* fix(immich): use start.sh in service, ensure DB_HOSTNAME in .env
* Bump Immich to v2.6.2 and adjust chown handling
Update Immich release references from v2.6.1 to v2.6.2 in ct/immich.sh and install/immich-install.sh. Replace broad recursive chown -R on the install dir with a safer approach that avoids recursing into the upload directory (which may be a mounted volume with restricted permissions): set ownership on the install dir itself, chown each top-level entry except 'upload', and attempt to chown the upload path while ignoring errors. Also adjust ordering for /var/log/immich chown to avoid permission issues when enabling services.