mission-control-v2/docs/UPDATES.md

Updates — die Sonntags-Kette, Festhalten, Freigeben

Stand 24.09.2026, Code in main = 75611be. Für Techniker und Agenten; für den User: Seite „Updates" in BEDIENUNG.md.

Die Box aktualisiert ihre Fremd-Software jeden Sonntag selbst: erst llama-swap, dann den Motor (llama.cpp), dann Hermes. Jeder Baustein wird danach geprüft; ist die Prüfung rot, rollt die Box zurück und hält den Baustein fest, bis ihn jemand freigibt. Sicherheitsupdates des Betriebssystems laufen getrennt über unattended-upgrades. Modelle wechseln nie automatisch (Modell-Radar, Knopf „Übernehmen").

Ablauf

flowchart TD
  T["mc2-autoupdate.timer<br/>So 04:30 (+≤10 min)"] --> S["jobs/sonntags-update.sh"]
  S --> A["autoupdate.sh"]
  A --> R["1 · llama-swap<br/>update-swap.sh"]
  R --> E["2 · Motor<br/>update-engine.sh"]
  E --> H["3 · Hermes<br/>Job über MC2"]
  H --> W["Wochenbericht<br/>[Box-Update]"]
  W --> N{"Neustart nötig?<br/>nur So 04–07 Uhr"}

1. mc2-autoupdate.timer (Persistent=true, bis 10 min Zufallsverzug) startet mc2-autoupdate.service (einmaliger Lauf nach mc2-backup.service, Zeitlimit 3 h). Die Unit ruft deploy/jobs/sonntags-update.sh, das deploy/autoupdate.sh startet und nur dann selbst meldet, wenn autoupdate.sh mit Fehler endet (letzte 15 Zeilen). Der Hermes-Cron „Updates am Sonntag" ist seit 24.09. pausiert.
2. autoupdate.sh bricht mit Meldung ab, wenn MC2 (/api/health) nicht antwortet.
3. llama-swap und Motor: Ein festgehaltener Baustein wird übersprungen. Sonst liefert GET /api/maintenance/update-details?kind=swap bzw. kind=engine die installierte und die neueste Version. Gibt es Neues, läuft sudo -n bash deploy/update-swap.sh bzw. update-engine.sh (fehlt die sudo-Freigabe, wartet der Baustein mit Hinweis). Die Skripte sichern die alte Version (/usr/local/bin/llama-swap.bak, /opt/llamacpp-vulkan.bak), stoppen llama-swap, tauschen, starten und prüfen mit stack-postcheck.sh. Ergebnis 0 = eingespielt, 1 = zurückgerollt (Baustein wird festgehalten, Meldung), 2 = Update und Rückweg gescheitert (Meldung „KRITISCH", dringend).
4. Hermes: Ein festgehaltener Hermes wird übersprungen. Sonst sagt update-details?kind=hermes, wie viele Commits Hermes zurückliegt. autoupdate.sh startet POST /api/maintenance/hermes-update und wartet bis zu 20 Minuten. Der Job: Sicherung → Dashboard stoppen → hermes update --yes --no-gateway-restart → hermes doctor → Dashboard-Oberfläche mit Basis /hermes-ui/ bauen → hermes-gateway und hermes-builtin-ui neu starten → hermes-postcheck.sh. Seit dem Update vom 25.09.2026 hat Hermes einen eigenen Paketmanager (hermes pm): Das Gateway startet über ~/.hermes/hermes-agent/.hermes/bin/hermes in einer eigenen Umgebung (Python 3.14 unter ~/.hermes/installs/…); das alte venv (Python 3.11) bleibt liegen, das Dashboard startet noch daraus. Der Job ruft deshalb den neuen Starter, baut mit CC=gcc CXX=g++ CMAKE_POLICY_VERSION_MINIMUM=3.5 (sonst scheitert python-olm am fehlenden clang und an CMake 4), wertet Hinweise von doctor nicht als Fehler, legt mit hermes-plugin-deps.sh die Pakete unserer Plugins nach (trafilatura) und lädt die Units neu, bevor er neu startet. Die Zusatzpakete, die Lucy braucht, merkt sich der Paketmanager (hermes pm install --extra telegram --extra ddgs --extra stt-whisper, am 25.09. eingerichtet); fehlen sie, meldet hermes doctor „Configured features whose dependencies are still missing“, und nach dem nächsten Neustart wäre Telegram weg. Scheitert der Job, nachdem der neue Code schon da ist, heißt es „HERMES-UPDATE UNVOLLSTÄNDIG“ statt „alter Stand“.
   • Grün: Meldung.
   • Rot oder Zeitlimit: erst self-repair.sh (kommentiert eindeutige, nicht sicherheitsrelevante Config-Schlüssel aus, an denen die neue Version scheitert; der Gehirn-Check muss danach grün sein).
   • Hilft das nicht: Rückweg — git reset --hard auf den alten Commit in ~/.hermes/hermes-agent, config.yaml und .env aus der letzten Sicherung, Neustart, Gehirn-Check. Grün: Hermes wird festgehalten, Meldung. Sonst „KRITISCH" (dringend).
5. Wochenbericht „Commander, die Wochenpflege der Box ist durch" mit einer Zeile je Baustein.
6. Neustart, wenn Ubuntu ihn verlangt (/var/run/reboot-required), nur sonntags 04:00–06:59; außerhalb gibt es nur eine Ankündigung. Vorher prüft das Skript: Linger an, keine laufenden Jobs, mission-control-2, mc2-gateway und mc2-steward im Autostart; sonst Meldung statt Neustart. MC_AUTOUPDATE_REBOOT=0 schaltet den Neustart ab, MC_AUTOUPDATE_REBOOT_JETZT=1 erzwingt ihn außerhalb des Fensters.

Nachts landen alle Meldungen außer „KRITISCH" in der Morgenmeldung um 07:00.

Prüfungen nach dem Update

• stack-postcheck.sh (nach llama-swap, Motor und Betriebssystem): llama-swap aktiv; /v1/models antwortet (bis 120 s); das Hirn liefert eine echte Antwort (1 Token); das Embedding-Modell liefert Vektoren; MC2 meldet den Motor erreichbar; Gateway gesund; Steward aktiv.
• hermes-postcheck.sh (nach Hermes): keine Config-Warnungen im Gateway-Log der letzten 3 Minuten; Werkzeug-Test durch den echten Agenten (echo postcheck-ok, bis 3 Versuche); Sprach-Test über /api/voice/chat (bis 3 Versuche); Browser-Werkzeug agent-browser lauffähig (einen toten Link setzt das Skript selbst neu).

Festhalten und Freigeben

• Rot mit grünem Rückweg ergibt einen Eintrag in /srv/models/mc2-pins.json: {"<baustein>": {"pinned": true, "version": …, "grund": …, "datum": …}} mit den Bausteinen swap, engine, hermes. Künftige Sonntage überspringen ihn.
• Der Wächter zeigt jeden festgehaltenen Baustein als gelben Hinweis „… bekommt keine Updates mehr" mit Knopf „Freigeben"; die Updates-Seite zeigt ihn ebenso. Freigeben löscht den Eintrag (POST /api/updates/festgehalten/{baustein}/freigeben); der nächste Sonntag versucht das Update erneut.
• Warum sichtbar: Vom 06. bis 17.09. hielt die Box Motor und Hermes fest, ohne dass es jemand merkte, elf Tage ohne Updates.

Von Hand

• Seite „Updates": „Nach Neuem suchen" (apt-get update), je Baustein „Aktualisieren", „Alles jetzt aktualisieren" (mit Rückfrage). Es läuft immer nur ein Wartungs-Job; ein zweiter Klick startet kein zweites Update.
• „Alles jetzt aktualisieren" kettet in einem Job, was ansteht: Motor → llama-swap → Hermes → Betriebssystem (apt-get upgrade, danach stack-postcheck.sh). Scheitert ein Teil, stoppt die Kette.
• Zeitlimits der Jobs: Suche 15 min, Betriebssystem 90 min, Motor 60 min, llama-swap 30 min, Hermes 45 min, alles zusammen 3 h. „Abbrechen" beendet die ganze Prozessgruppe.
• Per SSH: bash ~/mission-control-v2/deploy/autoupdate.sh (neu gestartet wird trotzdem nur im Wartungsfenster).
• Kann eine Update-Prüfung nicht prüfen (Netz, API, apt), zeigt die Oberfläche „Prüfung unklar" statt „aktuell". Nach jedem Update prüft sie sofort neu.
• Update-Jobs leben im MC2-Prozess; ein Neustart von MC2 bricht sie ab. Der Deploy wartet deshalb.

Update-Verlauf

backend/services/update_verlauf.py baut den Verlauf der Updates-Seite aus ~/mc2-notify.log. Es liest die Zeilen OK telegram, OK telegram direkt (Zweitweg über die Bot-API), QUEUED für Morgen-Digest und FALLBACK (…). Meldungen mit weniger als 45 Minuten Abstand gehören zu einem Lauf; die Morgenmeldung zählt nicht als eigener Lauf. Der Wortlaut der Meldungen von autoupdate.sh und der Protokolleinträge muss deshalb bleiben: Eine Umformulierung bricht den Verlauf ohne Fehlermeldung.

Betriebssystem

Sicherheitsupdates spielt unattended-upgrades ein. Wartet danach ein Kernel oder libc auf den Neustart, startet der Sonntagslauf die Box im Wartungsfenster neu. Weitere Pakete: Knopf „Aktualisieren" beim Baustein Betriebssystem.

Fallen

• llama.cpp hat --no-mmap gestrichen (seit b10936); die Config nutzt --load-mode none. Vor einem Engine-Sprung die Config-Zeilen mit dem neuen llama-server prüfen.
• hermes update meldet Exit 1 trotz Erfolg, deshalb --no-gateway-restart.
• Ein Timer mit Persistent=true holt verpasste Läufe beim Einschalten sofort nach (24.09.: Neustart um 14:51).
• Der Updater läuft nicht mehr als Hermes-Cron (20.09.: Hermes startete sich beim eigenen Update neu).

Einzelheiten: wissen/FALLEN.md.