docs(cluster): pveelite - cauza confirmata, resetul adaptorului USB LAN

Nodul nu s-a oprit niciodata. La verificarea de azi avea uptime 17h46m, cu boot
pornit la 27.08 ora 16:03:06 - a mers toata noaptea, fara retea. Jurnalul
continua cu 58.454 de linii dupa 17:26:44, ceea ce inchide definitiv discutia
alimentare vs retea.

Vinovatul, din jurnalul kernel: Realtek RTL8156B (0bda:8156, driver r8152) pe
usb 2-3. La 16:01:45 si la 17:26:41 adaptorul s-a resetat si a fost re-enumerat.
Kernelul sterge interfata si o recreeaza - dar nimeni nu o readauga in vmbr0 si
nu o ridica, pentru ca nu exista regula de hotplug. Din acel moment masina merge
perfect si e invizibila in retea.

Partea care merita retinuta e de ce la 16:01 si-a revenit si la 17:26 nu. La
16:01 LRM-ul HA era activ, deci watchdog-ul era armat: pierderea retelei a dus la
pierderea quorumului, watchdog-mux a expirat la 16:02:39 si a resetat masina la
16:02:44 - repornire care a readus reteaua din intamplare, pentru ca la boot
interfetele se ridica prin auto. La 17:26 fence-ul mutase deja vm:109 pe pvemini,
LRM-ul era idle, watchdog-ul nearmat. Nimic nu a mai repornit masina. Singurul
lucru care "repara" defectul asta era un efect secundar, nu un mecanism proiectat
- pe un nod fara servicii HA, aceeasi defectiune devine permanenta si tacuta.

Reparat cu ifreload -a de la consola, la 09:49. Restul verificarii e curat: ZFS
ONLINE fara erori, cluster 3/3, SMART fara FAILED, replicarea se reia singura.

Reparatia de fond intra in Tier 1: eno1 exista si e functional, doar ca nu are
cablu (Link detected: no). Adaptorul USB e cauza a doua incidente pe nodul asta.
Am scris si ordinea operatiilor, pentru ca inversata te lasa fara retea cu drum
pana la nod.

Prima rulare reala a scriptului a scos la iveala trei defecte ale lui, toate
reparate aici:

- tiparele de semnatura hardware prindeau linii normale de boot ("Registered
  thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0") si produceau
  un verdict de defect hardware care contrazicea concluzia corecta din acelasi
  bilant. Strans tiparele si filtrat prin -p warning; verificat pe nod: 0
  potriviri.
- LRM idle era raportat ca "stare neclara". E starea normala a unui nod fara
  servicii HA - iar scriptul spune acum explicit ca idle inseamna watchdog
  nearmat, adica exact motivul pentru care caderea de la 17:26 nu s-a auto-reparat.
- Tailscale era raportat [ok] desi e delogat: systemctl is-active zice active, dar
  tailscale status zice "Logged out". De aici si cele 27 de zile de offline.

Consemnat si raspunsul la intrebarea cu magic packet, cu MAC-urile ambelor
interfete, ca sa nu se reia: WoL nu ar fi ajutat oricum, masina nu era oprita.
Dupa mutarea pe eno1 devine insa realmente utilizabil.

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

proxmox/README.md

@@ -13,7 +13,7 @@ proxmox/
 │   │   ├── 2026-04-20-cluster-outage.md  # Cascadă OOM pveelite + USB LAN watchdog
 │   │   ├── 2026-04-30-pvemini-backup-ssd-hang.md  # Kingston SSD hang → emergency mode
 │   │   ├── 2026-07-31-lxc110-dns-tailscale-oom.md # DNS mort (Tailscale logout) + zram pe pve1
-│   │   └── 2026-08-27-pveelite-down.md    # DESCHIS — pveelite mort, suspiciune alimentare/hardware
+│   │   └── 2026-08-27-pveelite-down.md    # Reset adaptor USB LAN → pveelite fără rețea 16h
 │   └── ups/                           # Sistem UPS pentru cluster
 │       ├── README.md
 │       ├── docs/

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** — 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`
+- **2026-08-27 pveelite fără rețea 16h:** `incidents/2026-08-27-pveelite-down.md` — resetul adaptorului USB LAN scoate interfața din `vmbr0` și nu o mai readaugă nimeni; mașina merge, dar e invizibilă. Fix: `ifreload -a`. De fond: mutarea pe `eno1`. Verificare: `scripts/verifica-pveelite.ps1`
 
 ### LXC Containers
 - **LXC 108 - Oracle Database:** `../lxc108-oracle/README.md`

proxmox/cluster/incidents/2026-08-27-pveelite-down.md

@@ -1,10 +1,12 @@
-# Incident 2026-08-27 — pveelite cade definitiv la 4 ore după repornirea planificată a clusterului
+# Incident 2026-08-27 — pveelite dispare din rețea 16 ore, cu mașina pornită (reset adaptor USB LAN)
 
 **Severity:** Medium (zero impact pe producție — nodul nu găzduia niciun serviciu viu —
 dar clusterul rămâne pe **2 voturi din 3**, fără marjă de quorum, și replicarea către
 pveelite e oprită)
 **Detected:** 2026-08-27 17:31 EEST (alertă automată `pveelite-down-alert.sh` → email)
-**Status:** **DESCHIS** — nodul e inaccesibil, necesită intervenție fizică
+**Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică)
+**Status:** **REZOLVAT** — cauză confirmată din jurnal. Rămâne o acțiune de fond:
+mutarea rețelei de pe adaptorul USB pe `eno1`
 **Author:** Claude Code (mmarius28@gmail.com)
 
 ---
@@ -51,7 +53,64 @@ sau cedarea adaptorului USB de rețea. Ce se poate afirma acum:
 - **Tiparul e de hardware:** reset spontan la 16:01, apoi moarte definitivă 85 de minute
   mai târziu, pe o mașină idle. Semnătură clasică de PSU / RAM / termic.
 
-### Ipoteza alternativă, care trebuie exclusă prima: adaptorul USB de rețea
+### ROOT CAUSE CONFIRMAT (2026-08-28, din jurnalul nodului)
+
+Nodul **nu s-a oprit niciodată**. La verificarea din 28.08 ora 09:49, `uptime` arăta
+**17 ore și 46 de minute**, cu boot-ul pornit la **2026-08-27 16:03:06** — a mers
+neîntrerupt toată noaptea, fără rețea. Lista de boot-uri confirmă:
+
+```
+ -1  Thu 2026-08-27 13:20:28  ->  Thu 2026-08-27 16:02:44
+  0  Thu 2026-08-27 16:03:06  ->  Fri 2026-08-28 09:49:22
+```
+
+**Vinovatul:** adaptorul USB de rețea — Realtek RTL8156B, `0bda:8156`, „USB 10/100/1G/2.5G
+LAN", driver `r8152`, pe portul `usb 2-3` al controllerului `xhci_hcd 0000:00:14.0`.
+
+**Ce s-a întâmplat la 16:01:45** — adaptorul s-a resetat și a fost re-enumerat:
+
+```
+xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
+vmbr0: port 1(enx6c1ff71abe67) entered disabled state
+r8152 2-3:1.0 enx6c1ff71abe67 (unregistering): left promiscuous mode
+usb 2-3: new SuperSpeed USB device number 3 using xhci_hcd
+r8152 2-3:1.0 enx6c1ff71abe67: renamed from eth0
+```
+
+Kernelul șterge interfața și o recreează. **Interfața nouă nu e readăugată automat în
+`vmbr0` și nu e ridicată** — nu există regulă de hotplug. Din acel moment mașina merge
+perfect, dar nu mai are rețea.
+
+**De ce la 16:01 și-a revenit, iar la 17:26 nu.** La 16:01 nodul avea LRM-ul HA **activ**,
+deci watchdog-ul era armat. Pierderea rețelei a dus la pierderea quorumului, iar watchdog-ul
+a resetat mașina — repornire care a readus rețeaua *din întâmplare*, pentru că la boot
+interfețele se ridică prin `auto`:
+
+```
+16:02:08  pmxcfs: node lost quorum
+16:02:08  pve-ha-crm: lost lock 'ha_manager_lock' -> status change master => lost_manager_lock
+16:02:09  pve-ha-lrm: lost lock 'ha_agent_pveelite_lock' -> status change active => lost_agent_lock
+16:02:39  watchdog-mux: client watchdog expired - disable watchdog updates
+16:02:44  (ultima linie din boot-ul -1 — resetul hardware)
+```
+
+La **17:26:41** s-a produs exact același reset USB. De data asta însă fence-ul mutase deja
+`vm:109` pe pvemini, LRM-ul era **idle**, deci **watchdog-ul nu mai era armat**. Nimic nu a
+mai repornit mașina, și a rămas pornită și fără rețea 16 ore.
+
+> **Concluzia neplăcută:** singurul lucru care „repara" defectul ăsta era watchdog-ul HA,
+> adică un efect secundar, nu un mecanism proiectat. Pe un nod fără servicii HA, aceeași
+> defecțiune devine permanentă și tăcută.
+
+**Remediul aplicat:** `ifreload -a` de la consola fizică, la 09:49. Interfața și puntea au
+revenit imediat (`vmbr0 UP`, `enx6c1ff71abe67 UP,LOWER_UP`), nodul a reintrat în cluster.
+
+**Nu a fost alimentarea.** Nicio semnătură de eroare hardware în jurnal — zero potriviri
+pentru MCE, panic, temperatură peste prag, EDAC sau erori de I/O.
+
+---
+
+### Ipoteza alternativă, formulată înainte de confirmare
 
 **pveelite are placă de rețea pe USB**, iar deconectarea ei e modul de defectare deja
 documentat al acestui nod: incidentul [2026-04-20](2026-04-20-cluster-outage.md) a pornit
@@ -117,7 +176,7 @@ Dacă da, mașina a mers mai departe și a căzut doar rețeaua.
 
 ---
 
-## Starea la momentul investigației (21:22)
+## Starea la momentul investigației (27.08, ora 21:22 — înainte de a se cunoaște cauza)
 
 ### Cluster
 
@@ -186,30 +245,35 @@ Merită consemnat, pentru că sunt exact lucrurile reparate după aprilie:
 
 ---
 
-## Ce urmează — verificare la repornirea nodului
+## Verificarea de la revenire — rezultate (2026-08-28 09:49)
 
-Nodul se pornește fizic. Imediat după ce revine, se rulează
-[`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin:
+Rulat [`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin:
 
-```powershell
-.\proxmox\cluster\scripts\verifica-pveelite.ps1
-```
+| Verificare | Rezultat |
+|---|---|
+| Cauza căderii | **Cădere de rețea, nu de alimentare** — jurnalul continuă cu 58.454 de linii după 17:26:44 |
+| Adaptor USB LAN | **Reseturi confirmate** la 16:01:45 și 17:26:41, cu re-enumerare `usb 2-3` |
+| Semnături hardware | **Zero** — fără MCE, panic, temperatură peste prag, EDAC, erori de I/O |
+| ZFS | `ONLINE`, fără erori de date, fără resilver |
+| Cluster | **3 din 3 voturi**, marja de quorum refăcută |
+| Replicare | se reia singură — `109-1 SYNCING`, restul `pending` |
+| HA | LRM `idle` — normal, nodul nu are servicii asignate |
+| SMART | fără `FAILED` pe discuri |
+| Tailscale | serviciu pornit, dar **DELOGAT** — vezi Tier 1 |
 
-Scriptul acoperă, în ordine:
+### Trei defecte ale scriptului, găsite la prima rulare reală și reparate
 
-1. **S-a oprit mașina, sau doar a dispărut din rețea?** Testul decisiv: există intrări în
-   jurnal după 17:26:44? Dacă da → a mers mai departe, a căzut rețeaua (adaptorul USB), iar
-   reparația e la dongle/cablu/switch. Dacă nu → mașina chiar s-a oprit, și atunci contează
-   dacă jurnalul e tăcut înainte (MCE, termic, panic, EDAC). **Tăcere = alimentare/hardware,
-   nu software** — și atunci nodul nu mai e de încredere ca țintă de failover.
-2. **Integritatea ZFS** — `zpool status -v` după două opriri necurate; se așteaptă
-   eventual un resilver automat, ca în aprilie.
-3. **Revenirea în cluster** — quorum 3/3, `pvecm status`, `/etc/pve/.members`.
-4. **Repornirea replicării** — `pvesr status`, FailCount înapoi la 0, toate cele 9 job-uri
-   recuperate. Nu necesită intervenție manuală; se reiau singure.
-5. **HA** — LRM pveelite `active`, nu `dead`.
-6. **SMART pe discuri** — temperaturi și erori, dat fiind precedentul Kingston.
-7. **Tailscale** — repornit și `Online`, ca să existe acces out-of-band data viitoare.
+1. **Fals pozitiv la semnăturile hardware.** Tiparele inițiale (`thermal`, `nmi`, `edac`,
+   `BUG:`) prindeau linii normale de boot — „Registered thermal governor", „NMI watchdog:
+   Enabled", „EDAC MC: Ver: 3.0.0" — și produceau un verdict de defect hardware care
+   **contrazicea concluzia corectă din același bilanț**. Tiparele au fost strânse și
+   filtrate prin `-p warning`; verificat pe nod: 0 potriviri.
+2. **LRM `idle` raportat ca „stare neclară".** `idle` e starea normală a unui nod fără
+   servicii HA. Acum e tratată ca atare — și, mai important, scriptul spune explicit că un
+   LRM idle înseamnă **watchdog nearmat**, adică fix motivul pentru care căderea de la 17:26
+   nu s-a auto-reparat.
+3. **Tailscale raportat `[ok]` deși era delogat.** `systemctl is-active` întorcea `active`,
+   dar `tailscale status` spunea `Logged out`. Verificarea se uită acum la starea reală.
 
 ---
 
@@ -224,40 +288,58 @@ fizică.
 ssh root@10.0.20.202 "systemctl enable --now tailscaled && tailscale up && tailscale status"
 ```
 
-**2. Verdictul hardware, scris explicit.**
-Dacă `journalctl -b -1` nu conține nimic înainte de 17:26 (tăcere completă, ca la pvemini pe
-2026-04-20), atunci **cauza e hardware și nodul trebuie tratat ca nesigur** până la
-înlocuirea sursei / testare RAM. Nu se lasă concluzia „a mers, deci e bine".
+**2. Mută rețeaua de pe adaptorul USB pe `eno1` — reparația de fond.**
+`eno1` **există și e funcțional**, doar că nu are cablu: `Link detected: no`, driver
+încărcat, `Supports Wake-on: pumbg`. Adaptorul USB e cauza a **două** incidente pe acest nod
+(2026-04-20 și cel de față) și rămâne un punct unic de cedare pe magistrala USB.
 
-**3. Notează adresa MAC a lui pveelite — acum nu o mai are nimeni.**
-În timpul incidentului s-a pus întrebarea dacă nodul poate fi trezit cu un magic packet
-(Wake-on-LAN). **Nu s-a putut nici măcar încerca:** intrarea ARP expirase peste tot —
-`ip neigh` pe pvemini (`INCOMPLETE`) și pe pve1 (`FAILED`), tabela ARP a stației de admin,
-LXC-urile de pe LAN. Nodurile au IP static, deci nu există lease DHCP, iar MAC-ul nu e
-consemnat în documentație. Singurele surse rămase: tabela ARP/DHCP a routerului 10.0.20.1
-sau citirea fizică de pe nod.
-
-Separat de asta, **WoL are șanse mici pe acest nod**: placa de rețea e pe USB, iar un
-adaptor USB rămâne nealimentat în stare soft-off, deci nu poate asculta după magic packet.
-De verificat la repornire, împreună cu MAC-ul:
+Ordinea contează, altfel rămâi din nou fără rețea, cu drum până la nod:
 ```bash
-ssh root@10.0.20.202 "ip -br link; ethtool <iface> | grep -iE 'Wake-on|Supports Wake'"
+# 1. Mută fizic cablul LAN din dongle-ul USB in portul eno1 de pe placa de baza.
+# 2. De la CONSOLA fizica (nu prin SSH — reteaua pica in timpul operatiei):
+sed -i 's/bridge-ports enx6c1ff71abe67/bridge-ports eno1/' /etc/network/interfaces
+ifreload -a
+ip -br link          # eno1 trebuie sa fie UP, vmbr0 UP
 ```
-Dacă apare `Supports Wake-on: g` și se activează și în BIOS, WoL devine posibil. Dacă nu,
-concluzia se scrie explicit aici, ca să nu se reia discuția la următorul incident.
+Dongle-ul USB rămâne ca rezervă, scos din `vmbr0`.
 
-**4. Textul alertei — scos exportul NFS inexistent.**
+**3. Regulă de hotplug, dacă adaptorul USB rămâne în uz.**
+Cauza reală nu e resetul USB în sine — e faptul că interfața recreată **nu e readăugată în
+punte**. `auto enx...` în `/etc/network/interfaces` ridică interfața doar la boot;
+`allow-hotplug` o ridică și la re-enumerare. Fără asta, orice reset USB scoate nodul din
+rețea definitiv.
+
+**4. Adresele MAC — consemnate acum, ca să nu se mai piardă.**
+
+| Interfață | MAC | Wake-on-LAN |
+|---|---|---|
+| `eno1` (placă de bază) | `84:69:93:57:b2:ea` | `Supports: pumbg`, activ `g` |
+| `enx6c1ff71abe67` (USB Realtek RTL8156B) | `6c:1f:f7:1a:be:67` | `Supports: pumbg`, activ `g` |
+
+În timpul incidentului s-a pus întrebarea dacă nodul poate fi trezit cu un magic packet.
+**Nu s-a putut nici măcar încerca:** intrarea ARP expirase peste tot — `ip neigh` pe pvemini
+(`INCOMPLETE`) și pe pve1 (`FAILED`), tabela stației de admin, LXC-urile de pe LAN. Nodurile
+au IP static, deci nu există lease DHCP, iar MAC-ul nu era consemnat nicăieri.
+
+Concluzia, scrisă explicit ca să nu se reia discuția: **WoL nu ar fi ajutat oricum** — mașina
+nu era oprită, ci pornită și fără rețea. Un magic packet nu are ce trezi. După mutarea pe
+`eno1`, WoL devine însă realmente utilizabil, pentru că e placă integrată, alimentată în
+soft-off — spre deosebire de un dongle USB.
+
+**5. Textul alertei — scos exportul NFS inexistent.**
 `/opt/scripts/pveelite-down-alert.sh` menționează `10.0.20.202:/mnt/pve/oracle-backups`, care
 nu mai e în `storage.cfg`. Cine citește alerta la 3 noaptea o ia pe o pistă falsă.
 
-### 🟡 Tier 2 — de decis după verdictul hardware
+### 🟡 Tier 2
 
-**5. Ce se întâmplă cu marja de quorum.**
-Cât timp pveelite e nesigur, clusterul funcționează pe 2 din 3 voturi. Nu se umblă la
-`expected votes` cât timp e quorate — dar dacă nodul urmează să stea oprit zile întregi,
-merită decis conștient dacă rămâne în cluster sau se scoate temporar.
+**6. Detecția tăcerii — nodul a stat 16 ore căzut fără să afle nimeni.**
+Alerta a funcționat corect la 17:31, dar apoi incidentul a rămas nesupravegheat peste noapte.
+Mai grav: pe un nod **fără servicii HA**, watchdog-ul nu e armat, deci nu există niciun
+mecanism care să repare sau măcar să semnaleze o cădere de rețea. Nodul rămâne pornit,
+sănătos și invizibil. Merită o alertă de repetiție (nu doar una la început de incident) sau
+un al doilea inel corosync pe `eno1`, care ar fi ținut nodul în cluster peste căderea USB.
 
-**6. `local-zfs` pe pvemini la 92 %.**
+**7. `local-zfs` pe pvemini la 92 %.**
 Separat de incident, dar pe același nod pe care stă acum toată producția.
 
 ---

proxmox/cluster/scripts/verifica-pveelite.ps1

@@ -67,8 +67,18 @@ $IncidentStart = '2026-08-27 13:20'      # boot-ul de dupa oprirea planificata
 
 # Tipare de eroare hardware in jurnalul kernel. Daca NICIUNUL nu apare, verdictul
 # inclina spre alimentare (masina nu apuca sa scrie nimic inainte sa dispara).
-$TipareHw = 'mce|machine check|hardware error|thermal|temperature above|critical temp|' +
-            'nmi|kernel panic|oops|BUG:|edac|pcieport.*error|ATA bus error|I/O error'
+#
+# Tiparele sunt deliberat STRANSE. Prima versiune cauta 'thermal', 'nmi', 'edac',
+# 'BUG:' si a raportat fals pozitiv la rularea din 28.08: liniile normale de boot
+# ("Registered thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0",
+# "DPC: error containment capabilities") au declansat un verdict de defect hardware
+# care contrazicea concluzia corecta. Un fals pozitiv aici nu e zgomot inofensiv -
+# trimite pe pista gresita exact cand trebuie luata o decizie.
+$TipareHw = 'Machine Check|mce: |Hardware Error|Uncorrected error|' +
+            'temperature above threshold|critical temperature|' +
+            'Kernel panic|Oops: |watchdog: BUG: soft lockup|' +
+            'EDAC.*(CE|UE) .*error|AER: .*error|Buffer I/O error|' +
+            'blk_update_request.*I/O error|ATA bus error'
 
 $ReplJobs = 9   # 9 job-uri de replicare au pveelite ca tinta
 
@@ -241,14 +251,16 @@ if ($usbEv) {
 # Cautarea tintita de semnaturi hardware, peste toate boot-urile de ieri.
 Write-Host ""
 Write-Info "--- semnaturi hardware in jurnal (MCE / termic / panic / EDAC) ---"
+# -p warning taie zgomotul de boot inainte de a ajunge la grep: mesajele de
+# inregistrare a guvernatorilor termici, EDAC si NMI sunt de nivel info.
 $hw = Invoke-Node -Node pveelite -Command `
-    "journalctl --since '$IncidentStart' --no-pager | grep -iE '$TipareHw' | tail -25"
+    "journalctl --since '$IncidentStart' -p warning --no-pager | grep -E '$TipareHw' | tail -25"
 
 $verdictHw = $false
 if ($hw) {
     Write-Bad "GASIT - nodul a lasat urme de eroare hardware:"
     $hw | ForEach-Object { Write-Host "       $_" -ForegroundColor Red }
-    Add-Rezultat 'Cauza caderii' 'bad' 'semnaturi hardware in jurnal - vezi liniile de mai sus'
+    Add-Rezultat 'Semnaturi hardware' 'bad' 'erori hardware in jurnal - vezi liniile de mai sus'
     $verdictHw = $true
 } else {
     Write-Info "niciun MCE, eroare termica, panic sau EDAC in jurnal"
@@ -354,6 +366,16 @@ $ha | ForEach-Object { Write-Info $_ }
 if ($ha -match 'lrm pveelite \(active') {
     Write-Ok "LRM pveelite activ"
     Add-Rezultat 'HA' 'ok' 'LRM activ'
+} elseif ($ha -match 'lrm pveelite \(idle') {
+    # 'idle' e starea normala pentru un nod fara servicii HA asignate - si e
+    # exact cazul lui pveelite dupa ce fence-ul a mutat vm:109 pe pvemini.
+    # ATENTIE: cu LRM idle, watchdog-ul NU e armat. La 16:01 watchdog-ul a
+    # repornit nodul si i-a readus reteaua; la 17:26, fara el, nodul a ramas
+    # pornit si fara retea pana dimineata.
+    Write-Ok "LRM pveelite idle - normal, nodul nu are servicii HA asignate"
+    Write-Info "Consecinta: watchdog-ul nu e armat, deci o cadere de retea nu se"
+    Write-Info "mai auto-repara prin reboot, cum s-a intamplat la 16:01."
+    Add-Rezultat 'HA' 'ok' 'LRM idle (fara servicii asignate) - watchdog nearmat'
 } elseif ($ha -match 'lrm pveelite.*old timestamp') {
     Write-Warn "LRM pveelite inca 'dead' - poate dura un minut dupa boot; reverifica"
     Add-Rezultat 'HA' 'warn' "LRM inca 'old timestamp'"
@@ -406,8 +428,16 @@ Write-Info "viitoare a nodului cere din nou deplasare fizica."
 $ts = Invoke-Node -Node pveelite -Command 'systemctl is-active tailscaled 2>/dev/null; tailscale status 2>&1 | head -3'
 $ts | ForEach-Object { Write-Info $_ }
 
-if ($ts -match '^active') {
-    Write-Ok "tailscaled activ"
+if ($ts -match 'Logged out|Stopped') {
+    # Capcana: serviciul poate fi 'active' si totusi inutilizabil. Exact asa arata
+    # pveelite la 28.08 - tailscaled pornit, dar delogat, ceea ce explica cele 27
+    # de zile de "offline". A verifica doar systemctl is-active da un fals OK.
+    Write-Bad "tailscaled ruleaza, dar e DELOGAT - nu exista acces out-of-band"
+    Write-Info "Reautentificare (cere deschiderea link-ului afisat intr-un browser):"
+    Write-Info "  ssh root@$($NodeIp.pveelite) 'tailscale up'"
+    Add-Rezultat 'Tailscale' 'bad' 'delogat - fara acces out-of-band'
+} elseif ($ts -match '^active') {
+    Write-Ok "tailscaled activ si autentificat"
     Add-Rezultat 'Tailscale' 'ok' 'activ'
 } else {
     Write-Warn "tailscaled NU e activ - reactiveaza-l acum:"