I tried to use TomAI and it told me to post here. I was trying to update and i got error: [SparkBox] Existing SparkBox install found (v1.6.338). Upgrading via atomic rename-swap — .env, state/, and module data are preserved. curl: (23) Failure writing output to destination I tried "df -h /opt/sparkbox" and got "Edgar@DXP4800PRO-484D:~$ df -h /opt/sparkbox Filesystem Size Used Avail Use% Mounted on overlay 107G 9.5G 92G 10% /" I usually have to update spark box with: "curl -sSL https://get.tomsparkbox.com/install.sh | sudo bash" but this time it didnt work. if you need any more information let me know. Thank you for the help.
14 replies
tomspark wrote:
Thanks for the detailed report — that curl error (23) is a write-to-disk failure, which is unusual with 92GB free. Quick things to try first: (1) check if /tmp has space: df /tmp, (2) try the update again with explicit /tmp override: TMPDIR=/opt curl -sSL https://get.tomsparkbox.com/install.sh | sudo bash. If those don't help, we'll dig deeper — flagged this to the team.
pereze94 wrote:
df /temp said: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8071184 1336 8069848 1% /tmp & "TMPDIR=/opt curl -sSL https://get.tomsparkbox.com/install.sh | sudo bash" said 'curl: (23) Failure writing output to destination Edgar@DXP4800PRO-484D:~$ Edgar@DXP4800PRO-484D:~$ df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8071184 1336 8069848 1% /tmp
tomspark wrote:
Thanks for running those diagnostics — the fact that /tmp has plenty of space but the TMPDIR override still fails means this isn't a simple disk issue. I've flagged this to the team for deeper investigation since the standard recovery paths didn't help. In the meantime: is the SparkBox service running normally otherwise (you can check with systemctl status sparkbox)? And did the curl failure happen right at the start of the update, or partway through? Any details help narrow this down fast.
pereze94 wrote:
Yes sparkbox is running fine. It happen partway through i believe. I also tried to run that command and it said : Unit sparkbox.service could not be found
tomspark wrote:
Good catch on running that command — and the fact that the service isn't installed yet tells us the upgrade didn't finish. The overlay filesystem you're running on (unusual for a typical box) might be limiting how curl can write the download during the upgrade. Let me flag this to the team for deeper investigation on overlay mounts — a couple of diagnostic steps might help while we look: (1) can you manually write to /tmp with sudo bash -c 'echo test /tmp/test-write.txt', then cat /tmp/test-write.txt to confirm it worked? (2) check if there are any partial files left behind: ls -lah /opt/sparkbox/ — look for .tar or .tar.gz files that might give a clue about where the download got stuck. Meanwhile we're looking into this.
pereze94 wrote:
Edgar@DXP4800PRO-484D:~$ sudo bash -c 'echo test /tmp/test-write.txt' Edgar@DXP4800PRO-484D:~$ cat /tmp/test-write.txt test Edgar@DXP4800PRO-484D:~$ ls -lah /opt/sparkbox/ total 664K drwxr-xr-x 13 Edgar 1000 4.0K Jul 12 16:44 . drwxr-xr-x 1 root root 4.0K Jul 12 16:44 .. drwxrwxr-x 2 Edgar admin 4.0K Jul 12 16:49 backups -rw-rw-r-- 1 Edgar 1000 6.6K Jul 4 06:39 CONTRIBUTING.md -rw-rw-r-- 1 Edgar 1000 11K Jul 4 06:39 CREDITS.md drwxrwxr-x 4 Edgar 1000 4.0K Jul 12 16:23 dashboard drwxr-xr-x 3 root root 4.0K May 8 21:31 data drwxrwxr-x 3 Edgar 1000 4.0K Jul 12 16:23 docs -rw-rw-r-- 1 Edgar admin 3.2K Jun 18 21:44 .env -rw-rw-r-- 1 Edgar 1000 2.5K Jul 4 06:39 .env.example -rw-rw-r-- 1 Edgar 1000 23K Jul 4 06:39 INSTALL.md -rwxr-xr-x 1 Edgar 1000 163K Jul 4 12:13 install.sh drwxrwxr-x 2 Edgar 1000 4.0K Jul 4 11:25 knowledge-private -rw-rw-r-- 1 Edgar 1000 2.2K Jul 4 06:39 LICENSE -rw-rw-r-- 1 Edgar 1000 8 Jul 4 06:39 MINFROMVERSION drwxrwxr-x 47 Edgar admin 4.0K Jul 4 06:39 modules drwxrwxr-x 2 Edgar 1000 4.0K Jul 4 06:39 qa -rw-rw-r-- 1 Edgar 1000 19K Jul 4 06:39 README.md -rw-rw-r-- 1 Edgar 1000 2.8K Jul 4 06:39 RELEASESIGNING.md drwxrwxr-x 2 Edgar 1000 4.0K Jul 12 16:11 scripts -rwxr-xr-x 1 Edgar 1000 358K Jul 12 14:21 sparkbox drwxrwxr-x 8 Edgar admin 4.0K Jul 12 23:34 state drwxrwxr-x 2 Edgar 1000 4.0K Jul 4 06:39 support drwxrwxr-x 2 Edgar 1000 4.0K Jul 4 06:39 templates -rw-r--r-- 1 Edgar 1000 8 Jul 12 16:23 VERSION looks like the test worked. Also i didn't see any .tar/ .tar.gz files
tomspark wrote:
Thanks for running those diagnostics — the fact that manual writes to /tmp work but curl fails with error 23 even when we override TMPDIR to /opt is the real clue. Your overlay filesystem is doing something unusual when curl tries to write. This one's worth a closer look. I've flagged this to the team for deeper investigation. Quick next step: can you run df -T /tmp /opt to show the exact filesystem types? That detail will help us understand whether it's a mount option or permission constraint specific to your setup. You're on the right track — we're digging in on this.
pereze94 wrote:
Filesystem Type 1K-blocks Used Available Use% Mounted on tmpfs tmpfs 8071184 1352 8069832 1% /tmp overlay overlay 111896192 9925616 96240412 10% /
tomspark wrote:
Thanks for grabbing that — those numbers look healthy, so your disk isn't the problem. That curl error can actually hide the real message, so let's take it out of the picture. Run this — it saves the installer to a file first, then runs it: curl -sSL https://get.tomsparkbox.com/install.sh -o /tmp/sb-install.sh && sudo bash /tmp/sb-install.sh If all goes well you'll see the update run through and finish with a success message. If it stops again, paste the last 10 lines or so here — they'll show exactly where it got stuck.
pereze94 wrote:
[SparkBox] Full details: https://tomsparkbox.com/docs.html [SparkBox] Network profile: nas (NAS detected: ugreen) [SparkBox] Suggested install directory: /opt/sparkbox [SparkBox] Data directory (media/photos/books/manga): /volume1/sparkbox-data [SparkBox] System clock is in sync (265s off Cloudflare's reference) [SparkBox] Detected: Debian GNU/Linux 12 (bookworm) [SparkBox] NAS mode: skipping system package installation. [SparkBox] Docker already installed: Docker version 29.4.3, build 055a478 [SparkBox] Docker Compose: 5.1.3 [SparkBox] Existing SparkBox install found (v1.6.338). Upgrading via atomic rena me-swap — .env, state/, and module data are preserved.
tomspark wrote:
That paste was exactly what we needed — we found it, and it's our bug, not your box. The update stops right at a check we recently added to the installer: just after that last line you see, it peeks at which network ports are busy before going further. On a NAS with a lot running, that check can crash the installer quietly — no error, it just stops, which matches what you're seeing exactly. Your files and settings are untouched. Until the fixed installer ships, this should get you updated — stop SparkBox first, then run the saved installer: sudo sparkbox down && sudo bash /tmp/sb-install.sh Everything starts back up on its own at the end. If it still stops, paste the last few lines again and I'll keep digging.
pereze94 wrote:
looks like it worked here is the last few lines [SparkBox] Boot self-heal enabled (sparkbox-boot.service runs 'sparkbox up' after every reboot) ^C [SparkBox] SparkBox installed to /opt/sparkbox [SparkBox] Upgrade complete. Dashboard preserved its previous login. [SparkBox] Your ship is ready — welcome to the Fleet.
tomspark wrote:
That's the finish line — "Upgrade complete" means the whole update went through and you're on 1.6.344 now, with all your settings and library untouched. Thanks for sticking with the back-and-forth and pasting the output each step — that's exactly what let us pin down the installer bug on our side. A proper fix is in the works so the normal one-line update behaves again; until then, if an update ever stalls the same way, that same save-the-file-then-run trick will get you through. Enjoy!
Chris wrote:
Owed you an update, and it's a good one: Tom shipped that fix today in v1.6.456, built straight from this thread. The cause was where the download got parked. The installer staged the release tarball in /tmp, and on UGOS /tmp is a small RAM-backed disk — so your 92GB free was never the space that mattered. It's also why the TMPDIR override did nothing: sudo strips that variable before the installer ever sees it. It now stages next to /opt/sparkbox instead. The misleading 'check your connection' wording is gone too — a write failure now names the file and the df to run. Your usual one-liner should just work again, no save-the-file trick needed.