* fix(hyperion): keep service running after container reboot
The packaged hyperion@.service declares "Requisite=network.target" but is
not ordered After=network.target. Inside an LXC the unit's start job can be
evaluated before network.target is active, and because Requisite= is stricter
than Requires= (it does not pull the unit in or wait for it) the job fails
with "Dependency failed", so Hyperion does not start after a reboot.
Add a systemd drop-in that clears Requisite=; ordering is still provided by
the base unit's Wants=/After=network-online.target.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix Hyperion service startup issue in LXC
Remove Requisite from Hyperion service to ensure it starts correctly in LXC environments.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
* 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>
