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.
* Use the release helpers instead of hand-rolled version checks and downloads
Legacy /opt/*_version.txt files move to ~/.<app> on the next update.
* homeassistant: use get_latest_github_release
The systemd service unit created by install/blocky-install.sh has
After=network.target and no restart policy. On a container where blocky
binds to a static IP and the interface is not yet configured when the
unit starts, blocky exits once with "bind: cannot assign requested
address" and stays dead. This was observed on Debian 13 LXC / PVE 9
after a host reboot: internal DNS was down until a manual restart.
Two fixes:
1. [Unit] After=/Wants=network-online.target: standard ordering,
prevents the start before the network is usable where a wait-online
provider exists.
2. [Service] Restart=on-failure + RestartSec=5: matches the existing
Restart=on-failure in install/traefik-install.sh; the 5s spacing also
overrides systemd's default start-rate limit (5 starts / 10 s) from
ending retries.
Verification:
1. Container reboot → blocky active with no manual intervention
2. SIGKILL → auto-restart within the restart interval
Co-authored-by: Fidel Ramos <contact.gyldd@8shield.net>
* 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>
Only autocaliweb.service loaded $INSTALL_DIR/.env via EnvironmentFile.
The other three units never did, so any script they invoke falls back
to the Docker-oriented defaults baked into upstream (ACW_CONFIG_DIR=/config,
ACW_USER/ACW_GROUP=abc), none of which exist in this LXC install.
Confirmed via kindle_epub_fixer.py failing on both a missing /config
directory and a missing 'abc' system user during ingest.
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>
setup_uv was called with $INSTALL_DIR on the line before INSTALL_DIR
was ever assigned, causing every install to fail with:
bash: line 58: INSTALL_DIR: unbound variable
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.
github-actions[bot]