* fix(romm): snapshot Redis hourly like the upstream image
Redis' default save policy (3600 1 300 100 60 10000) rewrites the whole dump.rdb every 5 minutes on an idle RomM, because the RQ workers and scheduler change keys constantly. With the Switch TitleDB and PS2 serial caches the dump is ~50 MB, so an idle container writes ~14 GB/day. Upstream fixed this for the Docker image (rommapp/romm#3983, REDIS_SAVE_POLICY default "3600 1"), but that lives in docker/init_scripts/init, which the LXC install never runs. Apply the same policy on install and, for existing containers, on update unless a save policy is already set.
* Update ct/romm.sh
* Update install/romm-install.sh
---------
Co-authored-by: Michel Roegl-Brunner <73236783+michelroegl-brunner@users.noreply.github.com>
linkding stores them in data/favicons and data/previews and upstream maps both
under /static next to the collected assets, with a sandbox CSP. The nginx site
only aliased the collected assets, so every downloaded image answered 404; the
update rewrites that block even without a new release.
Upstream's nginx.conf gained a resolver ${NGINX_RESOLVER} line that its Docker
entrypoint fills from /etc/resolv.conf; the script substitutes a fixed list of
placeholders, so the literal variable reached nginx and the config test failed.
Take the nameservers from resolv.conf the same way.
* fix: bump aurral Node.js requirement from 22 to 26
Upstream aurral now requires Node 26.x (engines: "26.8.x" in v2.10.0),
causing npm ci to fail with EBADENGINE when the install script sets up
Node 22.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: bypass npm engine-strict check for aurral build
aurral's .npmrc sets engine-strict=true and pins an exact node patch
(26.8.x), which NodeSource can never satisfy since it only ships the
latest patch per major (currently 26.10.0). Disable engine-strict for
the build, matching the ignore-engines workaround already used for
yarn-based apps in this repo (dashy, monica, excalidraw,
elementsynapse).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
On the run in which steamcmd replaces itself, the app_update that follows fails
with 'Missing configuration', and the same command succeeds once it runs again.
A login-only run first takes that self-update out of the install and update.
The noavx2 requirements pin numpy 1.23.5 and onnx 1.14.1, neither of which ships
a cp312 wheel, so on 3.12 uv built them from source: numpy fails without
distutils and onnx without cmake. Every noavx2 pin has a 3.11 wheel.
@lobehub/ui 5.50.0 dropped NeuralNetworkLoading, and LobeHub 2.2.18 still imports
it through a ^5.47.0 range with lockfile: false, so every fresh build now fails.
Upstream moved off it on main; the pin only applies while package.json still asks
for a 5.4x range, so it stops on its own with the next stable release.
The repo also publishes web-clipper-v* releases, and whenever upstream marked one
of those as latest the update offered to replace the server with the browser
extension. A v prefix makes core pick the newest stable server release itself
instead of trusting that marking.
2.16.0 ships production.conf only as a template that its s6 prepare step renders,
so installs outside Docker never listened on 81; render it on install, on update
while keeping a custom admin port, and on update for containers already stuck on
2.16.0. Certbot's upgrade died on a dist-info without RECORD, which pip's own
--ignore-installed hint does not clear, so drop such records before upgrading.
RomM 5.3.0 dropped rq-scheduler (rommapp/romm@4e5921727), so
romm-scheduler.service fails with 203/EXEC on a missing
.venv/bin/rqscheduler. The same release moved scans to their own
"scans" queue (rommapp/romm@3593d2398), which the LXC worker never
listened on, so scans queued but never ran.
Match upstream's docker init: the scheduler service runs
`rq cron tasks.cron_config`, both workers run with --with-scheduler
so delayed jobs (watcher rescans) are released, and a new
romm-scan-worker.service consumes the scans queue.
The update script migrates existing units when romm-scheduler.service
still references rqscheduler. It runs before the release check, so
installs already on 5.3.x get repaired too.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Upstream renamed OBSIDIAN_VERSION in its Dockerfile to IGNIS_OBSIDIAN_PIN, so the
grep matched nothing - and under pipefail the assignment itself aborts, which is why
the fallback on the next line never ran. The tag already carries the pairing
(0.8.13+obsidian.1.13.7), so read it there and keep both Dockerfile keys as a
fallback.
* Docker-LXC: remove Portainer installation from install
Removed Portainer installation prompts and related code.
* Remove Portainer installation instructions from docker.sh
Removed instructions for installing Portainer as an addon.
* scanopy: use prebuilt server binary, relax release profile for generate-fixtures
* scanopy: drop unneeded rust build, use committed UI fixtures
* scanopy: restore generate-fixtures build, ui/src/lib/data is gitignored and incomplete
* scanopy: serve the UI from the binary, drop the source build
Upstream confirmed in scanopy/scanopy#698 that scanopy-server-linux-*
has carried the built UI since v0.17.13, fixtures and service logos
included, served on the same port as the API. The release notes never
said so, which is why we kept building it.
That removes the source tarball, the Rust toolchain and
generate-fixtures, Node with npm ci and npm run build, and
SCANOPY_WEB_EXTERNAL_PATH. With the variable set to a directory that no
longer has an index.html, v0.17.14 and earlier refuse to start, so the
update deletes the line rather than leaving it. build-essential,
libssl-dev and pkg-config go too: the release binary is static-pie with
no INTERP segment, so it has no runtime library dependencies.
/opt/scanopy stays, now only for .env and oidc.toml, and the unit's
WorkingDirectory follows it out of the removed backend directory. Since
nothing wipes that directory any more, the config survives an update on
its own, which is the report upstream passed on of an update coming
back without SCANOPY_WEB_EXTERNAL_PATH and the server starting API-only.
The update keeps the running binary until the new one answers
/api/health and puts it back if it does not, so a bad release leaves a
working server instead of a stopped one.
check_for_gh_release now keys on scanopy-server, matching the version
file the binary deploy writes; the Scanopy key belonged to the tarball
that is gone. Existing containers run one extra update, then agree.
* Refactor scanopy-install.sh for server setup
Updated installation script to configure Scanopy server and removed daemon configuration section.
* Update service names from 'scanopy-server' to 'Scanopy'
* Fix case sensitivity in fetch_and_deploy_gh_release
* scanopy: make the rollback restore the whole old setup
The health check put the previous binary back but nothing else, and the
source tree it needs was already gone by then: the update deleted
/opt/scanopy/ui before starting the new server, and removed
SCANOPY_WEB_EXTERNAL_PATH from the env at the same time. A failed
health check therefore left the old binary running without the UI it
serves from disk, so the rollback produced an API-only server.
Back up the env file and the unit alongside the binary, restore all
three when the check fails, and delete the source tree only once the
new server has answered. Nothing the old version needs is removed
before the new one has proven itself.
* scanopy: name the deployed binary what the unit starts
singlefile mode writes the asset to <target>/<app name>:
local target_file="$app"
[[ "${USE_ORIGINAL_FILENAME:-false}" == "true" ]] && target_file="$filename"
so with the app renamed to Scanopy the binary lands at /usr/bin/Scanopy
while the unit starts /usr/bin/scanopy-server, and the service never
comes up on a fresh install. Rename it after the deploy, the same way
the daemon block already renames "Scanopy Daemon".
Keeping the app name is what matters here: it is also the version file
(~/.scanopy), and changing it would make every existing container
report an update it does not need.
* 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.
* Let uv see the project before syncing it
uv refuses to run when a project pins a required-version it does not
match, in either direction: RomM pins ==0.12.13, which fails against
both the 0.10.3 a container was built with and the 0.12.17 latest
installs.
UV_PROJECT_DIR points setup_uv at the project so it reads that pin. It
is a prefix like PYTHON_VERSION and UV_VERSION, and the call sits
directly under fetch_and_deploy: the project is on disk by then, and
the deploy has closed its message block, which setup_uv needs since it
opens one of its own. That is also the only call needed - nothing
between the old early call and the deploy uses uv or Python, so the two
collapse into one.
Two things found along the way:
UV_PYTHON was set as a command prefix on setup_uv in 14 places. setup_uv
reads PYTHON_VERSION, never UV_PYTHON, and a prefix assignment does not
outlive the call, so those pins did nothing. They now use
PYTHON_VERSION, which installs the interpreter they were asking for.
Five update scripts had no setup_uv at all while their install
counterpart pinned a Python version. They now carry the same pin.
immich is left out: it runs uv through sudo -u inside a retry loop.
* yubal: drop the uv 0.7.19 pin
The pin came in with the script and was never explained. uv 0.7.19 is
from 2025-07-02; yubal's uv.lock has carried revision 3 since at least
2025-12-27, and older uv refuses a newer lockfile revision. The script
runs uv sync --frozen, so there is no fallback.
yubal declares no required-version of its own, so latest is what it
gets - and if it ever pins one, that pin is now honoured.
The update script doesn't run `php artisan storage:link`, so the symlink at `public/storage` is left pointing at the old release path after an update. As a result, uploaded images 404 in the frontend until the link is recreated by hand.
This change runs `storage:link` after the release is swapped in, to ensure that the storage path is symlinked correctly.
update_script() compared the upstream tag against /opt/${APP}_version.txt but
never wrote it back, so the stored version stayed at whatever the installer
wrote. Every subsequent run took the update branch, wiping the web root and
re-downloading the full release archive even with no new upstream release.
Write the tag after a successful update, matching what the installer already
does at install/alpine-it-tools-install.sh:42.
Closes#17420
Umami 3.4.0 pins engines.pnpm to 12.3.4. update_script() never
refreshed pnpm, so containers installed with pnpm < 12 fail at
pnpm install with ERR_PNPM_UNSUPPORTED_ENGINE after the service was
already stopped and the old release replaced.
Read engines.pnpm from the deployed package.json and pass it to
setup_nodejs (same approach as ct/seerr.sh), falling back to latest.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* suggestarr: keep the data where the app actually reads it
The env file sets CONFIG_DIR=/opt/suggestarr_data and the service passes
it through, but SuggestArr never reads that variable. Its database
manager builds the path from the application directory:
DB_PATH = os.path.join(BASE_DIR, 'config', 'config_files', 'requests.db')
so config.yaml, requests.db and secret.key live under /opt/suggestarr,
which the update wipes with CLEAN_INSTALL. Every update came back as a
fresh install.
Make config/config_files a symlink to /opt/suggestarr_data and lay it
down again after each deploy, since the deploy replaces it with a real
directory. Existing installs have their files copied across first, with
cp -an so anything already in the data directory wins.
CONFIG_DIR stays in the env file: it is inert today and costs nothing if
upstream starts reading it.
* suggestarr: let a failed migration stop the update
The || true was wrong and the review caught it. CLEAN_INSTALL wipes
/opt/suggestarr right after this copy, so swallowing a failure here
means the source is deleted with nothing carried across.
The guard was not even doing anything: cp -an exits 0 when it skips a
file that already exists in the target, which is the only case that
looked like it needed one. It only returns non-zero on a real failure,
which is exactly when the update has to stop - and it now stops before
the deploy, with the original data still in place.
cp -an, target file exists -> exit 0, continues
cp -an, source missing -> exit 1, ERR trap, aborts before deploy
2>/dev/null goes as well, so the reason is visible.
* refactor: streamline OxiCloud installation process by using prebuilt binaries
* oxicloud: take the prebuilt binary in the update too
Upstream now attaches musl tarballs to every release (AtalayaLabs/
OxiCloud#533), so the update no longer has to install a Rust toolchain
and Node and compile for up to 35 minutes. That compile is also what
broke #16216: a release whose source did not build left users with a
failed install and no way forward.
The tarball carries one top-level directory, which the deploy helper
strips, so the binary lands at /opt/oxicloud/oxicloud. The frontend is
baked into it, so the SPA build and OXICLOUD_STATIC_PATH both go; the
variable is commented out rather than removed, since a stale ./static
path would otherwise point at a directory that no longer exists.
migrate-nfc-filenames is gone as a separate binary - it is now a
subcommand, oxicloud migrate nfc-filenames - so the update removes the
old one. ffmpeg replaces build-essential: the server forks it for video
thumbnails and it is the one runtime dependency the musl build still
needs from the system.
Defaults drop to 2 CPU and 2048 MB, which were sized for the compile.
* oxicloud: install ffmpeg on update as well
The install gained it, the update did not, so a container created before
this change would never get it. The musl binary forks ffmpeg for video
thumbnails; without it that one feature stays silently unavailable.
Tin Sever