ares-install: stop reporting a successful install as a failure

[mariotaku]

Three fixes to how ares-install reports what happened. The first is a correctness bug: on some sets it reports a successful install as a failure.

1. A successful install reported as a failure

The install request goes out over an exec channel, and the device starts work on it before it answers. A connection that dies in that window leaves request_exec returning Socket error: disconnected — while the device carries on and installs the package.

On a set that drops SSH connections around install time this is not a corner case. It reproduced four runs out of four on a UP7560: every one printed

Failed to install: Fatal: Socket error: disconnected

and every one succeeded on the device, confirmed against appinstalld's NL_APP_INSTALLED and the Installed-Time in opkg's status file. Caught in the act with a changed binary, so checksums could tell the builds apart:

staged                      b05d92da609916f5cd99369fb3d86587
ares-install                -> "Failed to install: Fatal: Socket error: disconnected"
device, immediately after   a83303ff8c8c805cbfdf91afa79cfdd5   <- old app
device, ten seconds later   b05d92da609916f5cd99369fb3d86587   <- new app

The device was still writing the package while ares-install had already given up. Anyone checking the moment it exits sees the old app and is told the install failed — wrong twice over, and it sends people hunting for a device fault that isn't there.

A dead connection is not evidence of a failed install. It now says what is actually known:

lost the connection to up7560 while the install was running. The device may have installed
the package anyway - `ares-install -d up7560 --listfull` prints the version that is on it.
`--list` alone only names the app, which says nothing about which build landed

--listfull because it serialises version; plain --list prints ids only, so it answers "is this app on the device", not "did this build land" — a distinction that cost real debugging time. The Failed to install prefix is dropped for this case, since it contradicts the one thing the message has to say. Exit status stays non-zero: an unknown outcome is not a success.

2. A silent install stream reported as success

dev/install is subscribed to, and the loop takes the first message saying "installed" or naming a failure. If the stream ends having said neither, .next() returns None — and that was mapped to Ok(String::new()), so ares-install printed Installed package ! and exited 0 for an install whose outcome it never learned. That is now an error.

3. Cleanup noise in front of the real error

Deleting the uploaded ipk happens on the way out, before the install result is propagated, so its failure always landed ahead of the error that explains the run:

Failed to delete /media/developer/temp/ares_install_fca561c25f.ipk: Ssh(Fatal("Inappropriate ioctl for device"))
Failed to install: Fatal: Socket error: disconnected

The ENOTTY is meaningless — a stale errno libssh reports through a session that is already gone — and it reads like a permission or path problem on the device. Cleanup now checks the session first and, when it is gone, names what was left behind instead:

Lost the connection to up7560, so /media/developer/temp/ares_install_d224c1e3f6.ipk is still on the device.

Errors in this file print with Display rather than Debug, so the remaining two say what went wrong instead of dumping a variant.

Verification

Fixes 1 and 3 were built and run against a UP7560 on the exact case that produced the false failure six times: output accurate, leftover ipk named, cleanup noise gone, exit status non-zero, and the package confirmed on the device by checksum. Fix 2 is not reachable on demand and was not exercised on hardware.

Workspace builds clean; 79 tests pass; clippy warnings for the crate drop from 36 to 34.

Not addressed here: why the socket dies. That was chased a long way — dropbear 2022.83 with no channel cap, listener pid and start time unchanged across installs, an idle reverse tunnel surviving untouched, no OOM kill, and a clean dmesg over a window verified to cover the event. It is narrowed to something on the device deliberately ending that process, and it is a device-side question that does not block this.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Gde2tcn5SbUHKhesuTNB7a