When update or install.sh fails and there's a terminal, ask whether to
send its log to the CoreDesktop team, with the option of reading exactly
what would be sent first. Nothing is sent without a yes, and nothing is
asked without a terminal. The new report command sends a log later
(report, report FILE) or shows what would be sent (report --view).
Before sending, the log is cleaned of terminal codes, and the home
folder, user name, host name, email addresses, IPv4 addresses and
Tailscale names are replaced. CoreDesktop's version, the kernel's, the
failed steps and sibling versions go along with it. The request format
the receiver on federated.sh implements is described at the top of
report.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each run's output now goes to ~/.local/state/coredesktop/logs/, so what
failed can be read after the terminal is gone. In a terminal, update runs
itself under script(1), so everything it runs still sees a terminal, then
strips color codes and progress redraws from the log; otherwise it uses
tee. install.sh, usually piped into bash, uses tee, and runs configure
straight on the terminal, outside the log. Both name the log when
something fails. 95-cleanup.sh keeps the newest 10 update logs and 3
install logs.
The sudo keepalive loops no longer share the logged output, so their
sleep can't hold the log open after the run ends.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
013acac's update (in use 2026-08-14 to 2026-10-19) copies the new update
over itself with sudo cp while bash is still reading it, so bash reads on
from byte 1484 of the new file: today, the middle of the logo, and the
update dies with a syntax error. Put a line at exactly that byte that
execs the new update, in a here-document a normal run skips. Found by
30-upgrade-from-baseline at ca658dc; the test replays 013acac's update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Since a65f07c ran each hook in a subshell, a hook that does its work as
it's sourced (12-migrations, 15-services, 20-aur, 30-flatpak and others)
had its failure lost: the run_update check after source left the
subshell's status at 0, so update said "Done." and exited 0. The smoketest's
40-failing-migration caught it. update now exits the subshell with the
sourced hook's status.
Also, the smoketest scenarios that check whether a migration ran look for
"Running migration " so install.sh's "Running migrations..." heading
doesn't match (11-refresh failed on it).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brings in the shellcheck lint and bats tests. Both sides fixed the same
shellcheck warnings; this keeps the remote's versions of 20-aur.sh,
80-gnome-extensions.sh and .shellcheckrc, which silence false positives
per line rather than for the whole repo.
The Gitea workflow now runs make lint, so it checks the same scripts as
the Makefile, and the README points contributors at make check. The test
helper's REPO, used only by the .bats files, is marked for shellcheck,
and the update test expects the pull to be fast-forward only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
make lint runs shellcheck on every tracked bash script, make test runs
the bats suite in tests/, and make check runs both. The tests cover the
update orchestrator (hook isolation, failure reporting, pull and
free-space handling) and utils.sh (migrations, package install and
removal, services, initramfs build check), using stub commands so they
never touch the real system.
Fixes from the first lint run: 20-aur.sh stops if a cd fails rather
than building or deleting in the wrong directory, and
80-gnome-extensions.sh refuses to rm -rf with an empty path. The rest
are false positives, silenced in .shellcheckrc or per line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
davidandClaude Opus 5.5