I'm trying to install SparkBox on Arch Linux. It's installing as normal but it's not starting up a Setup Wizard by default. Do I have to manually enter a command line to start a Setup Wizard to get SparkBox working? curl -fsSL https://get.tomsparkbox.com/install.sh | sudo bash / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || The easiest, most user-friendly self-hosting stack anywhere. Created by Tom Spark | youtube.com/@TomSparkReviews [SparkBox] Unsupported NAS detected. SparkBox officially supports UGREEN NASync. [SparkBox] Continuing anyway — it may work, but support is limited. [SparkBox] NAS detected: generic [SparkBox] Running in NAS mode (generic) [SparkBox] NAS users: keep internet access ON during install. [SparkBox] SparkBox needs the internet to: [SparkBox] 1. Pull Docker images during install [SparkBox] 2. Activate your free personal-use license key (update alerts) [SparkBox] Re-block outbound internet only AFTER you've logged in, registered [SparkBox] your license, and finished the setup wizard. [SparkBox] Full details: https://tomsparkbox.com/docs.html [SparkBox] Network profile: nas (NAS detected: generic) [SparkBox] Suggested install directory: /opt/sparkbox [SparkBox] Data directory (media/photos/books/manga): /opt/sparkbox/data [SparkBox] Your data directory (/opt/sparkbox/data) is on the SAME DISK as the operating system. [SparkBox] On a NAS the OS disk is usually small -- media/photos will fill it quickly. [SparkBox] If your storage pool lives elsewhere (e.g. /volume1), set SBDATADIR to a [SparkBox] folder on it and re-run, or edit SBDATADIR in /opt/sparkbox/.env later [SparkBox] followed by 'sudo sparkbox up' (SparkBox migrates data automatically). [SparkBox] System clock is in sync (0s off Cloudflare's reference) [SparkBox] Detected: Arch Linux (NAS mode - this is fine) [SparkBox] NAS mode: skipping system package installation. [SparkBox] Docker already installed: Docker version 29.9.2, build a82e528901 [SparkBox] Docker Compose: 5.6.0 ============================================================ PREFLIGHT — here's what I found on this machine ============================================================ System: Arch Linux Hardware: NAS (generic) Memory: 63958 MB Free disk: 1732 GB at /opt Install to: /opt/sparkbox Timezone: America/NewYork Clock: in sync (0s off reference) Mode: fresh install ============================================================ [SparkBox] Downloading SparkBox... [SparkBox] Verifying release integrity... [SparkBox] SHA256 digest verified [SparkBox] ed25519 signature verified [SparkBox] SparkBox downloaded to /opt/sparkbox [SparkBox] SparkBox installed to /opt/sparkbox [SparkBox] NAS mode: skipping firewall configuration. [SparkBox] Configure port forwarding through your NAS or router admin panel. [SparkBox] Non-interactive install detected (piped from curl). Skipping wizard. [SparkBox] Bringing up core services so the dashboard is reachable...
17 replies
Chris wrote:
No command is needed to start the setup wizard. Because the installer was piped from curl, it skips the terminal wizard on purpose, and the setup wizard runs in your browser instead. Next step: from another device on the same network, open http://YOUR-BOX-IP:8443 (use the box's LAN address). The first page asks for the one-time bootstrap token printed at the end of the install. If you did not keep it, run sudo sparkbox bootstrap-token on the box to print it again. Could you tell me whether the install finished and whether that page loads? The paste stops at "Bringing up core services", so I can't tell yet.
ABOhiccups wrote:
I did not get bootstrap-token from Terminal and SparkBox is not working.
Chris wrote:
Sorry the install left you stuck. The bootstrap token is printed at the end of a successful install, and the paste you shared stops at "Bringing up core services", so the install may still be running or may have stopped there. Once the install terminal is back at a normal prompt, run this on the box: sudo /opt/sparkbox/sparkbox bootstrap-token If it prints a token, open http://YOUR-BOX-IP:8443 from another device on your home network and paste it there. Please don't post the token here. If it prints a message instead, paste that message in your reply, since it contains no secrets. The installer also labelled this Arch machine a "generic NAS" and mentioned port forwarding. That is a detection mistake on our side, and you don't need port forwarding to reach the dashboard from your own network. We've logged it.
ABOhiccups wrote:
I got Bootstrap Token by using a command line you gave me. SparkBox is not working for me. I enter my local IP Address with 8443 port number. The page is not loading.
Chris wrote:
Thanks for trying the token step. Getting the token means the install wrote its settings, but the install paste stopped at "Bringing up core services", so the dashboard container may not be running yet. Please run these three read-only checks on the Arch box and paste the results here (no tokens or passwords): 1. sudo docker ps --filter name=sb-dashboard Expected: a line for sb-dashboard showing Up ... (healthy) or Up ... (health: starting). If nothing is listed, the dashboard container is not running. 2. curl -s -o /dev/null -w '%{httpcode}' http://127.0.0.1:8443/api/auth/status Expected: 200. Run this on the box itself. 3. Tell me what your browser shows when you open http://YOUR-BOX-IP:8443 from another device: a timeout, "connection refused", or a page. Stop there and paste the results. If step 1 lists nothing, the next step is to finish starting SparkBox, and I will walk you through it from the output.
ABOhiccups wrote:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Chris wrote:
Thanks for checking. The container list you pasted has no containers in it, so the SparkBox dashboard is not running yet. The install stopped before it finished starting SparkBox, which is why the page does not load. Please run this on the Arch box and wait until it returns to a normal prompt (it can take a few minutes): sudo /opt/sparkbox/sparkbox up Then paste two things here, with no tokens or passwords: 1. The last 20 lines of that output. If it ends with a line saying apps are still NOT running, include that line. 2. The output of this command: sudo docker ps -a Once I have those, we will check the page at http://YOUR-BOX-IP:8443 from another device on your network.
ABOhiccups wrote:
It stuck at the last part. / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.7.3 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Environment: NAS (generic) [INFO] Starting SparkBox... [INFO] Active modules: core dashboard [INFO] Creating sbproxy network (172.20.0.0/24)... [WARN] This box had no reboot self-heal installed (it predates the feature, and 'update' never adds it) — installing it now. [OK] Boot self-heal enabled (sparkbox-boot.service runs 'sparkbox up' after every reboot) [INFO] Prepared 4 module config dir(s) for PUID=1000 PGID=1000 [OK] Repaired Actual Budget's TLS certificate (it was incomplete). Your browser will ask you to accept it once more. [INFO] Fetching images for module: core [+] pull 54/54 ✔ Image ghcr.io/gethomepage/homepage:v2.6.0 Pulled 3.6s ✔ Image jc21/nginx-proxy-manager:2.16.0 Pulled 10.3s ✔ Image portainer/portainer-ce:2.45.2 Pulled 4.7s [INFO] Fetching images for module: dashboard WARN[0000] The "SBADMINPASSWORDHASH" variable is not set. Defaulting to a blank string. [+] pull 1/1 ✔ sparkbox-dashboard Skipped No image to be pulled 0.0s [OK] All required images present. [INFO] Minted NPMADMINPASSWORD for module 'core' (stored in .env) [+] up 3/3 ✔ Container sb-portainer Started 0.6s ✔ Container sb-homepage Started 0.8s ✔ Container sb-npm Started 0.7s WARN[0000] The "SBADMINPASSWORDHASH" variable is not set. Defaulting to a blank string. [+] Building 977.0s (6/13) = [internal] load local bake definitions 0.0s = = reading from stdin 548B 0.0s = [internal] load build definition from Dockerfile 0.0s = = transferring dockerfile: 3.99kB 0.0s = [internal] load metadata for docker.io/library/node:20-alpine 0.5s = [internal] load .dockerignore 0.0s = = transferring context: 129B 0.0s = [1/8] FROM docker.io/library/node:20-alpine@sha256:fb4cd12c85ee03686f6af5362a0b0d56d50c58a04632e6c0fb8363f609372293 1.1s = = resolve docker.io/library/node:20-alpine@sha256:fb4cd12c85ee03686f6af5362a0b0d56d50c58a04632e6c0fb8363f609372293 0.0s = = sha256:fff4e2c1b189bf87d63ad8bd07f7f4eb288d6f2b6a07a8bb44c60e8c075d2096 445B / 445B 0.0s = = sha256:b2cbbfe903b0821005780971ddc5892edcc4ce74c5a48d82e1d2b382edac3122 1.26MB / 1.26MB 0.1s = = sha256:6a0ac1617861a677b045b7ff88545213ec31c0ff08763195a70a4a5adda577bb 3.86MB / 3.86MB 0.1s = = extracting sha256:6a0ac1617861a677b045b7ff88545213ec31c0ff08763195a70a4a5adda577bb 0.0s = = sha256:4feea04c154301db6f4a496efa397b3db96603b1c009c797cfdde77bea8b3287 43.23MB / 43.23MB 0.5s = = extracting sha256:4feea04c154301db6f4a496efa397b3db96603b1c009c797cfdde77bea8b3287 0.5s = = extracting sha256:b2cbbfe903b0821005780971ddc5892edcc4ce74c5a48d82e1d2b382edac3122 0.0s = = extracting sha256:fff4e2c1b189bf87d63ad8bd07f7f4eb288d6f2b6a07a8bb44c60e8c075d2096 0.0s = [internal] load build context 0.0s = = transferring context: 10.01MB 0.0s = [2/8] RUN for i in 1 2 3; do apk add --no-cache bash docker-cli docker-cli-compose curl coreutils su-exec tar openssl && break; if [ "$i" = "3" ]; then echo "apk add failed 3 times — the box's Docker DNS likely can't reach dl-cdn.alpinelinux.org" &2; exit 975.4s
Chris wrote:
Sorry it is still stuck. Thanks for pasting the whole output. The paste shows the core apps started, then the dashboard image build reached its package-download step and ran for about 16 minutes before the build stopped. The paste ends before the line that names the error, so the dashboard was never started, which is why the page will not load. I think the cause is that the build step inside Docker cannot reach the Alpine package server, even though the Arch machine itself is online. These two read-only checks will confirm or rule that out. Please run them on the Arch box and paste the results (no tokens or passwords): 1. Test the same package path the build uses: sudo docker run --rm node:20-alpine sh -c 'timeout 120 apk update /dev/null 2&1 && echo APKOK || echo APKFAILED' Expected: APKOK. It can take up to two minutes. 2. Test the Arch machine itself: ping -c 3 dl-cdn.alpinelinux.org Expected: three lines that begin "64 bytes from". If nothing comes back, paste whatever it prints. If you can scroll back in the terminal, also paste the line that starts with ERROR or "apk add failed"; it names the failure. Please do not change Docker, the firewall or the install yet. Stop after these checks, paste the results, and I will give you the next step from them.
ABOhiccups wrote:
Unable to find image 'node:20-alpine' locally 20-alpine: Pulling from library/node Digest: sha256:fb4cd12c85ee03686f6af5362a0b0d56d50c58a04632e6c0fb8363f609372293 Status: Downloaded newer image for node:20-alpine APKOK PING dualstack.j.sni.global.fastly.net (151.101.2.132) 56(84) bytes of data. 64 bytes from 151.101.2.132: icmpseq=1 ttl=56 time=5.23 ms 64 bytes from 151.101.2.132: icmpseq=2 ttl=56 time=4.23 ms 64 bytes from 151.101.2.132: icmpseq=3 ttl=56 time=6.09 ms --- dualstack.j.sni.global.fastly.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.231/5.182/6.089/0.759 ms
Chris wrote:
Thanks for running those two checks. I was wrong to say the Docker build could not reach the Alpine package server. Your checks show it can, so that was a guess, and I should have labelled it as one. What the earlier output shows is the dashboard image build sitting in its package download step for about 16 minutes before it stopped. That step has no time limit on each try, so one stalled download can hold the install for a long time without printing the error. I can't confirm that is what happened yet, because the paste stops before the error line. Please run this one command on the Arch box and wait until it returns to a normal prompt (it can take several minutes): sudo /opt/sparkbox/sparkbox up If it finishes, open http://YOUR-BOX-IP:8443 from another device on your network. If it stops again, paste the last 20 lines of the output here, with no tokens or passwords. What I told you about the package server has now been corrected in what I work from, so the next person who sees this stall is not sent down the same path.
ABOhiccups wrote:
It still stuck at = [2/8] RUN for i in 1 2 3; do apk add --no-cache bash docker-cli docker-cli-compose curl coreutils su-exec tar openssl && break; if [ "$i" = "3" ]; then echo "apk add failed 3 times — the box's Docker DNS likely can't reach dl-cdn.alpinelinux.org" &2; exit 975.4s
Chris wrote:
I'm sorry this has taken this long. Earlier I guessed that the Docker build could not reach the Alpine package server. Your checks showed it can, so that guess was wrong, and I should not have stated it as the cause. Here is what the paste shows. The dashboard image build's package step ran for about 16 minutes (the 975s timer) and then stopped. The paste ends before the line that names the error, so I can't yet say exactly what it reported. What we know from our side: that package step retries three times, but each try has no time limit. One stalled connection can hold the build for a long time before it fails. This is recorded for the team and is under review. There is no released fix yet, so updating SparkBox will not clear it today, and I don't have a date for one. Next step: once the install terminal is back at a normal prompt, scroll up to the lines near the [2/8] RUN line and paste only the lines that start with ERROR or that mention apk. Those lines contain no passwords or tokens. If the terminal is still busy, wait for it to finish first. The record for this stall says the cause is the package step, not DNS, so the next person who sees it is not sent down the DNS path. The Arch machine being labelled a generic NAS is a separate known mistake. It only changes the messages and skipped steps, and you still don't need port forwarding for your own network.
ABOhiccups wrote:
I installed SparkBox on Ubuntu-Server and I have no issue. It was just Arch Linux side I'm having issue.
Chris wrote:
Thanks, that helps. A clean install on Ubuntu Server means SparkBox itself installs fine, so the stall is most likely specific to this Arch machine. The stall is in the dashboard image build step described above. There is no released fix for it yet, and I don't have a date, so the Arch install may keep stalling until one ships. Next step: once the install terminal is back at a normal prompt, scroll back to the line that starts with ERROR near the [2/8] RUN step and paste only that line. If the terminal is still busy, tell me that instead. That line contains no passwords or tokens.
ABOhiccups wrote:
I've found a fix. Running sudo sparkbox factory-reset fixed the issue.
Chris wrote:
Thanks for trying it and for letting us know. Please don't treat factory-reset as the fix for this stall, and don't suggest it to others. It is a wipe: it removes every app's settings and data folders on the box and the saved state, then runs sparkbox up again. Your .env, backups and /data are kept, but any app settings made after the install are gone. The reset also starts sparkbox up again, which is the step that stalled, so I can't tell from here whether the reset helped or the second pass simply finished. To find out, please send me these, with no tokens or passwords: 1. The last 10 lines of the factory-reset output. If it stops before the line that says the dashboard will load the first-run wizard, paste the last 10 lines anyway. 2. Whether http://YOUR-BOX-IP:8443 loads from another device on your network. If the page loads, we will know the dashboard is up. If it does not, tell me what the browser shows and we will continue from there.