[bong-water-water-bong]

Stacked on #579 (same base; merge #579 first and this PR shows only its own commit). Files: os/mini/mkimage.sh, os/mini/init.sh.

First hardware boot of the signed candidate 5 (26 Oct, Secure Boot enabled, our MOK loaded): 14 of 16 release checks pass (fans controlled, GPU, NPU, Lemonade 401 keyless, chat 176 tok/s, bench, sealed sets, licences). The two onebit rows fail for reasons the VM gate cannot see, both fixed here:

1. Lemonade cannot start the engine's server. scripts/lemonade-hrx defaults to the llama-server beside the script (hrx/llama/bin/llama-server); the image keeps it at /opt/1bit-llama. lemond logged Failed to execute: hrx/llama/bin/llama-server. init.sh now exports ONEBIT_HRX_LLAMA_SERVER=/opt/1bit-llama/llama-server, the script's own override, for lemond and for ssh logins via /etc/profile.
2. The HRX backend never loads. With the server named, llama-server --list-devices printed (none): libggml-hrx is dlopened by ggml and NEEDS libhsa-runtime64.so.1, which was not beside it; the stage resolved only the program's NEEDED entries. Putting Lemonade's bundle on LD_LIBRARY_PATH made it load and then mixed that bundle's libloomc into the engine (undefined symbol: loomc_link_index_builder_allocate). mkimage.sh now resolves the NEEDED entries of every lib*.so in /data/1bit-llama, copies the HSA runtime's ROCm sysdeps flat beside it (relocate() makes every file look in $ORIGIN only), and fails the build if any library still misses one. /etc/1bit/libhsa prefers that copy, with Lemonade's bundle as the fallback for older data partitions.

Evidence on the board: with SVM left on and the right libraries on the path, llama-server --list-devices lists HRX0: AMD Radeon 8060S Graphics (gfx1151).

Not in this PR: the engine package inside the image is candidate 3's tarball (candidates 4 and 5 were package-only runs), built before the HRX_ALLOW_NO_SVM gate of #565, so on the CWSR-on kernel the HRX runtime answers "only systems with SVM are supported". Candidate 6 is a full build. Also not here: the engine's own default llama-server path when 1bit serve is run by hand (follow-up issue).

🤖 Generated with Claude Code

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 5b90513)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 579 - Partially compliant Compliant requirements: The manifest file is now generated by mkimage.sh from server_models.json Skip reasons for chat-hrx and chat-npu are now correctly distinguished Secure Boot detection now uses firmware variables directly Non-compliant requirements: The chat-hrx "did not answer" failure is not addressed in this PR (as noted in the ticket description) Requires further human verification: Verification that the firmware variable parsing works correctly on actual hardware Confirmation that the chat-hrx "did not answer" issue is resolved in a separate change 565 - Partially compliant Compliant requirements: HRX submodules are updated to the specified commits Non-compliant requirements: No specific requirements related to the bump are explicitly tested or verified in this PR Requires further human verification: Verification that the updated HRX submodules work correctly on hardware Confirmation that the long-prompt correctness probe and test-backend-ops -b HRX0 pass

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Missing HSA runtime dependencies The llama_to_data function now copies HSA runtime dependencies and ROCm sysdeps, but it does not validate that all required libraries are present after copying. If a library is missing from the source paths, it could lead to runtime failures. The check at the end of the function ensures that the llama-server and all lib*.so files are fully resolved, but it does not ensure that the ROCm sysdeps are correctly copied. for f in "$out/data.dir/1bit-llama/llama-server" "$out/data.dir/1bit-llama"/lib*.so; do if ldd "$f" 2>/dev/null | grep -q "not found"; then echo "$(basename "$f") on the data partition still misses libraries:" ldd "$f" | grep "not found" exit 1 fi done Incorrect HSA runtime path resolution The logic for resolving the HSA runtime path in init.sh prioritizes /data/1bit-llama over /data/lemonade/cache/bin/llamacpp-hrx/*/lib, which may lead to incorrect behavior if the HSA runtime is not present in the expected location. This could cause the system to fail to find the correct HSA runtime, especially in older data partitions. hsa=$(ls /data/1bit-llama/libhsa-runtime64.so* 2>/dev/null | head -1) [ -n "$hsa" ] || hsa=$(ls /data/lemonade/cache/bin/llamacpp-hrx/*/lib/libhsa-runtime64.so* 2>/dev/null | head -1) [ -n "$hsa" ] && echo "$hsa" > /etc/1bit/libhsa

[github-actions]

Persistent review updated to latest commit 5b90513