Repository navigation
v0.4.3 — Hotfix: libunwind8 für Qdrant
Hotfix — Qdrant startet jetzt wirklich
Mit v0.4.2 startet uvicorn, aber der Qdrant-Sidecar bricht sofort ab mit:
/usr/local/bin/qdrant: error while loading shared libraries:
libunwind-ptrace.so.0: cannot open shared object file
Damit failed dann der FastAPI-Lifespan in index.ensure_collection() mit Connection refused, der Container shuttet sich runter via [api] service exited — bringing the add-on down.
Ursache
Wir kopieren mit COPY --from=qdrant/qdrant:v1.17.1 /qdrant/qdrant /usr/local/bin/qdrant nur das Binary, nicht seine Runtime-Library-Dependencies. Upstream qdrant/qdrant installiert in seinem Image libunwind8 (enthält libunwind-ptrace.so.0); unsere debian-slim-Base hatte das nicht.
Fix
libunwind8 zur apt-get install-Schicht im Dockerfile hinzugefügt.
Drive-by-Fix
app/embedder.py benutzt jetzt bevorzugt SentenceTransformer.get_embedding_dimension() (neue Methode) statt get_sentence_embedding_dimension() (deprecated). Damit verschwindet die FutureWarning die im selben Log-Block auftauchte.
Update auf v0.4.3
In HA: Settings → Add-ons → BookStack RAG → Update. Build sollte mit Layer-Cache schnell durchgehen (~30 Sek-2 Min, weil nur die apt-Schicht neu gebaut wird; PyTorch + Modell bleiben aus dem Cache). Nach dem Update Start klicken.
Im Add-on-Log solltest du jetzt sehen:
[qdrant] starting on localhost:6333 (storage at /data/qdrant)...
[api] waiting for qdrant readiness on localhost:6333...
[api] qdrant ready after Xs — starting API
INFO:app.embedder:Loading embedding model nomic-ai/nomic-embed-text-v1.5
INFO:app.embedder:Embedding model loaded — vector size 768
INFO:app.main:Initial reconcile: indexed=N unchanged=0 skipped=0 failed=0
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
Wenn alle Zeilen kommen → ready, Web-UI in der HA-Sidebar klicken.
Process-Note
Das war der zweite Runtime-Failure (nach v0.4.2's leerer-String-im-Schema), den unsere CI nicht abgefangen hat — der Smoke-Build ruft nur docker build, nie docker run. v0.5.0 wird das beheben: vorgebaute Images via home-assistant/builder werden bei der Publish-Action tatsächlich gestartet, das fängt diese Klasse von Bug. Bis dahin ist Real-Host-Install der einzige Gate.