On Linux, the ~/bin/quak that make install builds starts only while one particular path in the nix store exists. The README's cron setup depends on that binary.
Steps
On Linux with nix, run make install, as "Running the backup from cron" says.
Run readelf -l ~/bin/quak | grep interpreter.
Copy the binary into a stock Debian container (for example postgres:15, no /nix) and run quak --version.
What happened
The program interpreter is /nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/ld-linux-x86-64.so.2. That is the glibc of the bun that nix-shell -p bun provides. bun build --compile copies bun's own executable, so the binary inherits nix's loader.
exec /quak: no such file or directory.
Why it matters: nix-shell -p creates no garbage-collection root. Once that glibc is no longer referenced, for example after a nixpkgs update, nix-collect-garbage deletes it. From then on every cron run fails with a "not found" error although ~/bin/quak is there, and no backup runs. Not checked: an actual garbage collection; on the test host, the user's own nix profile still holds that glibc.
What should happen
readelf -l ~/bin/quak names the system loader, /lib64/ld-linux-x86-64.so.2 on x86-64.
The binary runs on a glibc Linux without /nix.
One way, tested: bun build --compile --target=bun-linux-x64-baseline downloads bun's own release build and produced a binary with the system loader that runs on Debian without nix. A --target equal to the host's (bun-linux-x64) reuses nix's bun and does not help. bun caches that download under ~/.bun.
Model: opus-5-5
On Linux, the `~/bin/quak` that `make install` builds starts only while one particular path in the nix store exists. The README's cron setup depends on that binary.
## Steps
1. On Linux with nix, run `make install`, as "Running the backup from cron" says.
2. Run `readelf -l ~/bin/quak | grep interpreter`.
3. Copy the binary into a stock Debian container (for example `postgres:15`, no `/nix`) and run `quak --version`.
## What happened
2. The program interpreter is `/nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/ld-linux-x86-64.so.2`. That is the glibc of the bun that `nix-shell -p bun` provides. `bun build --compile` copies bun's own executable, so the binary inherits nix's loader.
3. `exec /quak: no such file or directory`.
Why it matters: `nix-shell -p` creates no garbage-collection root. Once that glibc is no longer referenced, for example after a nixpkgs update, `nix-collect-garbage` deletes it. From then on every cron run fails with a "not found" error although `~/bin/quak` is there, and no backup runs. Not checked: an actual garbage collection; on the test host, the user's own nix profile still holds that glibc.
## What should happen
- `readelf -l ~/bin/quak` names the system loader, `/lib64/ld-linux-x86-64.so.2` on x86-64.
- The binary runs on a glibc Linux without `/nix`.
One way, tested: `bun build --compile --target=bun-linux-x64-baseline` downloads bun's own release build and produced a binary with the system loader that runs on Debian without nix. A `--target` equal to the host's (`bun-linux-x64`) reuses nix's bun and does not help. bun caches that download under `~/.bun`.
Model: opus-5-5
clawbot
self-assigned this 2026-11-11 21:22:24 +01:00
PR: #248, branch issue-240-system-loader. On Linux x86-64, make build-bin builds from bun's downloaded release build, so ~/bin/quak uses the system loader. Linux on other architectures is now refused with an error (judgement call, explained in the PR).
Model: opus-5-5
PR: https://git.eeqj.de/sneak/quak/pulls/248, branch `issue-240-system-loader`. On Linux x86-64, `make build-bin` builds from bun's downloaded release build, so `~/bin/quak` uses the system loader. Linux on other architectures is now refused with an error (judgement call, explained in the PR).
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On Linux, the
~/bin/quakthatmake installbuilds starts only while one particular path in the nix store exists. The README's cron setup depends on that binary.Steps
make install, as "Running the backup from cron" says.readelf -l ~/bin/quak | grep interpreter.postgres:15, no/nix) and runquak --version.What happened
/nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/ld-linux-x86-64.so.2. That is the glibc of the bun thatnix-shell -p bunprovides.bun build --compilecopies bun's own executable, so the binary inherits nix's loader.exec /quak: no such file or directory.Why it matters:
nix-shell -pcreates no garbage-collection root. Once that glibc is no longer referenced, for example after a nixpkgs update,nix-collect-garbagedeletes it. From then on every cron run fails with a "not found" error although~/bin/quakis there, and no backup runs. Not checked: an actual garbage collection; on the test host, the user's own nix profile still holds that glibc.What should happen
readelf -l ~/bin/quaknames the system loader,/lib64/ld-linux-x86-64.so.2on x86-64./nix.One way, tested:
bun build --compile --target=bun-linux-x64-baselinedownloads bun's own release build and produced a binary with the system loader that runs on Debian without nix. A--targetequal to the host's (bun-linux-x64) reuses nix's bun and does not help. bun caches that download under~/.bun.Model: opus-5-5
PR: #248, branch
issue-240-system-loader. On Linux x86-64,make build-binbuilds from bun's downloaded release build, so~/bin/quakuses the system loader. Linux on other architectures is now refused with an error (judgement call, explained in the PR).Model: opus-5-5