Skip to content

hal0 v0.8.5b2

Choose a tag to compare

@github-actions github-actions released this 04 Jul 17:49
0bdc8c9

Hotfix over v0.8.5b1, closing the three findings from the first live
update+verification pass on Strix Halo hardware (CT105): stale mtp = true
overrides crashing slots on re-render, slot units not re-rendering on update,
and the gateway missing POST /v1/rerank. Safe upgrade from v0.8.5b1
the one migration (crash-only MTP override defuse) touches exactly the slot
configs that could not have loaded anyway, with a loud per-slot log.

Added

  • Slot units re-render automatically on update. A slot's systemd unit
    bakes the launch argv at load time, so updating hal0 changed the code that
    WOULD render but not the file that DID — systemctl restart, crash
    restarts, and reboots kept running pre-update flags until an operator did a
    hal0-level slot restart (field finding). The updater (post venv-reinstall,
    via a fresh interpreter so the NEW code renders) and install.sh now
    rewrite every existing unit through current code plus one daemon-reload
    running services are never bounced; fresh argv applies on each slot's next
    start from any path. Per-slot failures log and skip. The dashboard drift
    indicator still covers the "process running old argv until next restart"
    window.

Fixed

  • Gateway now serves POST /v1/rerank. The dispatcher's capability path
    map already resolved /rerank to the rerank slot, but the gateway only
    registered /v1/rerankings — so clients using llama-server's / Jina-style
    /v1/rerank got 405 and had to hit the slot port directly (field finding).
    /v1/rerank is now an alias of /v1/rerankings through the same dispatch
    path.
  • Crash-only mtp = true overrides are defused automatically. A forced
    MTP override pointing at a model with no MTP heads crashes llama-server at
    load once the slot's unit re-renders under the v0.8.5b1 MTP separation
    (field-confirmed: pre-separation mtp = true debris on a headless MoE
    model). Two mechanisms now clear exactly that combination: an updater
    migration over the slot TOMLs (updater.mtp_force_on_cleared log; force-off,
    eligible force-on, and unresolvable models untouched) and a swap-path guard
    (swapping onto an ineligible model drops a forced true → AUTO, so the
    staleness can't regenerate). The false-negative escape hatch — forcing MTP
    on for an untagged-but-capable model — is preserved.