4.7 KiB
Cleanup-Verträglichkeit und Wiederherstellung
Verifizierter Stand vom 2026-09-10
Ein globales Leeren von ~/.cache entfernte Modell und Bildprojektor. Beim Aufwachen aus dem Idle-Sleep brach llama.cpp deshalb ab. Docker system prune entfernte außerdem das gerade unbenutzte Netz hermes-net. Der automatische Dienstneustart lud die Dateien erneut herunter. Nach vollständigem Download wurden Modell und Projektor als reguläre Dateien außerhalb des Caches abgelegt und mit cmp gegen die Quellen geprüft.
Nach Umstellung und kontrolliertem Neustart bestätigte das Serverlog beide neuen Pfade. Eine Textanfrage lieferte OK, der Healthcheck Result=success. Profil baseline bleibt unverändert (65536 Kontext, 1536 MiB Fit-Zielmarge). Damit sind Modellstart, kurze Textinferenz und leichte Gesundheitsprüfung belegt; ein kompletter Bildjob und der Docker-Netzwerk-Canary wurden bei dieser Wiederherstellung noch nicht erneut getestet.
Modellablage auf weiteren Rechnern
Die bestehende config/llama.env.example dient weiter zum HF-Bootstrap. Downloads vollständig beenden lassen. Keine .downloadInProgress-Dateien übernehmen. Die verifizierte Revision lautet: 0669b98607d47046c7c2b3f801011d54a08cfccf
Die Quellen liegen unter: ~/.cache/huggingface/hub/models--ggml-org--Qwen3.8-27B-GGUF/snapshots/REVISION/ Die dauerhaften Dateien gehören unter: ~/.local/share/hermes-stack/models/qwen38-27b/REVISION/
Benötigt werden Qwen3.8-27B-Q4_K_M.gguf und mmproj-Qwen3.8-27B-Q8_0.gguf. Cache-Symlinks beim Kopieren dereferenzieren (cp -L), reguläre Kopien mit cmp prüfen und die Cache-Quellen bis zur erfolgreichen Laufzeitprüfung behalten. Falls der Bootstrap eine andere Revision lädt, diese zuerst prüfen und bewusst auswählen; nicht verschiedene Modell-/Projektor-Revisionen mischen.
config/llama-local.env.example zeigt die lokale Konfiguration. In bestehender llama.env nur LLAMA_MODEL und LLAMA_MMPROJ setzen und LLAMA_HF_REPO leeren; Binary-Auswahl und Profil beibehalten. Vorher sichern. Auf neuen Rechnern die Vorlage erst nach Bereitstellung der passenden Dateien verwenden. Die Dateien werden nicht ins Git-Repository aufgenommen. Hermes-Updates aktualisieren diese fest ausgewählte lokale Modellrevision nicht automatisch.
Prüfen: hermes-stack-llama-run --check und --print. Erst nach Jobende mit hermes-stack-llama-restart --jobs-finished neu starten. Anschließend /health, eine kurze Inferenz und hermes-stack-health.service prüfen. Die --check-Prüfung allein belegt nur Konfiguration und Optionsnamen, keine funktionierende Inferenz.
Docker-Netz
Am 10. September wurde hermes-net als normale Bridge wieder angelegt:
docker network create --driver bridge hermes-net
docker network inspect hermes-net
Nur bei fehlendem Netz ausführen. Vorhandene Netze nicht entfernen. Docker wählte auf der Workstation 172.18.0.0/16 mit Gateway 172.18.0.1. Diese Adressen sind kein portabler Sollwert; auf neuen Rechnern Docker wählen lassen. Sonderoptionen des früher gelöschten Netzes waren nicht dokumentiert. In der privaten config.env DOCKER_NETWORK=hermes-net setzen, wenn Hermes dieses Netz verwendet. Die leere Deployment-Vorlage deaktiviert die Prüfung. install.sh erstellt das Netz nicht; Anlage und Container-Verbindung separat prüfen.
Cleanup-Skripte
maintenance/ enthält die korrigierten Skripte. install.sh installiert und startet sie nicht. Auf der Workstation liegen sie unter ~/Scripts; vorhandene Dateien vor einem manuellen Austausch sichern. Keine Zugangsdaten übernehmen.
- arch-maintenance.sh: standardmäßig Dry-Run, Änderungen erst mit --apply. Container, Images und Builder-Cache werden getrennt bereinigt; Netze bleiben. --docker-volumes bleibt eine ausdrückliche, datenlöschende Option.
- arch-sanity-cleanup.sh: interaktiv, kein allgemeiner Dry-Run. Im allgemeinen User-Cache nur Thumbnail-/Fontconfig-Dateien älter als 30 Tage löschen. Modellcache und Downloads bleiben erhalten. Docker-Netze werden nicht bereinigt.
- Beide Skripte behalten weitere Wartungsfunktionen, etwa Paket- und AUR- Bereinigung. --docker-aggressive bzw. die Image-Rückfrage kann weiterhin unbenutzte Runtime-Images entfernen; diese müssen später erneut geladen werden.
- Eigene tmpfiles-Regeln, andere Cleanup-Werkzeuge und manuelle Löschbefehle sind hiervon nicht erfasst. Ein Netzname allein schützt nicht vor prune.
Die Korrekturen wurden mit bash -n sowie gezielten Tests mit temporären Dateien und einem Docker-Ersatzprogramm geprüft: Modell-/Download-Dateien erhalten, alte Thumbnail-/Fontdateien entfernt, keine Docker-Netzbereinigung aufgerufen. Die normale Repo-Prüfung prüft die Cleanup-Skripte auf Syntax, führt sie aber nicht aus. Root-Wartung und echte Docker-Prunes sind kein Bestandteil der Tests.