nanobot: 2026-09-20 12:21:23

projects/devops/memory.md

@@ -225,3 +225,12 @@ Vyhodnocení testu:
 
 Zůstává otevřené: bez ohledu na výsledek testu stále chybí PBS (kam zálohovat) — nezávislé na 9020.
 - 2026-09-18: Stav sehnání originálního Dell PSU pro 9020: hledaný, ale **nenašel se** (uživatel zkusí ještě jednou). Bezpečný test Aukro desky přes originální zdroj je tedy zatím nedostupný — test půjde pravděpodobně přes AliExpress adapter s vědomým rizikem (konvertor může zabít i novou desku).
+- 2026-09-19: Root cause BIOS neukládání na Optiplexu 9010 nalezen: uživatel sám vyndal **PSWD jumper** (schválně, aby smazal heslo od předchozího správce — jinak nemohl měnit nastavení). Bez nasazeného jumperu je deska v ochranném režimu a **žádné změny v BIOSu se neukládají** (ani nová hesla). Nejsou za tím CMOS battery, verze BIOSu ani jumper jinde.
+
+Postup (dohodnutý, dle konzultace s Gemini):
+1. Vypnout PC, odpojit napájení
+2. Nasadit jumper zpět na oba piny PSWD (staré heslo už je smazané, nové není potřeba)
+3. Zapnout, F2 do BIOSu, nastavit potřebné hodnoty, uložit
+4. Ověřit: výstražná hláška zmizí a hodnoty po restartu zůstanou
+
+Pozn.: bezpečnostní důsledek — BIOS je po nasazení jumperu bez hesla, plně přístupný. U homelab stroje přijatelné.

projects/devops/state.md

@@ -10,7 +10,7 @@ timestamp: draft
 - Ollama na nvidia.hell: po incidentech 12.–13. 9. 2026 zaevidován root cause pádů — kauzální řetěz: ollama rozhoduje load podle VRAM ne volné RAM + vypíná mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy, regrese od 2026-06-05) + PLE host buffer u gemma4 + přerušený load leakuje napinovanou host paměť (neviditelná pro ps/nvidia-smi/cgtop, detekce jen `nr_foll_pin` delta v /proc/vmstat), uvolní **jen reboot** (rmmod driveru ověřeně NE). Cgroup pojistka (`MemoryMax=6G`, `MemorySwapMax=0`, bez MemoryHigh) ověřena zátěžovým testem: 240/240 SSH heartbeatů, load 3,41 vs 81 při incidentu. Skutečný zdroj zátěže = nanobot.hell (dávky přes ~10 modelů + embedding), LibreChat jen zesilovač. Reporty v `artifacts/2026-09-13_ollama-nvidia-full-report.md` (ucelený, s kuchařkou pro triáž) a `artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (negativní zjištění), shrnutí v memory.md 2026-09-14. Zavržené cesty: earlyoom i jakákoli externí kill varianta, MemoryHigh pod MemoryMax, navýšení RAM (headroom konstanta 7,5 GiB), limit počtu modelů, OLLAMA_LOAD_TIMEOUT, upgrade ollamy, mmap override (neexistuje), ballooning (`balloon: 0` + pevná paměť), rmmod jako remedy.
 
 ## Co dál
-- **HW po migraci na Optiplex 9010 (aktuální fronta):** (1) BIOS — neukládající se změny (CMOS battery? verze?); (2) doladit sekundární vetrak; (3) instalovat nový 1TB NVme; (4) nahodit Proxmox Backup Server — kandidát pivo.hell (Atom), aby bylo kam zálohovat; (5) dlouhodobě plán nového HW — průzkum ukázal 15–20 l skříňky s převahou jader, což nevyhovuje (uživatel nechce víc jader); zvažovat mini-ITX SFF, Optiplex jako mezikrok, custom build.
+- **HW po migraci na Optiplex 9010 (aktuální fronta):** (1) ~~BIOS — neukládající se změny~~ — root cause nalezen 2026-09-19: vyndaný PSWD jumper drží desku v ochranném režimu; fix: nasadit jumper zpět na oba piny PSWD, nastavit hodnoty v BIOSu, uložit, ověřit persistenci (postup v memory.md 2026-09-19); (2) doladit sekundární vetrak; (3) instalovat nový 1TB NVme; (4) nahodit Proxmox Backup Server — kandidát pivo.hell (Atom), aby bylo kam zálohovat; (5) dlouhodobě plán nového HW — průzkum ukázal 15–20 l skříňky s převahou jader, což nevyhovuje (uživatel nechce víc jader); zvažovat mini-ITX SFF, Optiplex jako mezikrok, custom build.
 - Rozhodnout umístění LibreCodeInterpreter (AI stack VM vs dedikovaná VM) a nasadit — viz memory.md 2026-09-13 pro capability požadavky (SYS_ADMIN, NET_ADMIN, apparmor:unconfined).
 - Ollama open body dle priority (report §11): (1) ~~zastavit dávky z nanobot.hell~~ — **neplatí jako provozní riziko** (dávky byly testovací tool-calling requesty, běžný provoz nanobot nesahá na lokální modely); (2) retest cgroup pojistky bez MemoryHigh (odblokováno rebootem; kritéria: heartbeat bez výpadku, MemAvailable > 2 GiB, dmesg constraint=MEMCG); (3) doladit MemoryMax podle memory.peak; (4) rozhodnout osud gemma4 (PLE ~5,9 GiB host bufferu, na 9,5 GiB stroji nikdy); (5) `OLLAMA_KV_CACHE_TYPE=q4_0` zrušit nebo nepoužívat granite-code; (6) drobnosti: `apt purge` earlyoom (rc), llama-server `--log-verbosity 4`, zabbix `Hostname=Zabbix server` → nvidia, LibreChat titleConvo duplicitní requesty, otázka real-time monitoringu (hlídač co killuje = zavržená cesta).
 - Návrh k rozhodnutí: izolovat embedding pipeline (wiki skill) ze ollamy na statický llama.cpp server (`llama-server --embeddings --pooling last`, stejný GGUF, /v1/embeddings) — obejde load path, kde vzniká leak; po ní nanobot nezůstane na lokální ollamě žádný provoz krom cloud proxy. Vyžaduje: úprava wiki_embed.py klienta, config.yaml endpoint, reindex --full.