docs(cluster): pveelite are LAN pe USB - a doua ipoteza pentru caderea de ieri

Intrebarea "nu-l putem trezi cu un magic packet?" a scos la iveala ceva ce
schimba diagnosticul, nu doar raspunsul la ea.

Pe WoL, pe scurt: nu se poate nici macar incerca. MAC-ul lui pveelite nu mai
exista nicaieri - intrarea ARP a expirat pe pvemini (INCOMPLETE), pe pve1
(FAILED), in tabela statiei de admin si pe LXC-urile de pe LAN; nodurile au IP
static, deci nu exista lease DHCP; in documentatie nu e consemnat. Raman tabela
routerului sau citirea fizica de pe nod. Si chiar cu MAC-ul, placa de retea e pe
USB, iar un dongle USB e nealimentat in soft-off, deci nu asculta dupa magic
packet.

Partea care conteaza insa e alta: pveelite ARE placa de retea pe USB, si
deconectarea ei e modul de defectare deja documentat al acestui nod - incidentul
2026-04-20 a pornit exact de la un USB LAN disconnect, motiv pentru care tokenul
corosync a fost marit la 10 s. Un nod care si-a pierdut adaptorul de retea arata
din exterior identic cu unul oprit: fara ping, fara ARP, fara corosync, fara SSH.
Toate observatiile din incident sunt compatibile cu ambele scenarii, iar eu
scrisesem doar unul.

Pentru 16:01 dovezile inclina in continuare spre repornire - curba de memorie din
RRD se reseteaza (2,43 GB la 16:00 -> 2,10 GB la 16:30, sub valoarea de dupa boot)
si NFS-ul se reataseaza. Pentru 17:26 nu exista niciun indiciu echivalent: nodul
pur si simplu a incetat sa fie vizibil, ceea ce o deconectare USB explica la fel
de bine ca o pierdere de alimentare. Am slabit corespunzator formularile din TL;DR
si din cronologie, unde afirmasem repornirea ca fapt.

Consecinta practica, pusa in document ca avertisment inainte de orice altceva:
prima observatie la fata locului e daca masina merge - ventilatoare, LED-uri,
imagine. Daca e pornita, nu a fost o cadere de alimentare, jurnalul e intact si
reparatia e la dongle, cablu sau portul de switch. Nu apasa butonul de power
inainte sa te uiti.

In script, pasul 1 nu mai citeste boot-urile dupa index - indexurile difera intre
cele doua scenarii si ar fi dus la concluzii gresite. Acum taie jurnalul dupa ora
si pune intai testul decisiv: exista intrari dupa 17:26:44? Daca da, masina a mers
mai departe si a cazut doar reteaua, iar verdictul si remediile se schimba complet.
Adaugat si un bloc de diagnostic pentru adaptorul USB (interfete, drivere, lsusb,
deconectari si evenimente de link in jurnalul kernel).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8

proxmox/cluster/README.md

@@ -870,7 +870,7 @@ swapon -a
 - **2026-04-20 Cluster Outage:** `incidents/2026-04-20-cluster-outage.md` — post-mortem complet + plan prevenție
 - **2026-04-30 pvemini backup SSD hang:** `incidents/2026-04-30-pvemini-backup-ssd-hang.md` — Kingston thermal hang → emergency mode
 - **2026-07-31 LXC 110 DNS + OOM:** `incidents/2026-07-31-lxc110-dns-tailscale-oom.md` — logout Tailscale → DNS mort; zram instalat pe pve1
-- **2026-08-27 pveelite down:** `incidents/2026-08-27-pveelite-down.md` — **DESCHIS** — reset spontan 16:01, cădere definitivă 17:26, jurnal tăcut ⇒ suspiciune alimentare/hardware. Verificare la repornire: `scripts/verifica-pveelite.ps1`
+- **2026-08-27 pveelite down:** `incidents/2026-08-27-pveelite-down.md` — **DESCHIS** — nodul dispare la 16:01, revine, apoi cade definitiv la 17:26. Două ipoteze hardware: alimentare sau adaptorul USB de rețea. Verificare la revenire: `scripts/verifica-pveelite.ps1`
 
 ### LXC Containers
 - **LXC 108 - Oracle Database:** `../lxc108-oracle/README.md`