[bong-water-water-bong]

Three defects that a hardware run of candidate 5 exposed. All three are in the image's own tooling, not in the release itself — the image booted signed with Secure Boot enabled and our MOK, and passed 14/16 rows on the board.

1. models could never pass: nothing wrote /etc/1bit/onebit-models.txt

release-check.sh:233 reads the manifest and, when it is missing, fails with "the build writes it from server_models.json". Nothing in the tree ever wrote it — a grep for onebit-models across os/ returned exactly one hit, the consumer. So every image failed models on hardware, and chat-hrx failed one row later because no onebit entry was registered to answer.

mkimage.sh now derives the manifest from the Lemonade catalogue it already stages at /opt/lemonade/bin/resources/server_models.json, in exactly the format release-check.sh parses:

mode=live
hrx Qwen3-0.6B-Q4_K_M-1bit
npu Qwen3-4B-npu-1bit

Derived rather than hand-kept, so it cannot drift from what Lemonade actually ships. A catalogue with no onebit entries writes a manifest with none — reported as such by the check, rather than failing. The walk accepts both a list of model dicts and a dict of sections, so a catalogue layout change produces a manifest instead of silently producing an empty one.

2. chat-hrx / chat-npu blamed the environment for a missing entry

Both rows said "no AMD GPU in this VM" whenever their model id was absent — including on a machine with a working GPU, where the real cause was that Lemonade listed no -1bit entry. A wrong skip reason is how a real failure gets filed as an environment limitation. Both now distinguish no device (/dev/kfd, /dev/accel/accel*) from no matching entry listed.

3. secureboot skipped on a machine that had it enabled

The row used mokutil, which is not shipped in the image, so it always fell through to a skip — on a board that reported Secure Boot enabled in dmesg and had just booted our MOK-signed kernel. That is the row the owner cares about most for a permanent install, and it was hiding a pass.

It now reads the firmware's own variable, SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c, byte 5 of 5. No new binary:

byte 5	row
1	PASS Secure Boot enabled; the MOK-signed kernel booted
0	PASS Secure Boot disabled (the firmware reports it off)
unreadable	SKIP

Testing

• os/mini/release-check.sh --self-test → PASS, all 7 verdict cases.
• bash -n clean on both scripts.
• The manifest producer was exercised against a synthetic catalogue: produces mode=live, 2 × hrx, 1 × npu, and the parser's grep -c '^hrx ' / sed 's/^mode=//' read them as intended.
• The efivar parse was checked with synthesised 5-byte variables (1 → enabled, 0 → disabled).

Not in this PR: the chat-hrx "did not answer" failure is a separate, real defect — the engine execs hrx/llama/bin/llama-server as a relative path, while the image ships llama-server at /opt/1bit-llama/llama-server (lemond.log: "Failed to execute: hrx/llama/bin/llama-server"). That is engine server-path resolution and gets its own change.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Manifest Generation Logic The new logic for generating the /etc/1bit/onebit-models.txt manifest from server_models.json correctly handles both list and dict formats of the catalogue, but does not validate that the id field is present and non-empty for each model. This could lead to empty or malformed entries in the manifest if the catalogue contains invalid model entries. if "id" in node and isinstance(node.get("id"), str): yield node Secure Boot Check Improvement The updated secure boot check now reads the EFI variable directly to determine the Secure Boot state, which is a more accurate method than relying on mokutil. However, the check assumes that the EFI variable path is consistent across all UEFI implementations, which may not be true in all cases. SBVAR=/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c if [ -r "$SBVAR" ]; then sbv=$(od -An -tu1 -j4 -N1 "$SBVAR" 2>/dev/null | tr -d ' \n') case "${sbv:-}" in 1) pass secureboot "Secure Boot enabled; the MOK-signed kernel booted";; 0) pass secureboot "Secure Boot disabled (the firmware reports it off)";; *) skip secureboot "Secure Boot state unreadable from $SBVAR";; esac HRX Device Check Logic The new hrx-device check introduces a more precise way to determine if an HRX device is registered by parsing the output of llama-server --list-devices. However, the check may fail to detect a device if the output format changes or if the device is registered but not listed in the expected format. HRXDEV=$(printf '%s\n' "$LD" | sed -n 's/^[[:space:]]*\(HRX[0-9][0-9]*\): *\(.*\)$/\1: \2/p' | grep -vi 'INCOMPATIBLE' | head -1) if [ -n "$HRXDEV" ]; then pass hrx-device "$HRXDEV"