* fix(fileflows): install .NET 10 ASP.NET Core Runtime to match current release
FileFlows now ships its server/node binaries targeting .NET 10
(Microsoft.NETCore.App 10.0.0), but the install script still installs the
ASP.NET Core Runtime 8.0. On a fresh install the app therefore cannot start:
You must install or update .NET to run this application.
Framework: 'Microsoft.NETCore.App', version '10.0.0' (x64)
The following frameworks were found:
8.0.28 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
so "dotnet FileFlows.Server.dll --systemd install" fails with exit code 150
(service failed to start) and the container aborts (issue #15686).
Bump the runtime to 10.0 on both branches: aspnetcore-runtime-10.0 from
packages.microsoft.com on amd64 (the same repo and package already used by
igotify, rdtclient and technitiumdns) and dotnet-install --channel 10.0 on
arm64.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(fileflows): ensure current .NET runtime on update too
An existing install set up under an older .NET (e.g. aspnetcore-runtime-8.0)
would download a newer FileFlows on update but keep the old runtime, failing to
start with the same framework-not-found error. Mirror the runtime handling used
by technitiumdns/rdtclient in update_script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
AdventureLog's frontend install runs a bare `pnpm i`. On pnpm v10+, build
scripts of dependencies (esbuild, es5-ext, svelte-preprocess) are ignored by
default and pnpm aborts with ERR_PNPM_IGNORED_BUILDS (exit 1), so the install
never reaches `pnpm build`. The shipped frontend/pnpm-workspace.yaml already
pins esbuild, so those builds are expected to run.
Enable the builds for this app only by appending `dangerouslyAllowAllBuilds:
true` to the frontend's pnpm-workspace.yaml before `pnpm i`, in both the install
and update paths. The change is guarded so it is not duplicated on re-run, and
it is scoped to AdventureLog (which ships no onlyBuiltDependencies) to avoid the
global config conflict that a repo-wide setting would cause.
Fixes#15670
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
When the optional Unbound install is chosen with DoT forwarding, the script
truncated (>) /etc/unbound/unbound.conf.d/pi-hole.conf and rewrote it starting
with an indented "tls-cert-bundle:" option that has no "server:" section header.
unbound-checkconf rejects this ("syntax error, is there no section start"), so
"systemctl restart unbound" exits 1 and the install aborts (line 153). The
overwrite also dropped the interface/port 5335 settings Pi-hole forwards to.
Append (>>) the DoT additions to the existing recursive server block instead,
under a proper "server:" section (unbound merges multiple server: clauses), so
the tls-cert-bundle and forward-zone are valid and the resolver keeps listening
on 127.0.0.1:5335. Recursive (non-DoT) mode is unchanged.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Ensure cleanup runs from `/opt/babybuddy` before deleting old files, add `--` to the removal command for safer argument handling, and run `manage.py makemigrations` before `migrate` so database updates are applied reliably during upgrades.
The completion message previously pointed to the bare host:port,
which serves the proxy API rather than the admin UI. Provider
authentication happens at /management.html.
Co-authored-by: root <root@paperclip.pilz.dev>
Replace the destructive multi-select container update block with a
proper per-container Y/N workflow:
- Unattended / non-interactive (DOCKER_NONINTERACTIVE=1 or no tty):
skip silently -- no docker pulls, no prompts.
- Interactive: stop_spinner() before any prompt to keep the terminal
clean, then for each container with a newer image:
Compose-managed → prompt Y/N (auto-no after 60 s)
→ on Y: docker compose pull <service> &&
docker compose up -d <service>
Standalone run → prompt Y/N (auto-no after 60 s)
→ on Y: docker pull only; no stop/rm;
user is told to recreate manually
- portainer / portainer_agent are excluded (handled earlier in
setup_docker)
The old code always stopped and removed the container without
recreating it, leaving users with a destroyed service. Standalone
containers without a Compose project can never be auto-recreated
safely, so only the image is pulled.
Fixes#15601
The 'Interactive Container Update Check' block scanned ALL running
Docker containers, pulled their images, then stopped and removed them
with only a message asking the user to manually recreate them. This
is destructive and outside the scope of the Docker LXC update script,
which is responsible for updating the Docker engine itself and the
Portainer / Portainer-Agent containers that this script originally
installed.
Removes the entire block. Updates now cover:
- OS packages (apt)
- Docker engine (via setup_docker / repo)
- Portainer CE (if installed by this script)
- Portainer Agent (if installed by this script)
Self-hosted / user-managed containers are intentionally left alone.
Fixes#15601
community-scripts-pr-app[bot]