install-rknpu.sh aborts after updating librknnrt.so, but succeeds on a second run (again)

[mandresve]

Update

I can confirm that this issue is still reproducible during a second clean installation on a fresh Debian Bookworm image.

The installer again aborted during install-rknpu.sh and continued with:

[server-install] install-rknpu.sh failed — continuing controller install anyway

As in my previous report, running the installer a second time allowed the RKNPU installation to complete successfully.

At this point, it looks like the failure is deterministic on a clean installation, while a subsequent run succeeds because some prerequisites have already been installed during the first attempt.

I've attached the complete log from the second clean installation in the "Clean install #1540 " issue for reference. If it would be helpful, I can also isolate the exact point where the first run diverges from the successful second run.

Originally posted by @mandresve in #1543

[kilo-code-bot]

This issue appears to be a duplicate of #1543.

install-rknpu.sh aborts after updating librknnrt.so, but succeeds on a second run (#1543)

Similarity score: 95%

This comment was generated by Kilo Auto-Triage.

[jaylfc]

Found it, and your read was the key: deterministic on the first run, fine on the second. It was not ldconfig after all.

The librknnrt version check ran strings <the 7MB runtime> | awk '/librknnrt version: / { print $3; exit }'. awk exits on the first match and closes the pipe while strings still has megabytes left to write, so strings takes a SIGPIPE. The installer runs with set -o pipefail and set -e, so that pipeline failure aborted the whole install. It only bites where binutils (strings) is present, which your Bookworm image has, and only on the first run: the second run finds librknnrt already pinned to 2.3.0 and skips that entire block, which is exactly the pattern you described.

Fix is up (the version check now reads to end-of-file instead of exiting early, and is guarded so a strings hiccup can never be fatal), verified against a set -e + pipefail reproduction. It will be in the next release. Thanks again, the first-vs-second-run detail is what pinned this down.