Ursache des fehlgeschlagenen Engine-Updates: die allerneueste llama.cpp-Release traegt
oft noch KEINE CI-Binaries (0 Assets). update-engine.sh lud aber stur von releases/latest
→ 404 „Download fehlgeschlagen".
Fix:
- update-engine.sh: nimmt die neueste Release, die wirklich ein ubuntu-vulkan-x64.tar.gz
traegt, und nutzt dessen echte browser_download_url (robust gegen Namensaenderungen).
- maintenance.py: _engine_update_available + engine_update_details pruefen jetzt ebenfalls
gegen die neueste ASSET-tragende Release → das Badge luegt nicht mehr („verfuegbar", aber
Download 404). Verifiziert: aufgeloeste URL liefert HTTP 200.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ROOT CAUSE: Die Unit pinnte MC_ENGINE_UPDATE_CMD=/usr/local/bin/update-llamacpp —
ein Alt-Skript aus der ROCm-Zeit, das den ROCm-Build nach /opt/llamacpp (totes
Rollback-Dir) zog statt des aktiven Vulkan-Builds nach /opt/llamacpp-vulkan. Es
endete mit 0 → Job "DONE", aber die aktive Engine blieb auf 9821. Mein
deploy/update-engine.sh lag dadurch komplett brach. Fix: Pin aus der Unit raus →
Backend nutzt den Default `sudo bash <repo>/deploy/update-engine.sh`.
Zusätzlich (vom User vermutet): mit geladenem Modell laeuft llama-server → die
Binary ist "Text file busy", in-place ueberschreiben scheitert. update-engine.sh
und update-swap.sh stoppen llama-swap jetzt VOR dem Austausch und starten danach,
mit robustem Fehlerpfad (set -uo statt -e, Service kommt immer zurueck, sonst
Rollback aus .bak).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
update-engine.sh / update-swap.sh sichern jetzt den alten Build/die alte Binary
VOR dem Ueberschreiben (.bak), verifizieren nach dem Restart per stack-postcheck.sh
und rollen bei Fehler automatisch zurueck (Binary/Dir wiederherstellen + restart +
erneut pruefen). Exit-Codes: 0 = neuer Build verifiziert, 1 = fehlgeschlagen aber
Rollback ok (alter Stand laeuft wieder), 2 = Update UND Rollback kaputt.
Da die Skripte den Postcheck nun selbst fahren (um reagieren zu koennen), entfaellt
das `&& stack-postcheck` in engine/swap-update-job. OS-Update behaelt den reinen
Detect-Check (apt-Downgrade waere unsicher). Backups sind winzig (Engine 86M,
Swap 14M) bei 1.6TB frei.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hitonabi