89 lines
4.7 KiB
Markdown
89 lines
4.7 KiB
Markdown
# 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:
|
|
|
|
```bash
|
|
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.
|