From 32d34f39cd8fa3b190c16cd591413b31b1e07557 Mon Sep 17 00:00:00 2001
From: duffyduck <info@hacker-net.de>
Date: Mon, 19 Oct 2026 02:42:06 +0200
Subject: [PATCH] fix(xtts): LLM auf der GPU + Container finden nach dem Reboot
 den RVS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Zwei Ursachen, beide auf der KI-Box nachgewiesen:

1. llama.cpp fand auch mit Treiber 615 keine Karte ("unsupported display
   driver / cuda driver combination"). Das llama-swap-Image traegt in seiner
   ld.so.conf die eigene CUDA-Kompatibilitaets-libcuda (575) VOR dem vom
   Container-Toolkit eingehaengten Host-Treiber (615) ein. Die Kompatibilitaets-
   bibliothek hilft nur Rechenzentrumskarten; bei GeForce scheitert llama.cpp
   damit — mit aelterem Treiber ("forward compatibility …") wie mit neuerem —
   und rechnet still auf der CPU. Jetzt LD_LIBRARY_PATH mit dem Host-Treiber
   zuerst. Auf der Box getestet: llama.cpp sieht CUDA0 + CUDA1. Whisper und
   F5-TTS (andere Images) sehen ihre Karte mit 615 ohnehin.

2. Nach dem Reboot erreichte kein Container den RVS ("Temporary failure in name
   resolution"). Debian traegt die Netzwerkkarte als allow-hotplug ein; darauf
   wartet network-online.target nicht. Docker startete die Container 2 s nach
   "online", bevor DHCP den DNS-Server lieferte ("DNS resolver has no external
   nameservers"), und die Container behalten diesen leeren Stand. Passiert bei
   jedem Reboot. bootstrap.sh legt jetzt ein systemd-Drop-in an: Docker wartet
   vor dem Start bis zu 90 s auf einen Nameserver in /etc/resolv.conf, dann
   startet es trotzdem. Netzkonfiguration bleibt unangetastet. Escaping und
   beide Pfade (DNS da / nicht da) in einer echten systemd-Unit getestet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 xtts/bootstrap.sh       | 27 +++++++++++++++++++++++++++
 xtts/docker-compose.yml |  8 ++++++++
 2 files changed, 35 insertions(+)

diff --git a/xtts/bootstrap.sh b/xtts/bootstrap.sh
index 50b9349..ffee8ca 100755
--- a/xtts/bootstrap.sh
+++ b/xtts/bootstrap.sh
@@ -252,6 +252,33 @@ if [[ "$DO_UPGRADE_DRIVER" -eq 1 ]]; then
   fi
 fi
 
+# ── 2c. Docker wartet beim Booten auf DNS ──
+# Debian traegt die Netzwerkkarte als "allow-hotplug" ein — darauf wartet
+# network-online.target NICHT. Docker startet die Container dann, bevor DHCP den
+# DNS-Server geliefert hat ("DNS resolver has no external nameservers"), und die
+# Container behalten diesen leeren Stand: kein RVS, keine Verbindung, bis man
+# sie neu erzeugt. Passiert bei jedem Reboot.
+# Abhilfe ohne die Netzkonfiguration anzufassen: Docker wartet vor dem Start bis
+# zu 90 s, bis /etc/resolv.conf einen Nameserver hat.
+step "Docker wartet beim Booten auf DNS"
+DROPIN=/etc/systemd/system/docker.service.d/aria-wait-dns.conf
+if [[ -f "$DROPIN" ]]; then
+  ok "schon eingerichtet ($DROPIN)"
+else
+  mkdir -p "$(dirname "$DROPIN")"
+  cat > "$DROPIN" <<'EOF'
+# ARIA bootstrap.sh: Container erst starten, wenn DNS da ist (sonst merken sie
+# sich "keine Nameserver" und erreichen den RVS nie). Siehe xtts/bootstrap.sh.
+[Unit]
+Wants=network-online.target
+After=network-online.target
+[Service]
+ExecStartPre=/bin/sh -c 'for i in $(seq 1 90); do grep -q "^nameserver" /etc/resolv.conf && exit 0; sleep 1; done; echo "kein DNS nach 90 s — starte trotzdem"; exit 0'
+EOF
+  systemctl daemon-reload
+  ok "eingerichtet — greift ab dem naechsten Boot"
+fi
+
 # ── 3. NVIDIA-Treiber ──
 step "NVIDIA-Treiber"
 if nvidia-smi >/dev/null 2>&1; then
diff --git a/xtts/docker-compose.yml b/xtts/docker-compose.yml
index 4a29637..b0943cc 100644
--- a/xtts/docker-compose.yml
+++ b/xtts/docker-compose.yml
@@ -141,6 +141,14 @@ services:
       # CUDA zaehlt Karten sonst "schnellste zuerst" — dann waere CUDA-Karte 0
       # nicht unbedingt nvidia-smi-Karte 0. PCI-Reihenfolge = wie nvidia-smi.
       - CUDA_DEVICE_ORDER=PCI_BUS_ID
+      # Echten Treiber vom Host zuerst laden. Das Image traegt in seiner
+      # ld.so.conf die eigene CUDA-Kompatibilitaets-libcuda (fuer Treiber 575)
+      # VOR dem eingehaengten Host-Treiber ein. Die hilft nur Rechenzentrums-
+      # karten; bei GeForce scheitert llama.cpp damit ("forward compatibility …"
+      # bei aelterem, "unsupported display driver / cuda driver combination" bei
+      # neuerem Treiber) und rechnet still auf der CPU. Auf der Box getestet:
+      # so sieht llama.cpp beide Karten.
+      - LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:/usr/local/cuda/lib64
       - LLAMA_CACHE=/models                                # llama-server legt -hf-Downloads hier ab
     # Liest die vom llm-adapter generierte Config. --watch-config: Aenderungen
     # (Modell in Karte geladen/entladen) greifen von selbst — einen Reload-