Problem
install_evsieve can hang the entire installer on a hidden prompt. Observed
2026-07-21 on a real Deck install: the build sat with zero CPU, target/ flat,
and the process tree showed distrobox in state T (stopped) and podman exec --interactive in Tl — i.e. SIGTTIN-stopped. The interactive podman session
tried to read the controlling TTY (almost certainly a sudo password prompt), and
because output is sent to /dev/null the prompt was invisible. It only unblocks when
the timeout 900 fires (~15 min) → fail-open.
Likely trigger: a freshly-created box (here, after podman system reset wiped
container storage) where distrobox's passwordless-sudo init hadn't taken effect, so
sudo apt-get in _evsieve_build_in_box prompted. modules/evsieve_management.sh
redirects the build's stdout/stderr to /dev/null but leaves stdin on the TTY.
Fix ideas
- In
_evsieve_build_in_box, run the build with stdin detached (< /dev/null) so a
prompt fails fast instead of hanging; and/or sudo -n (non-interactive) so it errors
immediately when a password would be needed.
- Ensure the box is fully initialized (NOPASSWD sudo ready) before building, or build as
root without sudo, or don't pass --interactive for a non-interactive command.
- Shorten the effective wait / surface a clear "waiting on the build box" state instead
of a silent 15-min stall.
Acceptance
A fresh-box install builds evsieve without ever blocking on input; if the box/
toolchain can't be prepared it fail-opens promptly, not after a 15-min TTY stall.
Related
Surfaced alongside the build progress-indicator work (PR #123). That PR's
run_with_spinner backgrounds its command, so it also needs </dev/null (done on the
branch) — same SIGTTIN class of bug.
Problem
install_evsievecan hang the entire installer on a hidden prompt. Observed2026-07-21 on a real Deck install: the build sat with zero CPU,
target/flat,and the process tree showed
distroboxin stateT(stopped) andpodman exec --interactiveinTl— i.e. SIGTTIN-stopped. The interactive podman sessiontried to read the controlling TTY (almost certainly a
sudopassword prompt), andbecause output is sent to
/dev/nullthe prompt was invisible. It only unblocks whenthe
timeout 900fires (~15 min) → fail-open.Likely trigger: a freshly-created box (here, after
podman system resetwipedcontainer storage) where distrobox's passwordless-sudo init hadn't taken effect, so
sudo apt-getin_evsieve_build_in_boxprompted.modules/evsieve_management.shredirects the build's stdout/stderr to
/dev/nullbut leaves stdin on the TTY.Fix ideas
_evsieve_build_in_box, run the build with stdin detached (< /dev/null) so aprompt fails fast instead of hanging; and/or
sudo -n(non-interactive) so it errorsimmediately when a password would be needed.
root without
sudo, or don't pass--interactivefor a non-interactive command.of a silent 15-min stall.
Acceptance
A fresh-box install builds evsieve without ever blocking on input; if the box/
toolchain can't be prepared it fail-opens promptly, not after a 15-min TTY stall.
Related
Surfaced alongside the build progress-indicator work (PR #123). That PR's
run_with_spinnerbackgrounds its command, so it also needs</dev/null(done on thebranch) — same SIGTTIN class of bug.