3 Commits

Author SHA1 Message Date
librelad
7ed8539af7 setup: stop calling the app-data drive "System disk" when it is not
The wizard's Storage step builds its first entry from primaryRoot() — the
app-data root — and labelled it "System disk". On a default install those are
the same drive and the name is honest. Installed with --containers-dir on its
own disk they are not, and the step then showed the DATA drive's size under the
system disk's name while the actual system disk never appeared in the list.

Seen on a matrix case-2 install (apps on a 29.4G test disk, system on a 912G
root): "System disk — 26.7G free of 29.4G".

The generator now reports whether that root is really on the OS disk
(is_os_disk, by st_dev against /), and the wizard labels it from that: "System
disk" when they coincide, otherwise the mount point. The "system" badge stays —
it marks the default location, which is still what it is.

Also add lp-shot --token / --cookie-js. A screenshot answers "does it render";
"does this wizard step work" needs clicking, which needs a real browser, which
needs the session lp-shot already knows how to mint from the stored jwtSecret.
This bug was found that way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 06:35:16 +01:00
librelad
fc92d556f1 dev: harness for the multi-disk install, and make lp-shot follow the roots
The three roots are independently relocatable, and the failures that matter are
the ones where only ONE of them moves: paths are baked into root-owned helpers,
the systemd unit and the CLI wrapper at install time, so anything that resolves
a root at runtime instead works on a default install and points at the wrong
disk on a relocated one. Testing "all default" or "all moved" misses that.

  scripts/dev/lp-testdisk       loopback ext4 disks — a real superblock, its own
                                st_dev and free space, thrown away between runs
  scripts/dev/lp-install-matrix installs across the four root combinations and
                                checks each landed on the intended DEVICE, that
                                the helpers were baked (no __PLACEHOLDER__ left)
                                and that the WebUI answers

First thing the harness turned up: lp-shot hardcoded /libreportal-containers for
both the compose file it reads the published port from and the .auth.json it
signs a session with. On an install whose app data is on another disk it fell
back to a default port and a missing auth file — which looks exactly like a
WebUI that failed to boot. It now reads the baked LP_CONTAINERS_DIR back out of
the CLI wrapper.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 06:24:39 +01:00
librelad
84b027feed chore(dev): vendor lp-shot, excluded from release tarballs
The WebUI screenshot helper CLAUDE.md already tells agents to use only
ever existed on the maintainer's box. Vendoring it means it survives a
machine rebuild and the setup steps are written down.

It does NOT ship: make_release.sh builds with `git archive`, which honours
export-ignore, so scripts/dev joins scripts/release and docs on that list.
Verified — the staged tarball has 1666 files and none under scripts/dev.

Keeping it out of releases is deliberate, not incidental. lp-shot signs
itself a session from the jwtSecret in frontend/.auth.json, which is fine
on a box where you already own that file, and has no business sitting in
a user's install where it would read as a backdoor.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 23:43:35 +01:00